У меня есть резервный сервер, и мне было интересно, устанавливаю ли я задание cron, чтобы разрешить подключение с сервера в IPTables, а затем, когда он подключается к rsync, могу ли я использовать IPTables, чтобы затем отключить порт для предотвращения подключений?
Идея состоит в том, чтобы заблокировать возможность стирания резервных копий, если основной сервер был скомпрометирован (да, он защищен, но я не рискую).
РЕДАКТИРОВАТЬ: после попытки и из-за того, как все работает. Я решил, что лучше всего будет установить второй сервер, который будет работать только с первого сервера.
Предполагая, что он подключается через ssh, а не через rsyncd, вы можете справиться с этим с помощью такого правила, как это
iptables -A INPUT -s <server> -p tcp --dport ssh -m connlimit --connlimit-saddr --connlimit-upto 1 -j ACCEPT
Если нет других правил, разрешающих это, и политика для INPUT - REJECT или DROP, это будет работать.
Если вы также хотите ограничить это определенным временем, дополнительно используйте -m time --timestart 01:00:00 --timestop 01:02:00 - что обеспечит двухминутное окно каждый день, начиная с 01:00.
Во-первых, прямо отвечу на ваш вопрос: да, конечно, возможно и довольно просто.
У вас будет только одно задание cron, разрешающее трафик с этого сервера:
-A Firewall-1-INPUT -p tcp -m state --state NEW -s 1.2.3.4 -j ACCEPT
Затем еще одно задание cron по удалению этого правила:
-D Firewall-1-INPUT -p tcp -m state --state NEW -s 1.2.3.4 -j ACCEPT
Но...
Вы подключаетесь с использованием собственного протокола rsync? Если так, вам действительно не следует этого делать, поскольку он слабо аутентифицирован и не зашифрован. Вместо этого используйте rsync через SSH, отключив аутентификацию по ключу и аутентификацию по паролю (в любом случае вы уже должны делать это на своих серверах). Используя rsync + ssh, весь трафик будет зашифрован, а с аутентификацией по ключу также не обязательно исполнять песни и пляски iptables, так как шансы на то, что кто-то взломает ваше имя пользователя и пару ключей, бесконечно малы.
Кроме того, как упомянуто ниже Skaperen, ваш сервер резервного копирования должен быть тем сервером, который инициирует соединение (я) с системами, для которых выполняется резервное копирование, а не наоборот.
Чтобы достичь вашей цели, я бы рассмотрел альтернативную идею изолированного сервера резервного копирования в частной IP-подсети за брандмауэром и создания резервных копий подключенных к Интернету серверов через частный IP-адрес и подключение на основе ключа ssh (а не пароля). Таким образом, ключи, которые могут делать мощные вещи, более изолированы от Интернета.