防禦伺服器中挖礦病毒

㈠ win2008伺服器中了挖礦病毒，求解答！

不能完全殺干凈的前提下，備份好自己的數據，然後重裝系統，不然這樣耽誤工作真的很麻煩

㈡ 如何評價騰訊雲在防止伺服器可能被植入挖礦木馬，成為

可以安裝一些殺毒軟體在電腦上
如電腦管家一類的，然後一直保持開啟
這樣就可以預防病毒進入到電腦當中了

㈢ 阿里雲windows伺服器如何去除挖礦病毒

找到進程，然後找到他文件路徑，幹掉進程，刪掉文件。
另外找找其他可疑進程，避免病毒有守護進程或者其他隱藏進程

㈣ 如何防範伺服器被攻擊

不管哪種DDoS攻擊，，當前的技術都不足以很好的抵禦。現在流行的DDoS防禦手段——例如黑洞技術和路由器過濾，限速等手段，不僅慢，消耗大，而且同時也阻斷有效業務。如IDS入侵監測可以提供一些檢測性能但不能緩解DDoS攻擊，防火牆提供的保護也受到其技術弱點的限制。其它策略，例如大量部署伺服器，冗餘設備，保證足夠的響應能力來提供攻擊防護，代價過於高昂。

黑洞技術

黑洞技術描述了一個服務提供商將指向某一目標企業的包盡量阻截在上游的過程，將改向的包引進「黑洞」並丟棄，以保全運營商的基礎網路和其它的客戶業務。但是合法數據包和惡意攻擊業務一起被丟棄，所以黑洞技術不能算是一種好的解決方案。被攻擊者失去了所有的業務服務，攻擊者因而獲得勝利。

路由器

許多人運用路由器的過濾功能提供對DDoS攻擊的防禦，但對於現在復雜的DDoS攻擊不能提供完善的防禦。

路由器只能通過過濾非基本的不需要的協議來停止一些簡單的DDoS攻擊，例如ping攻擊。這需要一個手動的反應措施，並且往往是在攻擊致使服務失敗之後。另外，現在的DDoS攻擊使用互聯網必要的有效協議，很難有效的濾除。路由器也能防止無效的或私有的IP地址空間，但DDoS攻擊可以很容易的偽造成有效IP地址。

基於路由器的DDoS預防策略——在出口側使用uRPF來停止IP地址欺騙攻擊——這同樣不能有效防禦現在的DDoS攻擊，因為uRPF的基本原理是如果IP地址不屬於應該來自的子網網路阻斷出口業務。然而，DDoS攻擊能很容易偽造來自同一子網的IP地址，致使這種解決法案無效。

防火牆

首先防火牆的位置處於數據路徑下游遠端，不能為從提供商到企業邊緣路由器的訪問鏈路提供足夠的保護，從而將那些易受攻擊的組件留給了DDoS攻擊。此外，因為防火牆總是串聯的而成為潛在性能瓶頸，因為可以通過消耗它們的會話處理能力來對它們自身進行DDoS攻擊。

其次是反常事件檢測缺乏的限制，防火牆首要任務是要控制私有網路的訪問。一種實現的方法是通過追蹤從內側向外側服務發起的會話，然後只接收「不幹凈」一側期望源頭發來的特定響應。然而，這對於一些開放給公眾來接收請求的服務是不起作用的，比如Web、DNS和其它服務，因為黑客可以使用「被認可的」協議（如HTTP）。

第三種限制，雖然防火牆能檢測反常行為，但幾乎沒有反欺騙能力——其結構仍然是攻擊者達到其目的。當一個DDoS攻擊被檢測到，防火牆能停止與攻擊相聯系的某一特定數據流，但它們無法逐個包檢測，將好的或合法業務從惡意業務中分出，使得它們在事實上對IP地址欺騙攻擊無效。

IDS入侵監測

IDS解決方案將不得不提供領先的行為或基於反常事務的演算法來檢測現在的DDoS攻擊。但是一些基於反常事務的性能要求有專家進行手動的調整，而且經常誤報，並且不能識別特定的攻擊流。同時IDS本身也很容易成為DDoS攻擊的犧牲者。

作為DDoS防禦平台的IDS最大的缺點是它只能檢測到攻擊，但對於緩和攻擊的影響卻毫無作為。IDS解決方案也許能託付給路由器和防火牆的過濾器，但正如前面敘述的，這對於緩解DDoS攻擊效率很低，即便是用類似於靜態過濾串聯部署的IDS也做不到。

DDoS攻擊的手動響應

作為DDoS防禦一部份的手動處理太微小並且太緩慢。受害者對DDoS攻擊的典型第一反應是詢問最近的上游連接提供者——ISP、宿主提供商或骨幹網承載商——嘗試識別該消息來源。對於地址欺騙的情況，嘗試識別消息來源是一個長期和冗長的過程，需要許多提供商合作和追蹤的過程。即使來源可被識別，但阻斷它也意味同時阻斷所有業務——好的和壞的。

㈤ 伺服器集群感染了挖礦木馬該怎麼辦

首先物理隔離，然後請專業的安全廠商來制定判斷病毒類型，然後修補相關系統漏洞，然後利用專殺工具或者殺毒軟體進行查殺

㈥ 怎麼才能防止中NSABuffMiner挖礦木馬呢

防止電腦中木馬可以下載安全軟體進行防護
打開騰訊電腦管家，點擊病毒查殺
裡面有個閃電殺毒，可以快速掃描電腦上的病毒
掃描之後點擊立即處理，就可以清理掉電腦上的病毒了

㈦ 伺服器被rshim挖礦病毒攻擊後 HugePages_Total 透明大頁怎麼都清不掉 一直佔用內存 球球

問題定位及解決步驟：

1、free -m 查看內存使用狀態 ，發現free基本沒了。--> 懷疑是服務有內存泄漏，開始排查

2、使用top命令觀察，開啟的服務佔用內存量並不大，且最終文檔在一個值，且服務為java應用，內存並沒達到父jvm設置上限。按top監控佔用內存排序，加起來也不會超過物理內存總量。查看硬碟使用量，佔用20%。基本排除虛擬內存佔用過大的原因。--->排除服務內存泄漏因素，懷疑mysql和nginx，開始排查

3、因為top命令看 mysql佔用內存也再可控范圍，是否存在connection佔用過多內存，發現並不會，設置最大連接數為1000，最多也不會超過幾M。 nginx佔用一直非常小。但每次最先被kill的基本都是nginx進程。所以排查，但發現無非就是openfiles數量啥的調整。發現也一切正常。且之前niginx可以正常使用的。

4、最為費解的就是 通過free -m 查看的時候 基本全是used，cache部分很少，free基本沒有。但top上又找不到有哪些進程佔用了內存。無解

5、注意到有兩個進程雖佔用內存不多，但基本耗光了100%的cpu。開始想著佔cpu就佔了，沒占內存，現在是內存不不夠導致進程被kill的，就沒注意這點。

6、實在搞不定，重啟伺服器，重啟了所有服務，服務暫時可用，回家。在路上的時候發現又崩了。忐忑的睡覺。

7、早上起來繼續看，這次留意注意了下那兩個佔用高cpu的進程，kdevtmpfsi 和 networkservice。本著看看是啥進程的心態，網路了下。真相一目瞭然，兩個挖礦病毒。

突然後知後覺的意識到錯誤原因：

1、cpu佔用率高，正常服務使用cpu頻率較高的服務最容易最內存超標。（因為在需要使用cpu時沒cpu資源，內存大量佔用，服務瞬間崩潰），然後看top發現剛剛已經佔用內存的進程已經被kill了，所以沒發現內存有高佔用的情況。
2、後面的應用繼續使用cpu時也會發生類似情況，倒是服務一個一個逐漸被kill。

問題點基本定位好了，解決問題就相對簡單很多：
通過網路，google，常見的病毒清除步驟基本都能解決。這兩個挖礦病毒很常見，大致記錄下要點。可能所有病毒都會有這些基礎操作。

① 首先，查看當前系統中的定時任務：crontab -l
我伺服器上有四個定時下載任務 通過wget 和 curl 下載病毒文件，把異常的刪掉。要不然刪了病毒文件還是會下載下來
crontab -r，全部刪除命令（或根據需求刪除定時任務）

② 查找病毒文件 可以全部模糊搜索 清除， 但病毒文件基本都用了chattr +i命令 使用chattr -i filename 後再使用rm -f filename 。可刪除

③ kill 病毒進程，但注意kill了可能馬上就重啟了。因為有守護進程，需要把病毒進程的守護進程也kill掉

④ 檢查是否root用戶被攻擊，可能系統配置信息被更改。

⑤ 最好能理解病毒腳本，通過看代碼看它做了些什麼。針對腳本取修復系統。

㈧ 伺服器上如何清除NrsMiner挖礦病毒

挖礦病毒完整清除過程如下，請在斷網情況下進行：

1.停止並禁用Hyper-VAccess Protection Agent Service服務；

2.刪除C:Windowssystem32NrsDataCache.tlb；

3.刪除C:.dll，若刪除失敗，可重命名該文件為其他名稱；

4.重啟計算機；

5.刪除C:Windowssystem32SysprepThemes和C:WindowsSysprepThemes目錄；

6.刪除C:Windowssystem32SecUpdateHost.exe。

7.到微軟官方網站下載對應操作系統補丁，下載鏈接如下：https://docs.microsoft.com/zh-cn/security-updates/Securitybulletins/2017/ms17-010

8.安裝國內主流殺毒軟體，及時更新至最新病毒特徵庫。

㈨ 電腦中了挖礦病毒 怎麼辦阿 著急 新手小白

ctrl+alt+delete打開任務管理器試一下是否有異常進程暫用cpu

另外可以下載安裝360安全衛士開啟反挖礦防護，有效攔截，並且使用木馬查殺進行全盤查殺

㈩ 中挖礦病毒的表現

故障現象：使用過程中，發現經常有服務無故關閉，登錄伺服器經檢查，發現CPU使用率達到100%。在檢測異常進程中，未發現CPU使用率異常的進程（使用 top、htop 以及 ps -aux 進行檢查），於是報障。

檢測過程：

1.找到他shell腳本對應目錄把目錄或者文件刪除。

2.檢查定時任務是否存在挖礦木馬文件在定時任務中，避免定時運行挖礦木馬文件。

3.添加hosts挖礦病毒訪問對應網站，避免二次訪問並下載。

4.排查liunx命令是否損壞，如損壞下載"procps-3.2.8"並編譯，恢復top等系列命令。

5.檢測進程是否異常。

6.排查入侵入口，例如 redis是否存在弱口令，nginx或者apache上面的網站程序是否存在漏洞，並排查下nginx或者apache日誌審查漏洞所在處。

7.排查ssh登錄日誌。

8.把ssh登錄切換成秘鑰登錄。

9.重啟伺服器，檢查是否進程是否正常。