初創公司如何避免服務器被攻擊

前不久和小夥伴們討論了一個基礎的安全問題：一個朋友開的公司的服務器集羣被黑了，攻擊者在機器上安裝了遠程操做程序——被肉雞了。但通過討論後發現，機器的最基本的防禦都沒有。這無異於大姑娘在街上裸奔——就算長得再醜也最終會被爆的。本文就這個討論，總結一下在工程實踐上，服務器集羣的「入門級安全防禦「該如何實施。

 

安全第一

本文僅僅針對初創公司，沒有資源創建完善運維團隊的場景。本文介紹的方法都是一個開發手工能夠搞定的。

服務器是如何被攻破的

線上服務器，不管是自建機房仍是雲服務，管理員都不太可能直接接觸到機器自己。大多數時候管理者都是經過網絡與服務器通信。這就涉及到了服務器必定要打開一些端口才能容許這種交互。做爲管理員是經過網絡使用服務器的資源，做爲用戶也是如此。做爲攻擊者固然也能夠經過一樣的方式來訪問主機。畢竟都是大門嘛，你能進，他也能進。

所以，從攻擊者的角度，最低成本的攻擊方式是用腳本自動掃描，看看一個服務器（IP）到底開了多少端口。若是是使用默認端口的話，攻擊者就能夠猜想這個端口背後的程序是否可能有漏洞。好比Web的默認端口是80，而80背後大機率可能就是nginx或者apache。而這些軟件的某個版本存在漏洞或者配置不當，就會形成極大的安全隱患。好比apache若是配置不當，攻擊者能夠順着apache用https://foo.com/../../etc 這樣的url訪問到很是敏感的信息，從而爲下一步的提高權限、作任意的操做、安裝黑客工具作第一步準備。而若是攻擊者發現3306這種端口是開的，就會直接嘗試用弱口令或者Mysql特定版本的漏洞來嘗試訪問Mysql，而後幹他任何想幹的事情。

衆多端口中，SSH服務的安全風險至關的高，一旦被攻破，攻擊者能夠任何執行器想要執行的指令。而其餘的協議，好比3306連通，背後是mysql，攻擊者就必須按照mysql的通信協議來嘗試各類機會，大部分狀況只能對mysql自己作一些事情，但不能對機器作一些事情。但不管哪種，對於被攻擊者來講都是巨大的損失。輕則全部機器要reset，從新安裝部署；重則一個公司完全信譽掃地，垮掉（好比大量用戶信息丟失，被篡改）。

So, take it seriously.

那麼如何防禦呢？

總體思路

整個防禦的思路就是，將生產服務器的對外網的接觸面下降到最少。將全部的管理類訪問收到以跳板機爲中心的SSH主機上。其他的訪問只能訪問生產機器提供的服務自己。

 

網絡隔離

下面一一講解。

限制開放端口

任什麼時候候，只要是生產服務器，投入使用以前必須限制開放端口。你須要開放什麼服務，就只開放那個服務必要的端口。例如，對於一個web服務來說只須要打開80/443兩個端口。具體作法是，使用iptable命令來DROP掉除了必要端口外全部的INPUT的網絡請求。

生產機之間最好也能夠作這種封閉，可是若是運維資源實在緊張，能夠只作對外出口的限制。畢竟，若是攻擊者已經能夠進入到生產機內網環境隨意SSH了，就已經算是攻破了。

絕對不要把數據庫的端口對外網打開。我已經見過太多案例，開發者在服務器上裝了個mongo或者mysql就無論了，結果被別人整庫拖庫的事情。數據庫屬於內部服務，根本就沒有打開的必要。

配置時切記不要把管理用的SSH端口給封住了，這樣管理員本身也訪問不了主機就尷尬了……

關閉沒必要要的對外主動鏈接

生產服務通常也不須要主動發起對外的網絡鏈接。一些例外的狀況好比支付服務，微信受權服務，第三方的數據統計分析服務等。這些狀況能夠方便的經過IP/域名的白名單來處理。除此以外，生產機不該該可以主動發起任何對外網的訪問。

修改默認端口

攻擊者會嘗試根據端口猜背後的程序是什麼。好比對於端口22，攻擊者會猜這是個SSH，而後會嘗試弱口令等方式來攻擊。若是你把SSH的端口隨便改爲一個好比4328，那麼攻擊者就得花更多的力氣才能作這個猜想。若是攻擊者不是針對你的話，也就不會廢這個功夫猜了，畢竟不設防的機器多的是，何須死磕你的。

其餘服務的端口也能夠相似處理，好比MySql，Redis等。可是值得注意的是，由於瀏覽器訪問Web時，若是不明確在URL裏寫端口，就會用80/443，而且端口還可能影響Cookie的有效性。因此Web的默認端口是不方便改的。

學會使用SSH

在*nix環境下，SSH是標準的遠程主機訪問的協議。全部對集羣的管理都要使用SSH，所以對SSH的配置要格外留神。

老是使用生產級別的SSH認證方式

SSH支持至關多的認證方式。只有兩種我認爲是能夠在生產中使用的：

• 高強度公鑰私鑰對（好比用RSA-1024）

• Kerberos

高強度公鑰私鑰由於配置方便，用得更普遍。而Kerberos須要比較複雜的配置，通常常見於大型企業內部。

不要使用任何基於密碼的認證方式。若是你用了密碼就要記住，爲了記住這個密碼必定是有某個含義的，這就爲字典攻擊提供了條件。而且密碼在網絡上傳輸也是很是不安全的。反覆輸入密碼會進一步增長密碼被記錄的機率。記得，你和服務器之間隔着互聯網，你永遠不知道有誰在中間。

2015年已經有消息報道RSA-1024能夠經過暴力破解，可是耗費了至關大的計算資源。目前看，對於小公司RSA-1024仍是安全的。可是你能夠輕易地改用RSA-2048來產生公鑰私鑰對，指數級提升破解的難度。

RSA-1024的意思是用RSA算法產生長度爲1024bit的公鑰私鑰對。越長的公鑰私鑰對越難被暴力破解。破解RSA-2048比RSA-1024須要的計算量大概大2^32倍。詳情見這裏。

做爲入口要定時更換認證key

若是是採用公鑰私鑰對做爲SSH的認證，建議每一個季度/每半年更換一次公鑰私鑰對。如若是採用Kerberos做爲SSH的認證，建議每一個季度/每半年換一次密碼。之因此這樣作是由於，這個更換的週期會遠遠小於常規暴力破解的時間。

訪問生產資源時老是通過跳板機

也許你有不少服務器主機，可是若是運維資源部不足，無法很好的挨個配置主機的SSH端口設置，能夠只開一臺機器的SSH端口到外網，容許遠程訪問。這臺對外網打開SSH的機器俗稱「跳板機「。

爲何使用跳板機呢？這是由於能夠在一臺機器上作全部的安全防禦配置。在公司過規模小的時候，一我的就能夠手工把全部的訪問權限在這一臺機器上搞了。

利用跳板機：

• 可使用SSH的ProxyCommand。它可讓你訪問遠程主機時必須通過跳板機。這樣整個集羣只須要在跳板機上開到外網的SSH端口了。

• 可使用SSH的端口轉發（Local Port Forwarding和Remote Port Forwarding）。這個功能能夠容許你用SSH包裝其餘協議的數據，因而你能夠通過跳板機的SSH端口訪問其餘主機的mysql、redis、mongodb……

  關於端口轉發，這裏推薦一個特別好的工具叫作SSL Tunnel Manager

固然，成熟的技術團隊中，除了Lead、DBA和Ops，其餘人不該該有權限訪問生產服務。要作到這一點須要補充不少基礎設施（好比帶有Audit和ACL的生產數據庫查詢、比較方便的查詢生產服務的log）。本文主要說小團隊的低成本的事情，就不展開了。

確保你的軟件源安全可靠

也許不少人對2015年的XCodeGhost不陌生。一些開發人員經過非官方渠道下載了XCode開發App。其中攜帶的被惡意篡改的基礎庫和App一塊兒被打包，發佈，最終安裝在用戶的設備上。這個問題可不必定只發生在XCode上。

天天開發者build程序都要使用各類開發工具，從外網各個地方下各類代碼包。怎麼確保這些東西就不出問題？最基礎的防禦是：老是從軟件提供的官方渠道下載。就算再慢，被牆，也要想辦法。若是技術手段沒法約束，就必須行政手段強行禁止國內的各類下載網站下開發軟件。

但若是訪問這官方服務時斷時續，或者比較浪費帶寬（帶寬費用相對比較貴），就要考慮自建「鏡像」。像Artifactory就是很好的工具，能夠充當內網的maven鏡像庫。

關注入口相關程序的漏洞

網絡請求從鏈接到被執行，須要通過

• 硬件（固件）

• 操做系統

• 系統庫（好比openssl）

• 程序庫（好比jdk和依賴的各類jar）

• 你的程序

時刻留意這個鏈條上的漏洞信息（新聞/社交網站討論等），尤爲是你開放的端口的對應服務的漏洞（好比開了443要特別留意操做系統、openssl和nginx的漏洞）。大多數時候漏洞比較偏門，或者說只有學術研究價值，這種能夠忽略。但若是發現有漏洞的討論已經很是廣泛，就說明這個漏洞的影響至關大，而且很是容易被利用，抓緊時間升級和修復。

若是你用的是雲服務，通常廠商都會有對受影響設施升級的公告，可能會形成停服務。請時刻留意。

管好你的祕鑰

用了很強的認證方式後，還要記得好好保管。要是不注意，本身把私鑰泄露到了公開的地方，再強的算法也保護不了你。任何狀況下不要在網絡上傳遞祕鑰。若是要傳遞給別人，請用紙和筆。

此外，全部的私鑰，密碼最終都會記錄在你本身的電腦上。因此若是你去上個廁所，別人偷偷跑過來從你的沒鎖的電腦上拿到私密的信息，那麼以上全部的防禦就都沒有用了。所以，離開座位時請老是鎖上你的屏幕。

若是用Mac，推薦「觸發角」功能。配置好後，鼠標一推就鎖屏了。

總結

作到本文所說的全部策略，其實並不能保證絕對的安全。而且還有許多安全問題本文並無考慮，好比注入攻擊，CRSF，帶有密碼的服務配置，內網服務API的ACL，DDoS，社工學騙管理密碼，短信炸彈等。

可是按照本文作了，你的服務器毫不會被攻擊者以毫無成本的掃描直接攻破。攻擊者必須針對你作定製的攻擊方案纔有可能成功。這會極大的提升攻擊成本。若是你的公司仍是個不起眼的小公司，那麼基本上不會招眼——太不划算了。

值得注意的是，初創公司就算再怎麼預算緊張，也必定要有人來負責運維。就算是開發頂一下也好，兼職也好，但機器不能沒人管，無論是自建集羣仍是雲服務。只有這我的存在，上面說的這些事情纔有期望能夠作好。

隨着業務的擴大，服務商業價值增長，隨之而來的就是更多的關注和更多的有針對性的攻擊的風險。這時候，也許公司已經能夠僱得起一個專心作安全的團隊，購買防禦軟件/硬件，或者能夠找到一個靠譜的安全領域的合做機構，來處理更復雜的安全攻擊。

祝好運！