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 I see this is part of an IP range in the "git" list from the API call (, 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., those don't work even though they're in the same range returned by the github API call.


  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)
  • 2
    What is their justification for just wanting to unblock a single IP address? I'm not sure I follow the thinking, there. GitHub's public services operate across a wide range of IP addresses, for a variety of legitimate reasons (e.g. load balancing, providing regional locality) and those IP addresses are subject to change at any moment. The whole point of DNS is that it abstracts away the underlying IP addresses from the name you use to identify them.
    – Polynomial
    Sep 23 '21 at 1:31
  • 1
    The whole approach is wrong in my opinion. If the company wants to have github blocked, it wants to have github blocked. It might want to do an exception for a specific repository so that updates can be pulled for this one, but such exceptions cannot be done at the level of IP addresses. Maybe you should rethink your update process too, away from just checking out some repository and moving to properly signed updates. Sep 23 '21 at 4:54
  • 1
    The threat they assume by keeping GitHub unblocked is still there when they unblock one IP address. I assume they are concern about insider leaks. Unblocking one IP address doesn't solve this problem.
    – defalt
    Sep 23 '21 at 8:02
  • It's the equivalent of using the inode number to identify the file, instead of the filename...
    – ThoriumBR
    Sep 23 '21 at 13:30

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.

  • 2
    Thank you for the detailed response! Sounds like limiting the rule to a single IP isn't a logical approach for several reasons. The VMs are all on different networks, so I don't think the internal git server is feasible. But we can look into limiting the rules by host, integrating the SSH fingerprints and using the meta API to automate the rule. Thanks for the suggestions! Sep 23 '21 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.