Keeping all of your server’s installed packages up to date is paramount to system security even if the server is physically isolated from the internet. On an internet-connected server or workstation staying up to date is as easy is issuing the ‘yum update’ or ‘dnf update’ command from a privilege-elevated shell prompt. Updating a RHEL or CentOS server that is isolated from the internet is not much more difficult but it will require us create an http proxy server and change the yum configuration on our target machine to have it look to our proxy for package updates.
Step 1 : Select the Hardware Necessary for Our HTTP Proxy
Yum does all of its package fetching via http, the same protocol that makes the internet go around. To get yum talking to the outside world all we need to do is provide it an http proxy. We’ll be using Squid as our proxy service to bridge the gap between our isolated server and the open internet. We’ll need to select a machine with at least two network interfaces to install it on. A laptop with both a wired and wireless network interface makes a nice portable solution provided you have high confidence in that laptop’s security. In my environment I use a laptop running RHEL 7.3 that has been hardened, and then checked and re-checked for vulnerabilities which I use for no other purpose than updating my handful of isolated RHEL servers.
Step 2: Install The Squid HTTP Proxy
From a shell-prompt on the machine you’ve selected to be your proxy server enter the following to locate the Squid package:
# yum search squid
This should net you a handful of returns, among them you should see:
squid.x86_64 : The Squid proxy caching server
if you don’t, check your repolist and ensure that the base repo is present and enabled.
Install this now with the command:
# yum install squid
Next you’ll see some dependencies being resolved and a (Y or N) prompt, type y and press enter to finalize installation.
Step 3 : Configure the Squid Service and Firewall
The configuration file is located at /etc/squid/squid.conf and works pretty well out of the box. One thing you might consider is the directive:
# Squid normally listens to port 3128
If you want the server to listen on any other port you’ll want to make the change here and update your firewall and selinux configuration.
If you stuck with the default port 3128, allow the service through your firewall with the following commands:
# firewall-cmd –permanent –add-service=squid
# firewall-cmd –reload
Step 4 : Start the Squid Service
You now have a choice to make as to whether to enable the Squid service to run each time the machine is booted or to start it on a per-use basis. I prefer the latter as I’d rather not have an extra service running each time I connect my machine to the network. The only drawback is that I have to remember to start the service manually each time I connect up to perform updates.
If you want to enable the service to run all the time issue the following command:
# systemctl enable squid
When you’re ready to start the service issue:
# systemctl start squid
If all went well we should be able to issue the ‘# systemctl status squid’ and see it running(active).
Step 5 : Configure YUM on your isolated server
Yum is proxy-aware, but will not look to a proxy by default. In order to have it check a proxy rather than the machine’s default interface we’ll need to make a change to its /etc/yum.conf file first.
# vi /etc/yum.conf
Go right up under the [main] section of the machine that needs updates and add the following:
As an example, if my isolated server was at 192.168.1.10, I would connect my proxy laptop and give it an available IP address on the same subnet, say 192.168.1.21, and then edit the yum.conf [main] section adding,
Step 6 : Test Your Configuration
Let’s check our network setup before proceeding. We have our isolated network on which our target server resides, and our internet-facing network. Our proxy server has two network interfaces and lives on both the isolated and internet-facing network. Our proxy server gets one IP address from the internet facing network and one from the isolated network. Your isolated target server that needs updates can ping the proxy server and has it’s yum.conf pointing at your proxy server’s isolated network IP address, port 3128 (or whatever port you chose in the step 3).
Squid writes logs to /var/log/squid so on your proxy machine watch the access.log with:
# tail -f /var/log/squid/access.log
Then go to your isolated server try to pull a repolist:
# yum repolist
On your isolated server you should see a list of enabled repositories with a number signifying packages available on the right hand side while on your Squid server you should see log output signifying that a machine has asked the squid server to pass http traffic on its behalf.
Step 7 : Update
A full update from yum on the isolated server will now be possible with the following command:
# yum update
There are a lot of moving parts here so please don’t be discouraged if everything doesn’t go off without a hitch when you issue that first yum repolist command on your isolated server. If things don’t go as expected check the following:
- Does your squid server have a valid IP on both the internet-facing and isolated facing networks? This is important, you should be able to ping to the open internet and your isolated server (if it’s not set up to deny ping requests).
- Is the firewall open for squid traffic on the proxy server? Run # firewall-cmd –list-all to verify the squid service is allowed.
- Is the squid service running? Run # systemctl status squid to verify.
- Does your isolated server have the correct ip/port directive in the [main] section of /etc/yum.conf? A spelling error or mistyped IP address could be a showstopper.
- Does your isolated server have a valid connection to your proxy server? Can you ping it?
- Finally, just to be sure, run a # firewall-cmd –reload and # systemctl restart squid
You should now be able to run yum updates on this isolated server, as well as any isolated server in your environment after revisiting the steps necessary for configuring your network and yum.conf file. If you want to be extra careful with security, and I suggest that you do, you should run a scan on your proxy server with your organization’s approved security tools before moving on to the next isolated server.