Some questions about the GitLab

I have GitLab installed on Debian 12.5 and have a few questions:
1- Which ports should be open on the server?

2- Can I protect GitLab with AppArmor?

3- Please introduce some tips to increase security?

Thank you.

Depending on your network requirements, tcp/443 (https) and tcp/22 (ssh). HTTPS works for both, for UI login, and git clone operations. SSH works for git clone.

You can for example limit tcp/22 (ssh) to a subnet range for admins only, who need shell login access, and limit Git clone to HTTPS and personal access tokens.

More in Hardening - Operating System Recommendations | GitLab

I’m not sure if AppArmor will be helpful for all cases. More context in Hardening - General Concepts | GitLab

Enable 2FA for all accounts, and disable the default root login. Assign administrative permissions to a small group. Use password managers. And much more below :slight_smile:


Thank you so much for your reply.
I asked about AppArmor because GitLab includes Nginx and PostgreSQL. I want to protect GitLab by Fail2Ban. The Fail2Ban configuration looks like this:


enabled = true
port     = http,https
logpath = /var/log/gitlab/nginx/*error.log
findtime = 600
bantime = 7200
maxretry = 3

Is this configuration correct?

I haven’t (yet) set up fail2ban anywhere, so I don’t know how it’s configuration looks and what is sane.

If you use the repository feature of GitLab you also need to have tcp port 4567 open.

Without having checked @dnsmichi 's links, I want to recommend GitLab’s admin mode.

1 Like

So should the open ports be 80, 443 and 4567?

tcp/4567 is only if you use that feature, and (I forgot to say that) there might me other ports required to use specific features. The same technically goes for tcp/22.

Thanks again.
How can I find a list of these ports?
Do you mean SSH port? If I change the SSH port from 22 to another port, will GitLab have problems?

Obviously, if port 22 is no longer listening, then you need to provide the respective port so that Gitlab would work with SSH. If you change the SSH port to 20022, then you need to use that port for connecting to the server to administer it via SSH, as well as use that same port for Gitlab. Gitlab uses the system configured SSH, so whatever you change affects Gitlab’s use of it.

If you look at the links @dnsmichi provided, you would see in the hardening section information related to Firewall Rules, and the associated ports. If you are a sysadmin, you should also know that using tools like ss or netstat you can find out what ports are listening on your system that relate to Gitlab and which ones you need to open up based on the Gitlab documentation posted here already.

The Gitlab documentation has pretty much all the information you need. I suggest reading it.


Thank you so much for your reply.
So GitLab looks at the sshd_config file and automatically takes the port from there. Is it correct?

When I enter the IP address of the GitLab server, I enter the login page. Isn’t it better to define a username and password to see this page?

Thank you.

I was mainly thinking about simply not giving SSH access to GitLab. As most/all (?) git work can be done over HTTP(s) (I haven’t tried, so I’m unsure about the details) you won’t need SSH access to do that, but maintenance of GitLab will be hard without some other way (on another network interface, or - if GitLab is running in some kind of virtual machine - some virtualisation command) to enter, but then we’re leaving the context of what GitLab needs.

Since the login page requires someone to give a username/password to actually login to Gitlab, why do you think it should be protected by yet another login/password before the page is accessible for you to then login again? I don’t understand why you ask such a thing, unless you are trolling here?

I suggest you read the Gitlab documentation thoroughly, as well as take a look at some Linux SysAdmin howto’s because some of the questions asked here are basic sysadmin stuff that you should already know.

Sure. Do you not set a password to enter the admin panel of your website (something like WordPress)? If you haven’t done it, I suggest that you definitely do it. This will make hackers not see your panel directly and reach their goal (SQL Injection) later.

I’m really thankful foe the links.
There were recommendations in the documentation to increase the security of the operating system itself and the SSH and Nginx services, but nothing about PostgreSQL!

A more general advice for hardening servers: Do not expose service ports, unless explicitly necessary (ssh, https). Do not expose database services, work locally. For monitoring purposes, a local agent that connects to the database using a unix socket can be considered more secure than a monitoring server with a service login via remote connection. As additional context, I maintained an OSS monitoring tool for 10+ years before joining GitLab.

As an attacker, a network port scan using nmap and friends immediately unveils potential attack vectors. Some environments could use default user/password settings, and boom, I am in the database, running a dump, or maybe even manipulating data.

The PostgreSQL server bundled with GitLab in the Omnibus package uses the Unix socket by default, and not a TCP socket listening on localhost. If you want to bring your own PostgreSQL server, it is advisable to use Unix sockets too, unless your database ops team provides a PostgreSQL cluster which they maintain and secure.

If you prefer to maintain your own PostgreSQL instance or cluster for hardening, and scaling, you can also do that. Configuring PostgreSQL for scaling | GitLab

I would defer here to more PostgreSQL security generic documentation for specific hardening.

Hardening can also mean that your environment blocks the usage of specific libraries or software being installed. If you encounter a blocker with GitLab Omnibus here, I’d suggest opening an issue in the project / omnibus-gitlab · GitLab to discuss with the engineering team.

Thanks for the context. I do not have fail2ban running with GitLab Nginx, but with defaults on my Linux VMs. The configuration looks good.

No, GitLab assumes that port 22 is being used, which is the default on a Linux distribution. If you want to use a different port, you can configure it using the gitlab_shell_ssh_port setting for the Omnibus package.

The login page requires a username and password, and does not need extra security. HTTPS is suggested, I highly recommend disabling HTTP/80 everywhere.

What you can and should do, is changing the administrative account password immediately, and add 2FA. Store the password in a password safe, and do not use the account to make administrative changes. Instead, assign user roles for administrative tasks, and use admin mode (recommended by @grove above). Sign-in restrictions | GitLab

It is also advisable to connect GitLab auth with an existing SSO/LDAP/AD instance, and ensure that permissions and groups are synced. Review the options in GitLab authentication and authorization | GitLab Disable user signup on the instance, too.

Suggest reviewing all sections in Secure your installation | GitLab

1 Like

I’m really thankful for your advices. Your answers raised a few questions for me:
1- About the ports, I left only ports 80, 443, 4567 and SSH port open. Is this good?

2- I have changed the SSH port from 22 to another number. So I have to change gitlab_shell_ssh_port to that number or I have to leave port 22 open on the firewall. OK?

3- I used guidance to harden Nginx. If I want to use HTTPS for GitLab server, I need to define SSL keys files in /etc/gitlab/gitlab.rb file. Do these two settings not overlap?

4- There are many articles on the Internet for securing PostgreSQL. Do these not interfere with GitLab? Can you recommend a good article on securing PostgreSQL?

No idea?


Should be OK.

Not necessary, it’s enough to specify the port in your .ssh/config file, for example:

HOST mygitlab
PORT 20022
USER mygituser

assuming port 20022 is the new port.

Define SSL keys? What do you mean? If you want to use SSL, you configure a certificate and certificate key. Easiest is just to put the files in /etc/gitlab/ssl and name them after your server, for example and

You can find these easily enough with Google. These are not specific to Gitlab, but rather specific to PostgreSQL since it’s only Postgres settings being changed to secure it. You will have to be careful though, especialllyif you edit pg_hba.conf and remove Gitlab-specific configuration. If you aren’t sure what you are doing, best leave it as it is and don’t mess with it. Or even better, instead of using the bundled PostgreSQL that comes with Gitlab, use an external PostgreSQL server and configure that properly instead as per the Gitlab documentation here: Configure GitLab using an external PostgreSQL service | GitLab but again, configuration of PostgreSQL is PostgreSQL specific so suggest googling to find out how to do this or find a Database Administrator who has experience of such a topic.


Thank you so much for your helps.
1- You used USER mygituser. What if the GitLab server has multiple users?

2- Regarding SSL please take a look at You should also change Nginx settings (nginx[‘ssl_certificate’], nginx[‘ssl_certificate_key’], etc.). I have already made changes to Nginx configuration via Hardening - Configuration Recommendations | GitLab. Will these changes that I have already made interfere?

It was an example. You cannot have multiple SSH users with Gitlab, since the git user is just git. Every user will always user to connect.

If you are just configuring the certificate, then nothing will happen with any other config options that you have changed. Also, it’s better to follow the official Gitlab documentation than some howto on the internet. The official documentation for configuring SSL certs: Configure SSL for a Linux package installation | GitLab

1 Like