LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   CentOS (https://www.linuxquestions.org/questions/centos-111/)
-   -   Help with securing local repository (https://www.linuxquestions.org/questions/centos-111/help-with-securing-local-repository-4175585051/)

jjscott 07-19-2016 05:01 PM

Help with securing local repository
 
I have hundreds of CentOS 6 workstations across the US and decided to create a local repository to patch them. These workstations have limited access to the internet, but can reach the local repository on our network. So far, I have created the local CentOS 6.8 repository and am using rsync to pull updates from a CentOS mirror. The local repository is using Apache to share the files with the remote workstations.

My question is…how can I verify the files from the mirror are valid? I know the mirror I am using has a GPG key on their site and I can see that it is located on my local repository server in /etc/pki/rpm-gpg and is named RPM-GPG-KEY-CentOS-6. The contents of the file on my server match the contents of the file on their server. Does there need to be some type of GPG check included in the rsync command that runs to get the latest updates from the mirror? I thought I read somewhere that you shouldn’t check against the GPG key on the mirror you download from, but rather, from the official CentOS site. If true, how do I automate this?

What about the workstations that will be patching from my local repository? Shouldn’t they validate the GPG key on my local repository? Remember, they do not have access to the mirror I download from or the official CentOS site.

Thanks

sundialsvcs 07-19-2016 05:23 PM

As to the second point: I'm not entirely sure how you are using Apache to communicate with the remote workstations, but that's not how I would recommend doing it.

I would use OpenVPN with digital certificates (as I've described e.g. in my "Dwarvish Door" post, here ...) to provide each workstation with individually accountable, cryptographically secure connections to your repository. (As an alternative, ssh with certificate-only access rules.)

With this, you will now know that the transport to the workstation is secure, and, because you're disciplined enough to use certificates, you know the identity of each one. The login used by the workstations should have read-only access to the repository. Now, you can be reasonably sure (if you are sure of what you have installed into the repo ...) that each workstation will receive a faithful and accurate copy of it. Furthermore, you will know that only those workstations can gain access to the material.

Remember: one way or the other, each workstation should possess a unique SSL/OpenVPN certificate that has been issued only to them. A "login:" prompt should never be presented, nor should login via userid/password ever be possible. Only entities which possess the necessary credential may enter.

jjscott 07-19-2016 06:21 PM

Apache is used to serve up the updates to the workstations. This seems to be a fairly common method for repository access along with NFS.

Based on our current network infrastructure, I'm not sure certificates are really required for securing communication between the workstations and the local repository as the workstations communicate to the local repository server over a encrypted VPN tunnel.

I do like the idea of making the repository read-only.

I still need to understand how to validate the integrity of the patch mirror to my local repository.

sundialsvcs 07-19-2016 09:19 PM

If you are certain that the only way for the workstations to communicate with your server is "over a VPN tunnel," then obviously you need have no further concerns.

I truly "cannot knowledgeably comment any further" with regards to the issue of determining whether-or-not the updates that you have accepted onto your server are, in fact, legitimate ones.

However, I would offer the opinion that: "if your server is satisfied, then your server's clients probably need not further question the server's judgment."

Therefore, it rather seems to me that this technical requirement is de-composed into two separate and entirely-unrelated parts:
  1. The server must be confident that "what it has to offer" is authentic and reliable.
  2. The clients must (merely ...) be confident that that they have obtained a valid copy of what the server has to offer, implicitly trusting(!) that the server knows what it is doing.

jjscott 07-20-2016 07:58 AM

Thanks for the feedback. And yes, I have no concerns with the workstations. My concern is how to validate the integrity of the updates received from the CentOS mirror as it is an unknown quantity and I have no way to verify that the patches they are serving up are valid. I will wait for someone else to respond.

Thanks again

onebuck 07-20-2016 09:24 AM

Moderator response
 
Moved: This thread is more suitable in <CentOS> and has been moved accordingly to help your thread/question get the exposure it deserves.

pingu_penguin 07-20-2016 09:37 AM

I have never used rsync but IMO a good way of verifying the integrity is via the md5sum or sha256 of files.

If the file is tampered , different or possibly corrupt somehow, the md5sums would be different.

McLinux1 07-27-2016 07:49 AM

One option would be to become an official mirror site and as such pull verified source code. Offer 1 server public access (to meet mirror requirements), and have one as private (VPN only) repo server to update machines in your network.

chrism01 08-10-2016 08:28 PM

Actually, you could use yumdownloader
https://access.redhat.com/solutions/10154
http://linux.die.net/man/1/yumdownloader

Note the comment in the 2nd link "Yumdownloader inherits all other options from yum. See the yum(8) man page for more information " http://linux.die.net/man/8/yum
which means it should use gpg check automatically so long as you've got it enabled in your repo defn files.

herkalurk 09-17-2016 04:15 PM

Just wondering if you've considered using the reposync utilities?

https://access.redhat.com/solutions/23016

Similar to apt-mirror it should bring in the GPG keys automatically. I did something similar to what you're doing. I worked for a web hosting company and we had mostly ubuntu, so I had a local mirror of the latest to keep the traffic down on the main internet connection during the actual heavy usage times.


All times are GMT -5. The time now is 04:34 PM.