I have a backup server and I was wondering if I set a cron job to allow connection from a server in IPTables then once it connects with rsync, can I use IPTables to then shut off the port to prevent connections?

The idea is to block the chance of backups getting wiped if the main server got compromised(yes, it is secured but i dont take chances.)

EDIT: After trying stuff and because of how things work. I decided the best idea will be to setup a second server which will just pull from the first server.


Assuming it connects over ssh rather than rsyncd, you could handle this with a rule such as this

iptables -A INPUT -s <server> -p tcp --dport ssh -m connlimit --connlimit-saddr --connlimit-upto 1 -j ACCEPT

Providing there are no other rules to allow it and the policy for INPUT is REJECT or DROP, this will work.

If you also want to restrict this to a specific time, additionally use -m time --timestart 01:00:00 --timestop 01:02:00 - which would provide a two minute window every day starting at 1AM


First, to answer your question directly: yes, it's certainly possible, and quite simple.

You would just have one cron job allow traffic from that server:

-A Firewall-1-INPUT -p tcp -m state --state NEW -s -j ACCEPT

Then another cron job to remove that rule:

-D Firewall-1-INPUT -p tcp -m state --state NEW -s -j ACCEPT


Are you connecting using the native rsync protocol? If so, you really shouldn't do that, as it's weakly authenticated and unencrypted. Instead, use rsync over SSH, with key authentication and password auth turned off (you should already be doing this on your servers anyway). By using rsync+ssh, all traffic will be encrypted, and with key auth, it's not necessary to do the iptables song and dance, either, as the chances of someone brute forcing your username and keypair are infinitesimally remote.

Additionally, as mentioned below by Skaperen, your backup server should be the one that initiates connection(s) to the systems it's backing up, not the other way around.

  • In the case of backup of internet connected servers, where the backup machine itself is not connected and expected to thus be more secure, have the backup server originate the ssh connection to the server to be backed up. That way, keys that could potentially access all the backups of all the servers won't need to be in a machine that can be accessed by the internet. – Skaperen Feb 9 '13 at 4:34
  • @Skaperen - yes, clearly that is the way things should be. I assumed that's what was being proposed by the OP, but perhaps I misread things. – EEAA Feb 9 '13 at 4:35
  • He's clearly concerned to be secure, but I don't know that he had considered the idea of the server pulling backups. There's a rare chance that can't be done. (de KA9WGN) – Skaperen Feb 9 '13 at 4:42
  • Yea, I would server pull, but because these are cpanel accounts it kinda has to be done their way.. – Tiffany Walker Feb 9 '13 at 5:21
  • @TiffanyWalker Ugh, cPanel. Ditch that crap. It's garbage. As you're finding out, it makes everything all too complicated and makes it very difficult to troubleshoot things. That makes me think, though, what about them being cPanel makes doing this the right way impossible? Surely you can create a new system user and deploy the backup server user's pubkey there, correct? – EEAA Feb 9 '13 at 5:24

To meet your goal, I would consider the alternative idea of having the backup server isolated on a private IP subnet behind a firewall and it originate the backups of the internet connected servers via a private IP, and ssh key (not password) based connectivity. This way keys that can do powerful things are more isolated from the internet.

  • the problem is the key to backup cpanel accounts sits on the cpanel server. so if server takes a compromise so does the backup server – Tiffany Walker Feb 9 '13 at 5:19
  • By "cpanel server" you mean each of the servers to be backed up (and cpanel is managing that)? This is something I didn't know (being as I don't use cpanel). I'd still suggest looking into a way to do it more securely. – Skaperen Feb 9 '13 at 5:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.