Hardening your GitHub Enterprise Server

GitHub stores your source code, releases, and a vast amount of invaluable information in issues and pull requests. While GitHub Enterprise Server (GHES), our self hosted solution, provides great security by default, administrators can take additional steps to further harden their appliance. This post will guide you through the most important settings.

Author

Lars Schneider

July 20, 2020

Configure a strong Management Console password

The Management Console is the most powerful GHES administration tool. Amongst other things it allows you to grant people administrative shell access. Establish a strong password to access it and rotate that password on a regular cadence (for example, with every GHES release upgrade).

Review admin permissions

Site admins have significant access rights (e.g. impersonate users or access all private repositories) so consider keeping the number of people in that list small. A good rule of thumb is to have two site admins per time zone that can help regular users on an average working day.

Remember that site admins can create Personal Access Tokens with the site admin scope, for automation. Make sure that these tokens are only used on systems that are thoroughly secured and audited.

Admins with administrative shell access have full rights on the appliance – for example, they can promote themselves to site admins. Every admin should use their own, passphrase protected, SSH key so their activities are auditable. We also recommend using the last section in a public SSH key to describe the owner or function of that key when you add it to the Management Console. Here’s an example:

ssh-ed25519 AAA...key...ZZZ Mona Lisa, Employee ID 123
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
                              SSH key comment section

Try to keep the number of people with administrative shell access as small as possible.

Please note that there are likely two keys that you do not want to remove from the administrative shell access list. First, the key which is used by the GHES replica to connect to the primary in a high availability setup. It is usually called admin-ssh-key. Second, the key which enables the GHES backup server to connect to the primary.

Just like Personal Access Tokens, SSH keys without a passphrase, which are used for automated tasks such as the backup server, should only be used and stored on secure systems.

Admins with virtualization platform, hypervisor, or physical machine access could access GitHub data too. Again, try keeping the number of people in that list small.

Upgrade GitHub Enterprise Server regularly

We strongly recommend that you follow GitHub’s biweekly update cadence, and stay on the latest supported hot-patch release. This ensures that your appliance contains all the latest security fixes. You should be able to apply these hot-patch upgrades (e.g. from 2.20.4 to 2.20.5) during working hours without user interruption, as they do not require downtime.

We also recommend performing full version upgrades (e.g. from 2.20.5 to 2.21.3) at least twice a year. By doing this, you’ll always be running a supported version of GHES – and you’ll have all our latest features too.

Enable two-factor authentication for all users

Consider requiring two-factor authentication (2FA) if your authentication method supports it. If you are using built-in accounts or LDAP accounts, then you can use GitHub’s 2FA facilities. Most SAML providers support 2FA as well and we highly recommend taking advantage of that feature for a more enhanced security posture.

Enable Transport Layer Security (TLS)

Enabling “TLS only” in the Management Console of your appliance ensures that all web traffic from and to the appliance is encrypted. We recommend allowing only modern and more secure TLS protocols 1.2 and 1.3.

Enable subdomain isolation

Enabling subdomain isolation will properly isolate the different GitHub components from one another. This is important as your GitHub Enterprise users can upload any HTML code to their GitHub Pages sites on your appliances. If subdomain isolation is not enabled, this code could be an attack vector that enables access to other GitHub components via cross-site scripting.

Turn on private mode and disable public pages

By turning on private mode in the Management Console, you can ensure that only users with valid login credentials are able to see any content on your appliance.

Additionally, disabling public pages ensures that no information on GitHub Pages is accessible without valid credentials.

Disable anonymous Git read access

Disabling all anonymous Git read access ensures that valid credentials are always required to access your source code.

Review backup server setup and permissions

Run regular backups with the GitHub backup-utils on a dedicated backup machine. Make sure the backup machine runs an up-to-date Linux distribution with the latest security fixes and limit the number of users with access to that system. All GitHub data (source code, releases, issue comments, …) is stored unencrypted by default on the backup host.

Use an outbound proxy server

Your GHES users can configure webhooks that can leak potentially sensitive information (e.g. issue comments) to external web servers if your appliance has Internet access. Configuring an outbound proxy allows you to control what external web servers can be used. Please contact GitHub Professional Services to learn how to setup such a proxy server.

Restrict publicly accessible network ports

Regular GHES users should only be able to access the appliance via the ports HTTPS/443 and SSH/22. A popular way to achieve that is to use a load balancer in front of the GHES appliance which only forwards these ports. In addition, administrators might use a bastion host to connect to the administrative ports of the GHES appliance directly.

A full high availability network layout with backup machine and outbound proxy server might look like this:

Explore more security best practices

Securing your GHES instance is just the first step to protecting your team and your code. Dive into more application security best practices in the cloud with these resources:

Questions? We’re committed to ensuring your GHES instance is secure, so please reach out to Support or request a security audit from our Professional Services team.