雖然 DR 自己的個人網站是使用 Drupal 架設，並且在近期因著版本升級的緣故，又陸續找時間做了許多調整措施。然而回想起來，其實在自己過去的工作經驗裡，接觸過最多的 CMS 是 WordPress，其次則是 Joomla。而這些經驗多數是來自於 DR 幾年前在雲端主機商做工程師的期間，因為虛擬主機（shared hosting）服務是公司的主力產品之一，並且有許多租戶是在虛擬主機上使用 CMS 來架設網站。
或許有人會有所預估，儘管虛擬主機是多租戶共用同一個網頁、資料庫及郵件伺服器，不過在給定的帳號權限區隔及資源配額下，如果租戶的網站配置有所缺失，那麼最多影響的是租戶自己的網站，而不會損害到整個基礎設施。然而實情並非如此，在各種可能發生的損害狀況裡，以下會列舉幾個還算相對單純的案例。
首先 WordPress 網站被反覆、密集地嘗試登入其管理員帳號，某些情況下有可能會產生顯著的伺服器 CPU 負載升高。特別是在資源超賣比例較高的伺服器上，可能會造成服務卡頓，使得監控到狀況的工程師必須要有所干預。儘管 WordPress 自身存在一些解決方案，能夠減少甚至於消除被嘗試侵入的風險。然而現實上就是連督促每位租戶要保持 WordPress 網站程式的安全性更新，都不是這麼地容易，更遑論要求每位租戶必須自行對網站部署進一步的安全措施。
於是 DR 當時所構思的應對方式，是編寫腳本，從 Apache 的日誌辨別出是否存在連續多次登入 WordPress 失敗的的 IP 位址，再直接加入到防火牆封阻名單中。此舉並非全面性的常態措施，而是在經過判斷認為有必要實施時再人工啟動。腳本程式也存在著白名單以及 IP 地理位置等權衡的判斷，以減少一般正常用戶不小心地多次登入失敗而被封阻的機會。事後來看，這可能是以相當粗略的手段，實作出某種意義上類似於網頁應用程式防火牆（web application firewall，WAF）的防禦機制。
另一方面，由於在我們的虛擬主機服務中，PHP 的 mail() 函式是直接可用的，所以租戶的網站被找到途徑用於發送大量垃圾或惡意信件，則是另一種也真實存在的情形。而這種情形有可能會造成郵件伺服器壅塞、以及信譽的降低，以致伺服器 IP 被列入到某個黑名單中。當 DR 初次探究這個狀況時，驚訝地發現公司並無實現任何自動化的封阻措施，一切都是等到郵件佇列出現壅塞告警時，才會有工程師試圖做些什麼（這也表示若是沒出現佇列壅塞就不會有人發現）。於是研究了一陣，Exim 郵件伺服器的設定經過改寫後，就能夠很便利的封禁特定租戶的 mail() 發送行為。然後利用雖然實作得很粗糙、但可用的自動化腳本，監控租戶發信頻率及數目，若達到指定閥值便封禁租戶的郵件發送，同時對工程師發出告警。
在 DR 當時的工作經驗裡，儘管沒有做過全盤的統計，但印象中最常見會被用於發送垃圾信的網站，是以 WordPress 或 Joomla 所架設的網站為大宗。至於發送垃圾信的具體來源，則例如網站上的帳號註冊表單。有許多網站實際上並沒有意圖提供訪客註冊功能，但卻不知道要停用註冊表單，因而成為被濫用的途徑。類似的狀況，也包含了 Joomla 的聯絡表單。許多租戶似乎並不知悉自己的 Joomla 網站存在著可以運作的聯絡表單，即便網站上並未放置相關連結。然後在使用了表單中的寄送複本功能後，就能夠發送任意內容給任意的郵件地址。
對於這些情形，一旦郵件伺服器的自動封阻機制經偵測並發出告警後，自己當下會採取的作法，是盤查租戶網站的可見功能，與郵件及網頁伺服器的記錄進行核對。然後若確認是網站上某些未明列的表單遭到濫用，便會編輯網站 CMS 的資料庫，找尋相關功能並關閉。至於若是其它的狀況，可能就會進一步與客戶聯繫，以協調處置對策。總結來說，前述措施主要的變革，是以往工程師會以簡單粗暴的方式，例如直接停用租戶的整個網站，來避免基礎設施持續受到影響；但改進的新方式，則是能夠單純禁止網站的發信，同時設法追溯出網站問題的來源，若條件許可便主動地將其修正。
類似像這種處置流程的改進與優化，其實也有出現在公司的另一項主機服務──VPS 上。不過這是另一個故事了，估計是要寫成另一篇文章才行。