S
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:
Investigate whether there is an alternative approach that satisfies that requirement without modifying the existing security policy.
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.
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 https://api.github.com/meta , 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.
