**:
話說從前些天開始，我的某台伺服器不時會出現外網訪問響應速度變慢的情況，不過內網訪問倒是一直正常。因為並不是核心伺服器，所以一開始我便忽略了監控報警，但是隨著伺服器的可用性越來越差，我不得不騰出手來看看到底發生了什麼。
既然是網路問題，那麼可以在客戶端用「mtr 」檢查一下網路情況：
發現丟包主要發生在最後一跳，接著可以在伺服器用「sar -n dev」檢查頻寬：
明顯可見 tx 流量時不時便會到達一定的高峰，說明伺服器在向外傳送大量資料，導致觸及了頻寬閾值，那麼到底是什麼原因造成的呢？是時候祭出「iptraf」神器了，本例的伺服器中，內網（eth0）正常；外網（eth1）異常：
單獨監控外網網絡卡發現大部分流量都集中在 udp 協議之上：
按照埠監控發現流量主要集中在 udp 的 53 埠上。不過需要說明的是這裡的埠既可能是源埠，也可能是目標埠，並且 iptraf 預設只監控 1024 以下的埠：
監控具體的流量包，發現本地埠在不停的往遠端的埠發請求：
隨便提一下，在上面的確診過程中，我詳細描述了 iptraf 的用法，其實 iftop 也不錯，但是需要說明的是，iftop 預設並不顯示埠資訊（按 p 鍵顯示）。
如果要想知道某個埠執行的是什麼程式，可以使用 lsof 命令：
lsof -i:結果發現可疑程序是通過 jenkins 使用者啟動的，於是我們基本上可以確認攻擊者是通過 jenkins 漏洞攻陷伺服器的，讓我的伺服器成為一台肉雞，進而對目標發起 dns 反射攻擊。既然已經大概搞清楚了被攻擊的原因，那麼最簡單的方法就是把問題伺服器直接下線，重新配置乙個新伺服器，不過有時候事情並不簡單，所以得想辦法恢復它。
因為攻擊者可能會在伺服器上做手腳，所以我們需要仔細排查每乙個存在隱患的地方，比如 cron 配置，還有 /etc/passwd 和 /etc/rc.d/init.d/* 等檔案。此外，一些常用的命令也存在被感染的可能性，如果作業系統是 centos 的話，可以按如下方式確認：
rpm -v $(rpm -qa)它會檢測檔案在安裝後是否發生了變化，如果是，那麼會給出相應的提示，比如：長度變化提示 s，許可權變化提示 m，最重要是的 md5 變化的話提示 5，一旦發現了某個命令可能存在問題，重新安裝它（前提是 yum 沒有被感染）：
yum reinstall即便再小心，也難免百密一疏，木馬可能會死灰復燃，此時可以試試 sysdig 命令：
sysdig -c spy_users它會監控所有的使用者行為，如果木馬有動作，自然也會被記錄下來。
回想整個事件，如果我不在外網伺服器上亂裝服務，或者及時公升級到最新版，那麼可能就不會被黑；如果我沒有忽視監控報警，那麼可能很早就會發現問題。不過出問題並不可怕，更重要的是我們要能理清問題的來龍去脈，別重複摔在同乙個坑里。
記一次阿里雲伺服器被用作DDOS攻擊肉雞
事件描述 阿里雲報警 檢測該異常事件意味著您伺服器上開啟了 chargen dns ntp snmp ssdp 這些udp埠服務，黑客通過向該ecs傳送偽造源ip和源埠的惡意udp查詢包，迫使該ecs向受害者發起了udp ddos攻擊 源ip xx.xx.xx.xx 源port 111 目的port...
記錄一次redis 被挖礦的經歷
專案加入redis,伺服器redis 剛開始想著先全部開發訪問，等快上線了再配置密碼什麼的。沒想到第二天就中招了額。好吧，剛開始查了cpu占有率特高，然後redis 多出bakeup1 bakeup 2.刪除了，再出現。於是就找到了問題的根源了。redis 被挖礦了。第一步，先在 root ssh ...
記錄一次linux部署flask
專案比較趕，來了一次快速開發，環境 nginx gunicorn python3.6.6 flask 開發環境nodejs vue flask python3.6.6 1.安裝python3.6.6 解壓縮tar zxf python 3.6.6 tgz cd python 3.6.6 配置.con...