天天躁夜夜躁狠狠躁2021 ,四房播播网址

防護(hù)WordPress網(wǎng)站中的SEO投毒

知云網(wǎng) — Sat, 04 Apr 2020 06:11:20 +0000

WordPress是一個(gè)知名的開(kāi)源內(nèi)容管理系統(tǒng)（CMS），用于創(chuàng)建網(wǎng)站和個(gè)人博客。根據(jù)預(yù)計(jì)，目前有35%的網(wǎng)站使用這一知名CMS，如此之大的比例也使其成為了威脅參與者的理想目標(biāo)。WordPress平臺(tái)存在的一大弱點(diǎn)就是允許攻擊者破壞網(wǎng)站的安全性，而這個(gè)弱點(diǎn)會(huì)隨著網(wǎng)絡(luò)安全形勢(shì)的嚴(yán)峻而更加惡化。

平時(shí)，我們經(jīng)?？梢钥吹接泄粽哚槍?duì)CMS平臺(tái)發(fā)起攻擊，這已經(jīng)不再是一個(gè)新聞。威脅行為者已經(jīng)發(fā)現(xiàn)，對(duì)網(wǎng)站進(jìn)行攻擊可以成為一種攻破組織資產(chǎn)的有效手段。這篇文章首先介紹我們?cè)谝巴庥^察到的Payload示例，列舉出針對(duì)WordPress的不同類型的攻擊，深入揭秘攻擊者是如何利用非法獲取的管理員訪問(wèn)權(quán)限、API、Alfa-Shell部署和SEO投毒來(lái)實(shí)現(xiàn)攻擊。
利用非法獲取的管理員訪問(wèn)權(quán)限攻擊WordPress站點(diǎn)
這種方法需要使用管理員的帳戶和密碼訪問(wèn)使用WordPress架構(gòu)的站點(diǎn)。攻擊者可能會(huì)利用漏洞，或使用泄露的密碼及弱密碼實(shí)現(xiàn)登錄，這一過(guò)程可以通過(guò)向目標(biāo)站點(diǎn)的/wp-login.php發(fā)送POST請(qǐng)求來(lái)實(shí)現(xiàn)。

使用弱密碼登錄的攻擊示例：

攻擊者進(jìn)行暴力破解時(shí)所使用的密碼：

成功登錄后，具有管理員訪問(wèn)權(quán)限的攻擊者就能操作多個(gè)選項(xiàng)，攻擊者通常會(huì)進(jìn)行如下操作：

1、安裝帶有后門的自定義主題；

2、安裝插件以上傳文件。

在成功獲得管理員特權(quán)后，通常會(huì)進(jìn)行這兩種操作，此外攻擊者還可以選擇更改管理員密碼，或創(chuàng)建新的管理員帳戶。最常用的方法是使用公共的主題，利用遠(yuǎn)程代碼執(zhí)行（RCE）漏洞來(lái)嵌入自定義的后門。除此之外，還有一些文件上傳的插件，攻擊者可以借助這些插件直接上傳Payload。

應(yīng)該注意的是，我們經(jīng)常見(jiàn)到一個(gè)后門會(huì)部署具有相似功能的另一個(gè)后門。當(dāng)Payload/命令/代碼被編碼在Cookies或POST數(shù)據(jù)中時(shí)，使用GET或POST請(qǐng)求就可以完成部署。解碼的邏輯位于此前部署的后門內(nèi)部。在部署后，攻擊者將收到新上傳組件的URL。

在被攻擊的WordPress網(wǎng)站中實(shí)現(xiàn)搜索引擎優(yōu)化（SEO）投毒

攻擊者利用被攻擊的WordPress網(wǎng)站做的另一類行為是搜索引擎優(yōu)化SEO優(yōu)化投毒。我們發(fā)現(xiàn)，已經(jīng)部署的PHP腳本會(huì)在GET請(qǐng)求中接收關(guān)鍵字。

WordPress“搜索引擎”：

腳本首先檢查User-Agent是否與以下正則表達(dá)式中的其中一條相匹配，并檢查$_SERVER[“REMOTE_ADDR”]（發(fā)出HTTP請(qǐng)求的參與者的IP地址）的反向DNS查詢是否包含Google子字符串。如果發(fā)現(xiàn)，則將$isbot變量設(shè)置為1。

部署腳本的片段：

如果$isbot不為0，則使用相同的關(guān)鍵字，對(duì)硬編碼的URL地址發(fā)出另一個(gè)HTTP請(qǐng)求。

部署腳本的片段：

如果返回的文本長(zhǎng)度小于1000個(gè)字符，則使用必應(yīng)（Bing）搜索引擎執(zhí)行其它查詢，并將與特定正則表達(dá)式匹配的結(jié)果附加到$text后面。

攻擊者使用的文本：

如果再次執(zhí)行相同的查詢，就會(huì)返回最終的HTML頁(yè)面，并將其保存在服務(wù)器上。

最終頁(yè)面：

如果未設(shè)置$isbot，并且HTTP_REFERER包含類似于Google、Bing或Yahoo的字符串，則將其重定向到另外一個(gè)網(wǎng)站。

部署腳本的片段：

發(fā)表虛假或誤導(dǎo)性文章

遭到入侵的WordPress網(wǎng)站也可能會(huì)被用于發(fā)布虛假或誤導(dǎo)性文章，其中的內(nèi)容往往很少，或者沒(méi)有真實(shí)的細(xì)節(jié)。取而代之的是，攻擊者往往會(huì)使用引人注目的標(biāo)題，并編造吸引人注意的故事。

在遭到入侵的站點(diǎn)上發(fā)布的故事示例：

從以上示例可以看出，被攻擊的站點(diǎn)發(fā)布了帶有明顯語(yǔ)法錯(cuò)誤或煽情報(bào)導(dǎo)的故事。通常，這些文章的內(nèi)容難以被理解。攻擊過(guò)程是通過(guò)WordPress的XML-RPC應(yīng)用程序編程接口（API）來(lái)實(shí)現(xiàn)的，該接口可以傳輸數(shù)據(jù)并執(zhí)行多項(xiàng)任務(wù)，例如上傳新文件、編輯和發(fā)布帖子。

POST /xmlrpc.php和metaWeblog.newPost（左側(cè)）以及帖文內(nèi)容（右側(cè)）示例：

攻擊者可以使用POST /xmlrpc.php和metaWeblog.newPost，這允許將博客內(nèi)容直接（甚至遠(yuǎn)程）發(fā)布到WordPress網(wǎng)站。

針對(duì)WordPress站點(diǎn)的安全建議

上面提到的示例，只是目前已知攻擊者會(huì)使用的一些技術(shù)。實(shí)際上，如果沒(méi)有保證良好的安全性，易受攻擊的WordPress站點(diǎn)很容易遭到攻擊者的濫用。為了降低被攻擊的風(fēng)險(xiǎn)，我們建議用戶使用雙因素認(rèn)證（2FA）插件來(lái)防止憑據(jù)濫用，同時(shí)建議掃描未修復(fù)的漏洞。用戶和網(wǎng)站管理員可以采用以下防護(hù)措施：

1、部署基本的安全防御措施，以減少網(wǎng)站的攻擊面；

2、禁用或刪除過(guò)時(shí)的或易受攻擊的插件；

3、使用虛擬補(bǔ)丁程序來(lái)修復(fù)補(bǔ)丁不可用的漏洞，特別是針對(duì)需保障業(yè)務(wù)連續(xù)性的系統(tǒng)更要關(guān)注這一點(diǎn)；

4、應(yīng)用權(quán)限最小化原則；

5、定期將CMS更新到最新版本，包括CMS中使用的插件。

wordpress內(nèi)存占用大和負(fù)載堵塞的解決辦法

知云網(wǎng) — Sun, 16 Feb 2020 07:18:38 +0000

在使用知名建站CMS系統(tǒng)wordpress建設(shè)的網(wǎng)站，在網(wǎng)站運(yùn)營(yíng)過(guò)程中站長(zhǎng)們經(jīng)常出現(xiàn)一個(gè)主要問(wèn)題：wordpress內(nèi)存占用大和網(wǎng)站負(fù)載堵塞，出現(xiàn)這種情況，會(huì)導(dǎo)致網(wǎng)站運(yùn)行速度緩慢，將會(huì)嚴(yán)重影響到網(wǎng)站優(yōu)化、網(wǎng)站運(yùn)營(yíng)等各種問(wèn)題。

下面知云網(wǎng)就wordpress內(nèi)存占用大和網(wǎng)站負(fù)載堵塞提出以下幾個(gè)解決辦法。

經(jīng)研究和測(cè)試表明，wordpress系統(tǒng)排除google字體等代碼問(wèn)題，后仍然出現(xiàn)負(fù)載堵塞達(dá)到100%，或者內(nèi)存占用達(dá)到90%以上。

這時(shí)可以從以下五個(gè)方面解決：

一、 改善wordpress網(wǎng)站所在服務(wù)器的php-fpm性能調(diào)整。

安裝好 WordPress后，在瀏覽器中操作一段時(shí)間后，便無(wú)法再使用 WordPress，并出現(xiàn)了錯(cuò)誤提示信息。在服務(wù)器后臺(tái)開(kāi)啟 WordPress 的調(diào)試模式后，刷新瀏覽器，得到了更詳細(xì)的錯(cuò)誤信息，分析后得知是無(wú)法連接數(shù)據(jù)庫(kù)的問(wèn)題。在服務(wù)器中一看，MYSQL 數(shù)據(jù)庫(kù)不知什么時(shí)候掛掉了。查看系統(tǒng)內(nèi)存使用情況，發(fā)現(xiàn)總共 2G 的內(nèi)存，現(xiàn)在使用了1600M+。在一看系統(tǒng)并沒(méi)有交換分區(qū)。原因一下就很清楚了，是系統(tǒng)內(nèi)存不足導(dǎo)致 MYSQL 崩潰。為系統(tǒng)添加了 1G 的交換文件作為虛擬內(nèi)存后，數(shù)據(jù)庫(kù)是不崩潰了，但 WordPress 使用一段時(shí)間后反應(yīng)就相當(dāng)慢，并且服務(wù)器的 SSH 連接也幾乎不能使用。綜合前面的情況可知，現(xiàn)在的問(wèn)題是 WordPress 使用過(guò)程中占滿了系統(tǒng)內(nèi)存，系統(tǒng)開(kāi)始使用交換文件，而交換文件性能不足導(dǎo)致。

在控制臺(tái)重啟服務(wù)器后，繼續(xù)在瀏覽器中使用 WordPress，并且在后臺(tái)實(shí)時(shí)監(jiān)控系統(tǒng)內(nèi)存的使用情況。發(fā)現(xiàn)進(jìn)行更換主題，安裝插件等一些操作時(shí)，系統(tǒng)內(nèi)存使用量會(huì)大量增長(zhǎng)，并且很快會(huì)超出物理內(nèi)存大小，造成訪問(wèn)緩慢的問(wèn)題。多方查找資料后，發(fā)現(xiàn)是 php-fpm 的問(wèn)題。

php-fpm 的 FastCGI 進(jìn)程一旦加載就不會(huì)釋放，當(dāng)其工作完成后，并不會(huì)釋放給系統(tǒng)內(nèi)存，而是休眠于 FastCGI 系統(tǒng)池中，等待下一次被喚醒。就造成了內(nèi)存不斷上升的問(wèn)題。我一直用的是 php-fpm 默認(rèn)配置，這個(gè)配置對(duì)于我來(lái)說(shuō)可能有點(diǎn)不合適，需要修改配置文件。

php-fpm 的相關(guān)參數(shù)
pm：表示使用那種方式，有兩個(gè)值可以選擇，就是static（靜態(tài)）或者dynamic（動(dòng)態(tài)），默認(rèn)為dynamic。
pm.max_children：靜態(tài)方式下開(kāi)啟的php-fpm進(jìn)程數(shù)量。
pm.start_servers：動(dòng)態(tài)方式下的起始php-fpm進(jìn)程數(shù)量。
pm.min_spare_servers：動(dòng)態(tài)方式下的最小php-fpm進(jìn)程數(shù)量。
pm.max_spare_servers：動(dòng)態(tài)方式下的最大php-fpm進(jìn)程數(shù)量。
區(qū)別：

如果pm設(shè)置為 static，那么其實(shí)只有 pm.max_children 這個(gè)參數(shù)生效。系統(tǒng)會(huì)開(kāi)啟設(shè)置數(shù)量的 php-fpm 進(jìn)程。

如果pm設(shè)置為 dynamic，那么 pm.max_children 參數(shù)失效，后面 3 個(gè)參數(shù)生效。系統(tǒng)會(huì)在 php-fpm 運(yùn)行開(kāi)始的時(shí)候啟動(dòng) pm.start_servers 個(gè) php-fpm 進(jìn)程，然后根據(jù)系統(tǒng)的需求動(dòng)態(tài)在 pm.min_spare_servers 和 pm.max_spare_servers 之間調(diào)整 php-fpm 進(jìn)程數(shù)。

php-fpm 參數(shù)調(diào)整
對(duì)于內(nèi)存大的服務(wù)器（8G）以上，指定靜態(tài)的max_children實(shí)際上更為妥當(dāng)，因?yàn)檫@樣不需要進(jìn)行額外的進(jìn)程數(shù)目控制，會(huì)提高效率。對(duì)于小內(nèi)存的服務(wù)器，動(dòng)態(tài)方式會(huì)結(jié)束掉多余的進(jìn)程，可以回收釋放一些內(nèi)存。

這時(shí)選擇動(dòng)態(tài)模式，調(diào)整后的配置如下：

運(yùn)行模式：pm = dynamic
允許創(chuàng)建的最大子進(jìn)程數(shù)：pm.max_children = 20
起始進(jìn)程數(shù)（服務(wù)啟動(dòng)后初始進(jìn)程數(shù)量）：pm.start_servers = 5
最小空閑進(jìn)程數(shù)（清理空閑進(jìn)程后的保留數(shù)量）：pm.min_spare_servers = 2
最大空閑進(jìn)程數(shù)（當(dāng)空閑進(jìn)程達(dá)到此值時(shí)清理）：pm.max_spare_servers = 10
每個(gè)子進(jìn)程在處理了多少個(gè)請(qǐng)求數(shù)量后重啟pm.max_requests = 300

比如寶塔服務(wù)器控制面板，有PHP性能調(diào)整界面，可以直接調(diào)整。

然后重啟 php-fpm，系統(tǒng)內(nèi)存使用在二百多兆。操作 WordPress 一段時(shí)間后，系統(tǒng)內(nèi)存使用量不斷增長(zhǎng)，最終穩(wěn)定在1100M+。負(fù)載堵塞沒(méi)有出現(xiàn)，問(wèn)題得以解決。

二、修改WP的內(nèi)存配置大小。

如果你的空間支持.ini，可以通過(guò)修改php.ini實(shí)現(xiàn)，以下三種方法任選其一，把memory_limit修改為128M或更高。

1. 首先在public_html 目錄創(chuàng)建文件 php.ini，添加以下代碼：
memory_limit = 128M
然后在根目錄下修改.htaccess文件，添加下面代碼：
suPHP_ConfigPath /home/username/public_html/

2. 同樣是修改php.ini先在網(wǎng)站根目錄下，建立一個(gè)php.ini文件，寫(xiě)入下面這句：memory_limit = 128M
接著再到網(wǎng)站根目錄下修改.htaccess這個(gè)文件，寫(xiě)入下面這句：
SetEnv PHPRC /home/host1/public_html/usr1/
(unix path to the directory where php.ini is)
(keep the slashes)
注：以上代碼中的”128M”可根據(jù)需要適當(dāng)調(diào)整。

3. 通過(guò)服務(wù)器后控制面板臺(tái)直接修改

三、 WordPress中的插件和主題過(guò)多。

WordPress程序自身占用的內(nèi)存，加上插件，主題會(huì)導(dǎo)致更多的內(nèi)存占用。

1. 刪除沒(méi)有啟用的插件，并減少不必要插件的使用。

2. 如果服務(wù)器內(nèi)存本身就很小，就不要使用占用大量資源的插件，比如All in OneSEO,Broken Link Checker,Yet Another Related Posts Plugin,NextGen Gallery這些大容量插件。

3. 另外，沒(méi)有使用的主題也應(yīng)該刪除。這樣做不僅能夠減少內(nèi)存占用過(guò)高的問(wèn)題，也是增加網(wǎng)站安全性的一種基本措施。

四、限制wordpress定時(shí)功能

wordpress的定時(shí)發(fā)布功能真的很好，但是也非常耗費(fèi)資源的，如果不需要，建議還是限制一下，我們需要在wp-config.php文件中限制。

define(‘DISABLE_WP_CRON’, true);

五、限制自動(dòng)保存和副本數(shù)據(jù)

wordpress的自動(dòng)保存是一個(gè)很好的功能，但是也很占用資源，目前部分wordpress模板已經(jīng)限制了自動(dòng)保存的次數(shù)等等，默認(rèn)時(shí)候的WP會(huì)自動(dòng)給我們保存草稿以及副本添加入數(shù)據(jù)庫(kù)中，不信的話你到POST數(shù)據(jù)表看看是不是有很多記錄，而我們的文章并沒(méi)有這么多。這就是自動(dòng)添加的，我們需要限制自動(dòng)版本和限制自動(dòng)保存草稿。

define (‘WP_POST_REVISIONS’, 0); define(‘AUTOSAVE_INTERVAL’, 600);

這樣可以限制一下自動(dòng)保存的時(shí)間。

或者直接關(guān)閉自動(dòng)保存：

remove_action(‘pre_post_update’, ‘wp_save_post_revision’);
add_action(‘wp_print_scripts’, ‘disable_autosave’);
function disable_autosave() {
wp_deregister_script(‘autosave’);
}

參考資料：
CSDN博主「Peigenzi」的原創(chuàng)文章：https://blog.csdn.net/Peigenzi/article/details/73506298