0x00 前言

如果哪天有hacker進入到了公司內網為所欲為，你一定激動地以為這是一次蓄謀已久的APT，事實上，還有可能只是某位粗線條的員工把VPN資訊洩露在了Github上恰巧被一個好奇的計算機junior發現了而已。

0x01 意識缺失

先貼張圖：

有記者給溧陽衛生局局長撥通電話，該局長面對記者的採訪慌張答道：
“你看到我們發微博的啊？呵呵，你怎麼看到的啊？這個都能看得到啊？！這不可能吧？我們兩個發微博你都能看得到啊？不可能吧？”……

同樣，網際網路企業的員工流動性很強，各自的安全（隱私）意識也參差補齊。龐大的企業難免有些人由於無知或由於偷懶把含有敏感資訊（如資料庫連線串，郵箱賬號，VPN資訊）的程式碼直接丟到github上去。如果這些資訊被有心人看到了，那就能讓駭客花最小的成本，達到APT的效果了。

另附一篇漏洞盒子關於github洩露企業機密資訊的報告：
https://www.vulbox.com/news/detail-15

0x02 反爬機制

於是，我們想實現github程式碼的監控，定製諸多關鍵詞如password，mysql，account，email，希望透過爬蟲程式來實現對github上敏感程式碼的監控，如果有可疑資訊洩露，程式透過郵件通知負責人，負責人去進行二次人工稽核。這樣，能在第一時間發現敏感程式碼的洩露，並及時聯絡提交者進行處理。

期望是美好的，但是在連續高頻訪問若干次github.com之後：

觸發了github的反爬機制，難道專案要流產？

0x03 繞開

機智的樓主想起之前團隊購買了5臺阿里雲機器，何不用阿里雲機器搭建一套代理實現分IP訪問繞開反爬機制？

於是就有了下圖。

一次敏感程式碼爬取的流程：

1. Github爬蟲引擎發起一次爬蟲請求

2. 請求傳送到負載均衡Nginx，Nginx將請求按照同權重的方式轉發到流量轉發Nginx

   注：負載均衡Nginx設定為兩臺，防止出現單點故障。

3. 收到負載均衡Nginx發過來的流量，流量轉發Nginx將請求轉想github.com

4. github.com返回的內容透過Nginx原路返回給Github爬蟲引擎

這樣，對於github.com而言，他看到的是三臺機器在一樣頻率的交替訪問，頻率是原先的1/3，巧的是，這個頻率就不會觸發反爬機制。從而實現了Github爬蟲引擎的連續訪問，效率大大提升。

同時，這套方案的擴充套件性還很強，如果再次被github.com反爬機制封鎖，可以透過平行加流量轉發Nginx機器的方式來實現水平擴充套件。

附負載均衡Nginx的核心配置：

附流量轉發Nginx的核心配置：