使用 Docker 和 Traefik 搭建 GitLab（后篇）

印度阿三17 2021-02-07

展開全文

本文使用「署名 4.0 國際 (CC BY 4.0)」許可協(xié)議，歡迎轉(zhuǎn)載、或重新修改使用，但需要注明來源。署名 4.0 國際 (CC BY 4.0)

本文作者: 蘇洋

創(chuàng)建時間: 2019年04月10日統(tǒng)計字?jǐn)?shù): 7143字閱讀時間: 15分鐘閱讀本文鏈接: https:///2019/04/10/gitlab-was-built-with-docker-and-traefik-part-2.html

使用 Docker 和 Traefik 搭建 GitLab（后篇）
前篇文章提到了要介紹一些 GitLab 安全配置上的問題，本篇文章就來簡單聊聊如何加固你部署在公網(wǎng)上的 GitLab 代碼倉庫。

問題背景
一般來說，我們建議在內(nèi)網(wǎng)環(huán)境下使用 GitLab 這類包含大量敏感信息，相對大型、復(fù)雜的軟件，因為網(wǎng)絡(luò)的隔離，天然可以減少許多“可***面”。

如果需要外部使用，則推薦使用 “專用隧道” 等方式提供定向的流量訪問途徑。

前文提到過，這次遇到的訴求恰恰是：

不能使用專有的流量隧道
不能搭建在內(nèi)網(wǎng)，要提供公網(wǎng)訪問方式
沒關(guān)系，見招拆招即可。

分析***基本面
在暫時不考慮內(nèi)鬼作祟的情況下，對應(yīng)用進(jìn)行環(huán)境加固?？梢韵葘梢允艿?**的場景進(jìn)行簡單的分類：

系統(tǒng)層（宿主機(jī)環(huán)境）
網(wǎng)絡(luò)層（具備流量交互的場景）
應(yīng)用層（軟件運行環(huán)境、相關(guān)配置）
用戶層（軟件使用日常場景）
考慮篇幅、文章針對性兩個原因，本文重點介紹“應(yīng)用層”安全加固。

系統(tǒng)加固
網(wǎng)上關(guān)于系統(tǒng)加固的資料有不少，我之前的文章中也有零碎的提過，感興趣可以自行翻看。為了方便你進(jìn)行搜索，這里簡單提一下常規(guī)手段：

針對敏感端口進(jìn)行日志審計。
修改系統(tǒng)敏感端口，比如 SSH 端口，并考慮按需開啟。
限制登錄用戶和用戶登錄方式（比如堡壘機(jī)、或者秘鑰認(rèn)證），并創(chuàng)建普通用戶取代 root 進(jìn)行日常操作。
購買云安全服務(wù)，并對接監(jiān)控告警。
網(wǎng)絡(luò)加固
網(wǎng)絡(luò)加固的內(nèi)容比較雜，我們從下面五個點展開。

加密流量傳輸
網(wǎng)絡(luò)加固這里有一個簡單原則，除了本機(jī)流量外，但凡可以使用 SSL 加密的流量，一律使用 SSL 加密模式進(jìn)行傳輸，包括：

跨主機(jī)之間的系統(tǒng)調(diào)用
應(yīng)用和數(shù)據(jù)庫之前的調(diào)用
雖然不進(jìn)行 SSL 化配置，部署和編碼成本會有所提高，如果機(jī)器資源緊張，還可能影響一些性能，并且還可能帶來額外的費用問題：
企業(yè)使用的SSL證書按年付費，價格十分昂貴。
不過如果你覺得購買證書費用太過高昂，也可以使用自簽名證書來解決問題。
實際上，部署 SSL 所帶來的各種成本放到長期來看，都是可以忽略不計的一次性投入，但是安全風(fēng)險問題是基礎(chǔ)和底線，不值得為此冒險。

避免公開的 DNS 解析
提到網(wǎng)絡(luò)服務(wù)，其中有一點經(jīng)常被忽略：DNS 解析。

如果你的應(yīng)用只針對少數(shù)人提供服務(wù)，不妨考慮不在公網(wǎng) DNS 上進(jìn)行解析，僅通過綁定 Hosts 提供服務(wù)。

配合 Traefik 的服務(wù)發(fā)現(xiàn)功能，如果對方不知道你的服務(wù)域名，即使通過 IP 掃描到你的站點，請求后得到的結(jié)果也只有 404 Not Found。

添加網(wǎng)絡(luò)請求驗證
上一條措施，不進(jìn)行公網(wǎng)域名暴露，已經(jīng)可以解決一大部分掃描器的嗅探。但是面對有針對性的***，這招就不靈光了。

此時，建議在我們的 Web 系統(tǒng)前添加一層基礎(chǔ)的用戶驗證：Baisc Auth。

使用 Traefik 添加這層驗證很容易，只需要下面兩行簡單的聲明：


- "traefik.gitlab.frontend.auth.basic=${BASIC_AUTH}"
- "traefik.gitlab.frontend.auth.basic.removeHeader=true"

這兩行配置的作用是：

第一行告訴程序，我們要使用 Basic 認(rèn)證，認(rèn)證的用戶名密碼是什么。
第二行配置則告訴程序，這個認(rèn)證僅僅在 Traefik 流量進(jìn)入的時候使用，不要繼續(xù)傳遞給應(yīng)用程序，避免帶來其他麻煩（比如 Confluence 這類應(yīng)用會將 HTTP 請求頭中的 authorization 用作系統(tǒng)登錄憑據(jù)）。
當(dāng)然，這里同樣需要創(chuàng)建一個 .env 環(huán)境配置文件，比如：

BASIC_AUTH=soulteary:$apr1$rgGAffTk$vDZ1tL03og0nZ8XlCfdv80


如果你好奇這段代碼是如何生成的，可以在使用 Docker 搭建 Confluence 這篇文章中找到答案。

下面給出一個相對完整的配置參考：

labels:

"traefik.enable=true"
GitLab Web 服務(wù)
"traefik.gitlab.frontend.auth.basic.removeHeader=true"
"traefik.gitlab.frontend.auth.basic=${BASIC_AUTH}"
"traefik.gitlab.port=80"
"traefik.gitlab.frontend.rule=Host:gitlab.${BASEHOST}"
"traefik.gitlab.frontend.entryPoints=http,https"
"traefik.gitlab.frontend.headers.SSLProxyHeaders=X-Forwarded-For:https"
"traefik.gitlab.frontend.headers.STSSeconds=315360000"
"traefik.gitlab.frontend.headers.browserXSSFilter=true"
"traefik.gitlab.frontend.headers.contentTypeNosniff=true"
"traefik.gitlab.frontend.headers.customrequestheaders=X-Forwarded-Ssl:on"
"traefik.gitlab.frontend.passHostHeader=true"
"traefik.gitlab.frontend.passTLSCert=false"


**使用浮動 IP**
如果對方不光使用侵入的方式進(jìn)行***，還想讓你暫時無法正常使用系統(tǒng)，比如對你進(jìn)行令人發(fā)指的 DDoS ***。

作為被***方，可以使用 浮動IP 的方式，在遭遇***的時刻，降低切換 IP 的成本，快速金蟬脫殼，這里配合支持動態(tài)加速的 CDN 服務(wù)效果更好。

**應(yīng)用層**
應(yīng)用層做的事情也比較雜，我們來慢慢說起。

**用戶側(cè)流量加密**
建議系統(tǒng)不提供任何 HTTP 流量，防止用戶側(cè)流量被劫持利用。

所有出公網(wǎng)流量一律走 HTTPS，如果你也使用前文提到的 Traefik ，那么這個事情默認(rèn)就是做好了的（參考剛剛的配置）。

**對接 Prometheus 性能監(jiān)控**
如果你對可用性有很高的要求，可以參考官方文檔，對接 Prometheus 性能監(jiān)控，如果你對Prometheus沒有概念，可以先瀏覽一下官方的在線示例，這部分展開聊可以寫好幾篇，先略過。

**處理 CI Runner**
CI 雖然作為呼之即來、揮之即去的“附加部分”，但是實際上也可以因為“頻繁調(diào)用”而拒絕服務(wù)，或者因為不恰當(dāng)?shù)?CI 配置，而泄露敏感信息，或者作為***跳板，傷害到線上業(yè)務(wù)代碼。

對于 GitLab CI Runner 運行監(jiān)控，推薦使用 timoschwarzer/gitlab-monitor ，不過如果你在系統(tǒng)中配置好了推送消息，項目數(shù)量比較少的時候，一個手機(jī)Push過來，或許更方便迅捷。

對于 CI Runner ，要確定盡可能少的提供 SHELL 模式的 Runner，多提供容器模式的 Runner，減少 Runner ***到宿主機(jī)的可能。

另外 Runner 可被觸發(fā)的分支和倉庫要做額外的限制，盡可能避免過度頻繁的 Runner 執(zhí)行，讓宿主機(jī)器“過勞死”。

最后，Runner 中使用的環(huán)境變量和配置信息，需要使用加密環(huán)境變量的方式進(jìn)行獲取，而非明文寫死在配置文件代碼中。GitLab 這部分做的很好，有興趣的小伙伴可以了解一下。

**監(jiān)控 GitLab SSH 端口**
因為我們對用戶提供了 SSH 的方式去 Clone 和 Push 代碼，所以作為開放訪問的 SSH 端口就面臨被***的可能。

下面是一臺長期運行在公網(wǎng)的代碼倉庫的端口日志（cat logs/sshd/current），我節(jié)選了比較有代表性的一部分日志，并隱去了具體時間：

Invalid user admin from 179.53.182.234
Invalid user user from 183.89.94.13
Invalid user admin from 36.236.233.142
Invalid user admin from 143.255.154.219
Invalid user admin from 85.57.5.107
Invalid user ubnt from 85.57.5.107
Invalid user admin from 85.57.5.107
Invalid user admin from 156.223.73.14
Invalid user support from 200.145.6.88
Invalid user admin from 152.231.118.191
Invalid user user from 171.228.172.27
Invalid user admin from 27.66.79.45
Invalid user Admin from 117.0.57.69
Invalid user admin from 14.207.231.218
Invalid user gitlab from 121.71.20.66
Invalid user admin from 183.157.173.121
Invalid user guest from 37.214.104.206
Invalid user admin from 197.32.190.120
Invalid user Administrator from 125.34.196.43
Invalid user Administrator from 125.34.196.43
Invalid user \243\254git from 112.87.206.54
Invalid user \243\254git from 112.87.206.54
Invalid user admin from 116.118.104.96
Invalid user admin from 14.186.202.33
Invalid user admin from 113.172.217.15
....


可以看到有大量掃描器在默默的替你關(guān)注者你的系統(tǒng)安全，毫不夸張的說，一旦你漏出破綻，你的機(jī)器、你的應(yīng)用就不歸你使用了，這類掃描器的擁有者便能光明正大的隨意用你的機(jī)器、玩你的系統(tǒng)、欺負(fù)你的用戶…

如何避免這類惡意的掃描器呢？其實寫一段簡單的日志檢測腳本就能解決很大一部分問題。

比如下面這段腳本，在參考 這篇文章 后，我結(jié)合實際情況，更新了它，讓腳本能夠處理 GitLab 的日志格式。

#!/bin/bash

允許錯誤嘗試的最大次數(shù)

LIMIT=3

要進(jìn)行分析的日志文件

SCAN_LOG="/data/gitlab/logs/sshd/current"

封禁IP記錄

LOGFILE="/data/gitlab/logs/bad_gay_22_port.log"

要匹配的日志格式: 2019-04-10_12

TIME=$(date ' %Y-%m-%d_%H')

掃描當(dāng)前 GitLab 日志，找出所有的錯誤登錄行為，并進(jìn)行計數(shù)，篩選出超過允許次數(shù)的 IP

BLOCK_IP=$(grep "$TIME" "$SCAN_LOG"|grep "Invalid user"|awk '{print $(NF-3)}'|sort|uniq -c|awk '$1>"$LIMIT"{print $1":"$2}')
for i in $BLOCK_IP
do
IP=$(echo $i|awk -F: '{print $2}')

驗證該IP是否已經(jīng)被封禁

iptables-save|grep INPUT|grep DROP|grep $IP>/dev/null
# 如果未被封禁，則進(jìn)行封禁操作
if [ $? -gt 0 ];then
    iptables -A INPUT -s $IP -p tcp --dport 22 -j DROP
    NOW=$(date ' %Y-%m-%d %H:%M')
    echo -e "$NOW : $IP">>${LOGFILE}
fi

done


將上面的內(nèi)容保存為 gitlab_ssh.sh ，然后賦予腳本可執(zhí)行權(quán)限。

chmod 755 gitlab_ssh.sh && chmod  x gitlab_ssh.sh
接著將腳本放到 GitLab 應(yīng)用目錄中（或者任意你方便管理的地方），舉個例子： /data/gitlab/gitlab_ssh.sh。

最后將腳本添加到 crontab 中，以10分鐘為粒度執(zhí)行 (結(jié)合自己情況進(jìn)行調(diào)整)。

echo "/10 * root /data/gitlab/gitlab_ssh.sh" >>/etc/crontab


不出意外，往后如果還有這類掃描器，他們最多只能撲騰個10分鐘左右。

至于這個腳本的戰(zhàn)績，可以通過查看 /data/gitlab/logs/bad_gay_22_port.log 日志文件來進(jìn)行了解：

2019-04-10 19:33 : 113.172.217.15
2019-04-10 19:33 : 14.186.202.33


**監(jiān)控界面登錄**
前面已經(jīng)在網(wǎng)絡(luò)層添加了訪問授權(quán)，但是如果授權(quán)密碼泄露，被針對性***，比如在界面/應(yīng)用接口層面進(jìn)行弱口令掃描，那么又該如何處理呢。

配合 fail2ban 可以減少這類事情的影響，下面給出一段參考腳本。

[Init]
maxlines = 6

[Definition]

The relevant log file is in /var/log/gitlab/gitlab-rails/production.log

Note that a single failure can appear in the logs up to 3 times with just one login attempt. Adjust your maxfails accordingly.

Example fail - clone repo via https

#Started GET "/" for 10.0.0.91 at 2016-10-25 00:01:24 0200
#Processing by RootController#index as HTML
#Completed 401 Unauthorized in 69ms (ActiveRecord: 23.7ms)

Example fail - login via GUI

#Started GET "http://chmielu/test.git/info/refs?service=git-upload-pack" for 10.0.0.91 at 2016-10-25 00:01:09 0200
#Processing by Projects::GitHttpController#info_refs as /

Parameters: {"service"=>"git-upload-pack", "namespace_id"=>"chmielu", "project_id"=>"test.git"}

#Filter chain halted as :authenticate_user rendered or redirected
#Completed 401 Unauthorized in 50ms (Views: 0.8ms | ActiveRecord: 8.1ms)

failregex = ^Started . for <HOST> at .<SKIPLINES>Completed 401 Unauthorized

ignoreregex =



**用戶層**
用戶層面其實問題不多，如果你能確定你可以堅持使用以下措施的話：

關(guān)注官方版本更新和 changelog，及時更新應(yīng)用版本，減少 XSS 、CVE 漏洞問題。
進(jìn)行最小權(quán)限授予，減少錯誤授權(quán)帶來的風(fēng)險。
在系統(tǒng)設(shè)置中設(shè)置所有項目都是 private 的，避免某云平臺的事故重演。
避免添加過多的全局 Admin 角色，針對項目群組和項目進(jìn)行管理員設(shè)置。

僅允許使用 SSH 方式進(jìn)行代碼 Clone 和 Push，推薦使用秘鑰認(rèn)證的方式進(jìn)行系統(tǒng)交互。
盡可能減少與外部系統(tǒng)的交互，比如導(dǎo)入外部倉庫，僅支持你覺得必要的來源；比如服務(wù)調(diào)用，僅調(diào)用你覺得安全可靠的。
關(guān)閉默認(rèn)注冊方式，使用邀請制度，或者使用 SSO/LDAP 方式進(jìn)行注冊。
根據(jù)實際情況進(jìn)行用戶頻率限制（系統(tǒng)功能）。
要求你的用戶使用隨機(jī)生成的強(qiáng)密碼，并定期更換。
**最后**
使用容器在公網(wǎng)環(huán)境搭建 GitLab 就先介紹到這里，性能監(jiān)控部分，等把 WordPress 的坑填完，再細(xì)聊吧。

來源：https://www./content-4-850101.html