Shulou(Shulou.com)06/02 Report--

In the last article, we completed the construction and simple setup of the Gitlab server. In the final summary, we emphasized that it is necessary to set up the common security settings of Gitlab. In this article, I will improve the security settings of the Gitlab server from the following points. Welcome to discuss together.

(1), the length of the password and the number of errors allowed.

Modify the password length of gitlab account and allow the number of password errors. The default password length limit is 8-128bits, and the default number of password errors is 10 (10 locks). Now, the password length is changed to 10-128bits, the number of errors is allowed to be 5, and the locking time is 30 minutes.

Edit / opt/gitlab/embedded/service/gitlab-rails/config/initializers/8_devise.rb using vi

Change config.password_length = 8.. 128 at line 116 to config.password_length = 10.. 128

Change config.maximum_attempts = 10 at line 146to config.maximum_attempts = 5

Change config.unlock_in = 10.minutes on line 149to config.unlock_in = 30.minutes # unlock automatically after 30 minutes. Default is 10 minutes.

Note: changing the password length does not affect existing users, only subsequent new users.

Restart gitlab

# gitlab-ctl reconfigure

At this point, when you re-register or create a new account, you need a 10-digit password, as shown in figure 1.

Figure 1

The password is locked for more than 5 times, but it will not prompt the account to be locked on the login page, even if the correct password is used later, there will be an email reminder. The administrator can perform Unlock operations in Admin Area-> User for the specific users to operate, as shown in figure 2 below.

Figure 2

You can also go to the Rails console to modify it as an administrator.

[root@mail] # gitlab-rails console-e production---- GitLab: 12.5.2 (49482945d28) GitLab Shell: 10.2.0 PostgreSQL: 10.9- -Loading production environment (Rails 5.2.3) irb (main): 001irb 0 > wait for the console to load successfully Use the following command to find irb (main): 015firefly@demo.com' 0 > User.find_by (email: 'firefly@demo.com') = > # irb (main): 017User.find_by 0 > User.unlock_keys # previous versions may have used User.unlock_access= > [: email]

Users can also click unlock in their email, as shown in figure 3.

Figure 3

(2) which SSH key technology to force users to choose and the minimum number of key bits.

Gitlab is configurable for which SSH key technology the user chooses and the minimum number of key bits. The ssh-keygen command allows users to create RSA keys of only 768 bits (unspecified digits default to 2048 bits), which is much lower than recommended by some standard groups (such as NIST in the United States). Some companies that deploy GitLab may need to enforce minimum key strength to meet internal security policies or regulations.

Log in as an administrator account, click "Admin Area"-- > "Settings"-- > "General"-- > "Visibility and access controls", and click "Expand" on the right to expand, as shown in figure 4.

Figure 4

The length of the RSA created using ssh-keygen is 2048 bits by default. If the key length of the created RSA is less than 1024 bits, there is a risk of being cracked, while the DSA must be 1024 bits (DSA keys must be 1024 bits). After the modification is completed according to the actual requirements, click "Save changes" to save, as shown in figure 5.

Figure 5

(3) limit the request rate of Gitlab.

Rate limiting is a common technique used to improve the security and persistence of web applications. For example, a simple script can issue thousands of web requests per second, resulting in an application access exception. Gitlab can also make this restriction to avoid DOS***.

Log in as an administrator account, Admin Area > Settings > Network > User and IP rate limits

Requests that restrict the following three scenarios.

1. Unauthenticated requests (unverified request)

2. Authenticated API requests (authenticated API request)

3. Authenticated web requests (authenticated web request)

The specific settings are shown in figure 6.

Figure 6

(4) Gitlab access log archiving cycle management.

Gitlab uses svlogd to generate log data, which is placed in the / var/log/gitlab directory by default, and then uses the built-in logrotate service to scroll, compress, and eventually delete log data that is not captured by runit. Log-related properties can be configured through / etc/gitlab/gitlab.rb.

[root@mail ~] # vi / etc/gitlab/gitlab.rb logging ['svlogd_size'] = 1024 * 1024 * 1024 # when a single log reaches 1024 MB, it automatically scrolls to the new log file logging [' svlogd_num'] = 300 # retains 300 scrolled log files, and the excess will be deleted by logrotate Keep it longer for audit logging ['svlogd_timeout'] = 24 * 60 * 60 # scroll every 24 hours logging [' svlogd_filter'] = "gzip" # use gzip to compress logging ['logrotate_frequency'] = "daily" # Scroll logging [' logrotate_rotate'] = 300 # keep 300 logs, delete more than 300log, keep longer for audit logging ['logrotate_compress'] = "compress" # Log compression method See 'man logrotate'logging [' logrotate_method'] = "copytruncate" # Log scrolling mode, see 'man logrotate'logging [' logrotate_dateformat'] = "-% Y-%m-%d-%H-%M" # Log file name format, default is numeric, such as access.log.1.gz, now change to date, such as access.log-2019-12-03-16-30.gz

In addition, we can also collect all the Gitlab logs and the system logs of the Gitlab server to the log server for centralized management. The specific configuration will be described in the following log collection chapters.

(5) how to reset the root password of Gitlab account. Administrators who can lose their root passwords certainly won't cook.

To reset the root password, the first step is to log in to the system as root and run a Rails console.

[root@mail] # gitlab-rails console-e production---- GitLab: 12.5.2 (49482945d28) GitLab Shell: 10.2.0 PostgreSQL: 10.9- -Loading production environment (Rails 5.2.3) irb (main): 001irb 0 > user = User.where (id: 1) .first = > # and then Use the following command to reset the root password irb (main): 006root@12358'= > user.password = 'root@12358'= > "root@12358" irb (main): 007main 0 > user.password_confirmation =' root@12358'= > "root@12358" Save and modify irb (main): 008root@12358'= 0 > user.saveEnqueued ActionMailer::DeliveryJob (Job ID: 35e1f3a6-7321-45bd-ba2e-60e4501a93c6) to Sidekiq (mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", # = > true

At this point, root users can log in with the new password they just set.

(6) modify the ssh port of the Gitlab server and do not allow root users to log in directly.

Edit / etc/ssh/sshd_config using vi

Change # Port 22 on line 17 to Port 6688

Change the PermitRootLogin yes of line 38 to PermitRootLogin no

After saving, restart the sshd service (Note: direct login of root users is prohibited if there are ordinary users on the system who can log in except root)

[root@mail ~] # systemctl restart sshd

There are other security settings, such as users using two-factor authentication, which I usually use on the fortress machine, but not on the Gitlab, so I won't elaborate on them here. If you have any other common security settings, please let me know and learn together.

Conclusion: safety is no small matter, and we can't be careless at all. However, the more you think about the security settings, the more troublesome it will be, and everything should be implemented according to the specific circumstances of the company.

The next article will share the rights management of Gitlab, creating groups and repositories using API Token, data backup, recovery, and so on.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.