Using Github's Public IP Address as Remote URL

Question

My company distributes software that runs on locally installed Ubuntu Virtual Machines. To update the software, we pull our latest code down from Github.

Some IT departments have github blocked on their firewall. One IT guy suggested to us that they would be more open to adding a permanent rule to their firewall if we were able to narrow down the rule to a single external IP rather than the "github.com" domain, which covers a range of public IP addresses.

When I try to find info on github's public IP addresses, I'm always directed to the following page: https://docs.github.com/en/rest/reference/meta

When I follow the suggestions and access the github API to get a list of their public IP addresses, I get a long list of IP ranges in the "git" list. However, it's clear that not all of the addresses in these ranges work as a git remote URL.

Approaching this from a different angle, I pinged www.github.com and got 140.82.112.4. I see this is part of an IP range in the "git" list from the API call (140.82.112.0/20), and it works when I use it in a remote git URL in place of "github.com".

By accident and by messing around, I found that the following IPs worked as remotes. However, when I try adjacent IP addresses (eg. 140.82.112.2), those don't work even though they're in the same range returned by the github API call.

140.82.112.3
140.82.112.4
140.82.112.35
140.82.112.36
140.82.113.3
140.82.113.4
140.82.113.35
140.82.113.36
140.82.114.3
140.82.114.4
140.82.114.35
140.82.114.36

Questions

1. Is there a better list where I can find specific IP addresses that can be used for git remote URLs? Are these subject to frequent change and could they be any addresses in the ranges returned by the github API at any given point in time?
2. Is it reasonable for IT to ask us to limit our pulls to a single IP address? Is that really more secure than using the "github.com" domain?
3. One of the repositories we pull from uses LFS, which pulls from a different domain/IP range. Is there any way to accommodate this when using a single IP in the git remote URL? (this should maybe be a separate post)

Answer 1

The approach is wrong.

The whole point of DNS is that the domain name is what identifies the site or service, and the underlying IP addresses are abstracted away and subject to change. A service is not guaranteed to be uniquely associated with one IP address, nor is an IP address guaranteed to be uniquely associated with one service. Even if you do manage to find such an association, that may change at any point and break your processes.

If the organisation's security policy is to block GitHub for general users, in order to mitigate access to publicly hosted exploit scripts and make accidental publishing of internal code more difficult, that's fine. But security policies should be contextual, taking into account the business requirements of the people and processes that those policies apply to. Security is a service that should aid people in completing their work in a secure manner.

If you have a requirement that a security control impedes, here are the steps you take:

1. Investigate whether there is an alternative approach that satisfies that requirement without modifying the existing security policy.
2. If no alternative can be found, investigate ways in which the security policy can be relaxed or removed with the minimal possible scope and impact.
3. Assess whether the changes require further security mitigations to be put in place, and implement those mitigations.

At each point, you should consider both the reason for the requirement and the reason the security policy was put in place.

For step one, let's look at what you're doing right now:

My company distributes software that runs on locally installed Ubuntu Virtual Machines. To update the software, we pull our latest code down from Github.

Assuming that all of the Ubuntu VMs share an internal network, a potential alternative to using GitHub would be to have your own git server running internally, and configure it as a mirror for the GitHub repository. A firewall exception would only have to be added for that specific server.

If that isn't feasible, e.g. because the VMs don't share private network access, you're onto step 2. Why was the security policy to block GitHub put in place? Maybe it's to limit a potential attacker's access to exploit scripts, or prevent malware from grabbing C2 config / malicious files from raw GitHub content. Maybe it's to prevent accidental upload of internal code. In both cases there's a fairly easy solution: implement a separate security policy specifically for the affected hosts. The firewall should allow access to TCP port 22 on github.com (i.e. allow outbound TCP SYN, and inbound packets related to existing connections) so that SSH-based GitHub access can be used as the remote for the repo. You can automate rule configuration using the meta API, which lists the IP relevant addresses under the git JSON property.

Finally, you're onto step 3. Are there mitigations you could put in place to help bolster security, given the policy changes? If you've set up an internal git server, you might implement additional security procedures and policies, such as only syncing the mirror when a manual process is completed. You could require authentication to read repos from the git server, and pin HTTPS certificates or SSH server keys on the Ubuntu systems. If you're not deploying an internal git server, but instead are unblocking SSH to GitHub on the VMs, you could enable strict host checking and add the GitHub SSH fingerprints to the servers' known SSH hosts list.

You should repeat this set of questions for the LFS part of your requirements, since there may be differences in the requirements, or certain servers may not need access to LFS.