將pdflush端口80上的防止阿帕奇從重新啓動

預賽： + CentOS 5的 +的Plesk 10.4.4更新＃35將pdflush端口80上的防止阿帕奇從重新啓動

問題：在Plesk中的新的域/主機的添加/變更，它通常將寫新建或更新apache vhost配置文件，然後重新啓動apache服務。更新重寫似乎沒有問題，文件中沒有錯誤，但是由於端口80不可用，最近Apache關閉後無法重新啓動，因此通過「netstat -tulpn ...」進一步檢查顯示以下內容...

Proto Recv-Q Send-Q Local Address    Foreign Address    State  PID/Program name 
tcp  0  0 :::80      :::*      LISTEN  25794/PDFLUSH 
tcp  0  0 :::443      :::*      LISTEN  25794/PDFLUSH

你可以看到，將pdflush佔據較高的進程ID，而是坐在兩個80和443，防止從阿帕奇回來了。我不得不手動獲取PID，然後再次運行「service httpd start」以啓動apache，然後發出kill。

在我的搜索中，我看到有人被黑客入侵，但我可以找到任何類似的症狀，老實說，我不知道要在日誌或特定的日誌文件中尋找什麼。我也聽說這可能是內存失敗的症狀，但我不知道如何在生產服務器上測試內存。

請任何幫助，將不勝感激，我的心下沉，每次我得到一個短信，服務器再次下降！

編輯它通過簡單地增加一個子域，但是這一次我能夠運行PS -aux迅速之前殺將pdflush實例，並帶回了Apache的再次發生......

阿帕奇... ./PDFLUSH -b service.config

試圖搜索出的，現在的位置......

來源

2012-07-05 oucil

好消息是，我發現的罪魁禍首，壞消息是它是「C99」，只要做一個谷歌，你會發現一個悠久的歷史。現在真正的樂趣開始了，服務器已經紮根？

對於那些有類似的問題，並認爲，即使它使用的不是「將pdflush」以外的其他名稱可能是一樣的，只是做一個

查找/無功/網絡/虛擬主機-name將pdflush

找出小混蛋隱藏的地方。我在我的一個共享主機客戶站點發現了我的網站，這些網站深埋在webroot內的dir樹中。

來源

2012-07-10 16:30:45 oucil

的您已包含輸出爲高度懷疑：

您看到該計劃被稱爲PDFLUSH用大寫的所有字符。這似乎是企圖逃避偵查; pdflush（全部小寫）是處理將髒內存頁寫回到磁盤的合法內核線程的名稱。任何合法的程序都不會使用這樣的名字。
合法的pdflush沒有任何網絡功能 - 它根本與網絡無關。這似乎是一個Web服務器，但沒有這樣一個名稱的Web服務器存在。除非您明確安裝了一個具有該不幸名稱的自定義Web服務器，否則您有問題。

您是否嘗試過使用netcat或Telnet客戶端連接到這兩個端口？這可能會讓你知道發生了什麼。

就測試系統的內存而言，memtest86是目前實際上的標準工具。儘管如此，失敗的記憶通常以隨機崩潰的形式出現 - 你所看到的似乎太具體。

來源

2012-07-05 23:48:45 thkala

這是我的懷疑，但我發現很難得到關於這種入侵的任何其他背景信息（至少在搜索中使用PDFLUSH），我只看到一個參考，它有點舊。因爲這是一臺生產服務器，所以它在恢復時需要時間敏感，所以我沒有花時間輪詢端口。是否有任何可以指向我的日誌文件，其中包含有關該服務的任何相關啓動或停止詳細信息，可能指向服務文件的位置？ – oucil 2012-07-06 00:28:03

你相信*你看到的任何日誌文件？ – thkala 2012-07-06 01:38:27

好吧，沒有清除服務器，從頭開始，如何才能確定這個小混蛋？有沒有系統保護的日誌文件，它將無法操作？我禁用了root訪問權限，限制對特定IP的SSH訪問權限，只使用強密碼並且不允許在沒有SSL的情況下連接到服務器，所以很少猜測我的密碼並欺騙我的IP，我無法想象他們已經能夠得到太多....他們可以嗎？無論如何，建議將不勝感激，迄今爲止我們所做的一切都是同意的，這可能是某種形式的黑客攻擊。 – oucil 2012-07-06 04:32:24

將pdflush端口80上的防止阿帕奇從重新啓動

回答

相關問題