上一篇我们完成了Gitlab服务器的搭建以及简单设置，在最后总结时有强调Gitlab常用安全设置很有必要。这一篇我将从以下几点来完善Gitlab服务器的安全设置，欢迎共同探讨。
（1）、密码长度以及允许密码输错次数。
修改gitlab账户的密码长度以及允许密码输错次数，默认密码长度限制是8-128位，且默认允许输错密码次数为10次（10次锁定），现将密码长度修改为10-128位，允许输错次数为5次，锁定时间30分钟。
使用vi 编辑 /opt/gitlab/embedded/service/gitlab-rails/config/initializers/8_devise.rb
将位于116行的config.password_length = 8..128改为config.password_length = 10..128
将位于146行的config.maximum_attempts = 10改为config.maximum_attempts = 5
将位于149行的config.unlock_in = 10.minutes改为config.unlock_in = 30.minutes #30分钟后自动解锁，默认是10分钟
注意：修改密码长度不影响已存在用户，只影响后续新建用户。
重启gitlab
# gitlab-ctl reconfigure
此时再注册或创建新账户时就要求密码长度是10位了，如图1所示。
图1
密码输错5次以上被锁定，但并不会在登录页提示账号被锁定，即使后面用了正确的密码，但会有邮件提醒。管理员可在Admin Area -->User具体要操作的用户，进行Unlock操作，如下图2所示。
图2
也可以使用管理员身份进入Rails控制台修改。
[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):001:0> 等待控制台加载成功后，使用以下命令查找 irb(main):015:0> User.find_by(email: 'firefly@demo.com') => #<User id:4 @firefly> irb(main):017:0> User.unlock_keys #之前版本可能用的是User.unlock_access => [:email]
用户也可以在自己邮件中点击解锁，如图3所示。
图3
（2）、强制用户选用哪种SSH密钥技术以及最小密钥位数。
Gitlab对于用户选用哪种SSH密钥技术以及最小密钥位数是可配置的。ssh-keygen命令允许用户创建只有768位的RSA密钥（不指定位数创建默认为2048位），这远远低于某些标准组（如美国NIST）的建议。而部署GitLab的一些公司可能需要强制实施最小密钥强度，以满足内部安全策略或法规。
以管理员账户登录，点击"Admin Area" -->"Settings" -->"General" --> "Visibility and access controls"，点右侧的"Expand"展开，如图4所示。
图4
使用ssh-keygen默认创建的RSA长度为2048位，如若创建RSA的密钥长度小于1024位就有被破解的风险，而DSA必须是1024位（DSA keys must be 1024 bits），按实际需求修改完成后，点“Save changes" 保存，如图5所示。
图5
（3）、对Gitlab的请求速率做限制。
速率限制是一种常用的技术，用于提高web应用程序的安全性和持久性。例如，一个简单的脚本每秒就可以发出数千个web请求，导致应用出现访问异常。Gitlab也可以作此限制来避免DOS***。
以管理员账户登录，Admin Area > Settings > Network > User and IP rate limits
用于限制以下三种场景的请求。
1、Unauthenticated requests（未经验证的请求）
2、Authenticated API requests（经过身份验证的API请求）
3、Authenticated web requests（已验证的web请求）
具体设置如图6所示。
图6
（4）、Gitlab访问日志归档周期管理。
gitlab使用svlogd来生成日志数据，日志默认都放在/var/log/gitlab目录，再使用内置的logrotate服务来滚动、压缩并最终删除runit未捕获的日志数据。可通过/etc/gitlab/gitlab.rb来配置日志相关属性。
[root@mail ~]# vi /etc/gitlab/gitlab.rb logging['svlogd_size'] = 1024 * 1024 * 1024 # 单个日志达到1024 MB时就自动滚动到新的日志文件 logging['svlogd_num'] = 300 # 保留300个已滚动的日志文件，超过的将被logrotate删除，保留久一点便于审计 logging['svlogd_timeout'] = 24 * 60 * 60 # 每24小时滚动一次 logging['svlogd_filter'] = "gzip" # 使用gzip压缩 logging['logrotate_frequency'] = "daily" # 按天滚动 logging['logrotate_rotate'] = 300 # 保留300个日志，超过300以后的被删除，保留久一点便于审计 logging['logrotate_compress'] = "compress" # 日志压缩方式，see 'man logrotate' logging['logrotate_method'] = "copytruncate" #日志滚动方式， see 'man logrotate' logging['logrotate_dateformat'] = "-%Y-%m-%d-%H-%M" #日志文件名格式，默认是数字，如access.log.1.gz，现在改为日期，如access.log-2019-12-03-16-30.gz
另外，我们还可以将Gitlab日志以及Gitlab服务器的系统日志全部收集到日志服务器上集中管理，具体配置将放在后续日志收集章节中讲。
（5）、如何重置Gitlab账户的root密码。能丢失root密码的管理员肯定是不会炒菜的。
想要重置root密码，第一步以root用户登录到系统，并运行一个Rails控制台。
[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):001:0> user = User.where(id: 1).first => #<User id:1 @root> 然后，使用以下命令重置root密码 irb(main):006:0> user.password = 'root@12358' => "root@12358" irb(main):007:0> user.password_confirmation = 'root@12358' => "root@12358" 保存修改 irb(main):008:0> user.save Enqueued ActionMailer::DeliveryJob (Job ID: 35e1f3a6-7321-45bd-ba2e-60e4501a93c6) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", #<GlobalID:0x00007f40a408acc8 @uri=#<URI::GID gid://gitlab/User/1>> => true
这时root用户就可以使用刚设置的新密码登录了。
（6）、修改Gitlab服务器的ssh端口以及不允许root用户直接登录。
使用vi 编辑/etc/ssh/sshd_config
将17行的#Port 22 改为Port 6688
将38行的 PermitRootLogin yes 改为PermitRootLogin no
保存后，重启sshd服务（注：禁止root用户直接登录的前提是系统上有除root以外的可登录的普通用户）
[root@mail ~]# systemctl restart sshd
还有其他一些安全设置，如用户使用双因子身份验证等，我一般在堡垒机上才用，在Gitlab上基本不用，所以在此不再做详细说明，若大家还有其他常用安全设置 ，可告知一下，共同学习。
总结：安全无小事，一点都不能大意。但是，越想安全设置就越麻烦，一切要结合公司具体情况实施。
下一篇将分享Gitlab的权限管理、使用API Token创建组和仓库、数据备份、恢复等。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
