I recently deployed PHP Server Monitor v3.5.2 on my server to keep track of my hosting status. However, right after setting it up, I noticed a very bizarre issue:

I purposely added a completely unreachable, invalid IP to test the Ping monitoring, but the system reported it as “Online” with a latency of 0ms!

I checked the system error logs, but they were completely clean—no error messages at all. A monitoring system that fails to alert you when a server goes down is virtually useless. To fix this fatal flaw, I began a deep dive to troubleshoot the issue.

🕵️‍♂️ The Diagnosis: Where did it go wrong?

Initially, I suspected the server’s PHP security settings (like disable_functions in php.ini) might be restricting the execution of system commands. If the exec() function is disabled, PHP wouldn’t be able to run the system’s ping command.

To test this theory, I wrote a simple PHP diagnostic script (test_ping.php) to check the underlying connection:

<?php
$test_ip = "192.168.255.255"; 
$cmd = "ping -c 1 -w 2 " . escapeshellarg($test_ip) . " 2>&1";
exec($cmd, $output, $return_var);

echo "Return Code: " . $return_var . "<br>";
print_r($output);
?>

The execution results were eye-opening:

• Return Code: 1 (which means failure)
• Actual Terminal Output: It clearly printed 2 packets transmitted, 0 received, 100% packet loss, time 1016ms.

This proved that the server environment and permissions were perfectly fine! The system successfully sent the packets and accurately recognized that the IP was unreachable (100% packet loss). The environment was not the culprit.

💡 The Root Cause: Outdated Regex vs. Modern Linux

With the environment ruled out, the root of the problem pointed directly to a bug within PHP Server Monitor v3.5.2 itself.

After digging into the official GitHub repository, I realized the software hasn’t seen a major active update since around 2021. The old codebase uses a very rigid method to determine ping status: it uses Regular Expressions (Regex) to parse the text output of the terminal. If it spots the keyword time anywhere in the output string, it blindly assumes “there’s a response time, so the host must be Online.”

In older Linux distributions, a failed ping (100% packet loss) usually wouldn’t print the time taken at the end of the output. However! In newer Linux distributions (like recent Debian versions), the ping command reliably prints out time 1016ms at the very end, even if every single packet is dropped.

Because of this simple phrase—time 1016ms—the outdated code in PHP Server Monitor gets completely confused. It ignores the glaring 100% packet loss right next to it and falsely reports the server as Online. This is also exactly why the “fix” available in the official development branch still fails on newer Linux systems.

🛠️ The Ultimate Solution: Rewriting the Core Logic

Since official maintenance has stalled, the most reliable way forward is to rewrite the validation logic ourselves. Instead of relying on the app to parse terminal text—which can constantly change depending on the Linux distribution—we should just grab the most honest metric the OS provides: the Return Code (0 means success, anything else means failure).

How to apply the fix:

1. Access your PHP Server Monitor web directory via SSH or FTP.
2. Locate and open this specific file: src/psm/Util/Server/Updater/StatusUpdater.php
3. Search for the protected function updatePing function inside the file (it should be roughly past the middle).
4. Replace the entire updatePing function block with this updated, precise version:

    protected function updatePing($max_runs, $run = 1) {
        $starttime = microtime(true);
        $ip = $this->server['ip'];
        $os_is_windows = strtoupper(substr(PHP_OS, 0, 3)) === 'WIN';
        
        if ($os_is_windows) {
            // Windows Ping: -n 1 (1 packet), -w 2000 (2000ms timeout)
            exec('ping -n 1 -w 2000 ' . escapeshellarg($ip), $output, $result);
            $output_str = implode("", $output);
            // Windows ping notoriously returns 0 on unreachable hosts. Verify with "TTL="
            $status = ($result === 0 && stripos($output_str, 'TTL=') !== false) ? true : false;
        } else {
            // Linux/Unix Ping: -c 1 (1 packet), -w 2 (2s timeout), capture stderr
            exec('ping -c 1 -w 2 ' . escapeshellarg($ip) . ' 2>&1', $output, $result);
            // Core fix for Linux: Only trust the Return Code! (0 is success)
            $status = ($result === 0) ? true : false;
        }
        
        // Record the response time
        $this->rtime = (microtime(true) - $starttime);

        // If it fails and we haven't reached max retries, try again
        if(!$status && $run < $max_runs) {
            return $this->updatePing($max_runs, $run + 1);
        }
        
        return $status;
    }

Save the file and head back to your PHP Server Monitor dashboard. Test that invalid IP again, and the system will finally behave as it should, properly displaying a red “Offline” status!

📝 Conclusion

Sometimes, when running older open-source software on modern operating systems, official patches might not be enough to resolve bugs caused by OS-level changes. In situations like this, writing a simple script to test the underlying commands directly can help cut through the confusion and point you toward the most effective fix.

If you are using PHP Server Monitor and experiencing this “Fake Online” bug, give this fix a try!

Tags: PHP Server Monitor, Bug Fix, Server Monitoring, Ping, Linux

在使用 Fail2Ban + ipset + iptables 的伺服器環境中，
很多人只備份了 iptables，卻忽略了 ipset。

結果在災難還原時發現：

• ✅ 規則還在
• ❌ 被封鎖的 IP 全部消失

這篇教學會完整說明：

1. 為什麼要同時備份 iptables 與 ipset
2. 正確備份方式
3. 正確還原順序
4. 建議自動化備份腳本

🔎 一、iptables 與 ipset 差在哪？

在 Fail2Ban 環境中實際架構是：

Fail2Ban
   ↓
ipset（存放被封鎖 IP 清單）
   ↓
iptables（引用 ipset）
   ↓
Linux Kernel 防火牆

✅ iptables 負責「規則」

例如：

-m set --match-set f2b-http-404-scan src -j DROP

意思是：

如果來源 IP 在這個 set 裡 → 就 DROP

✅ ipset 負責「IP 名單」

例如：

add f2b-http-404-scan 65.20.67.134

真正被封鎖的 IP 存在 ipset 裡。

🚨 二、常見錯誤

很多人只做：

iptables-save > /root/iptables.backup

但這只會備份規則，不會備份 ipset 內的 IP。

結果：

• 重開機後
• 或手動 restore 後

IP 清單消失。

✅ 三、正確完整備份方式

必須備份兩個部分。

✅ 1️⃣ 備份 iptables

bash

iptables-save > /root/iptables.backup

✅ 2️⃣ 備份 ipset

bash

ipset save > /root/ipset.backup

這個檔案會包含：

sql_more

create f2b-http-404-scan hash:ip
add f2b-http-404-scan 65.20.67.134
add f2b-http-404-scan 1.2.3.4

這才是真正的封鎖名單。

✅ 四、正確還原方式（非常重要）

⚠️ 還原順序不能錯。

✅ Step 1：先還原 ipset

bash

ipset restore < /root/ipset.backup

✅ Step 2：再還原 iptables

bash

iptables-restore < /root/iptables.backup

❗ 為什麼順序不能反？

因為：

iptables 規則會引用 ipset。

如果 ipset 不存在，會出現錯誤：

iptables: Set f2b-http-404-scan doesn't exist

✅ 五、建議每日自動備份

可以建立一個腳本：

nano /root/backup-firewall.sh

內容如下：

bash

#!/bin/bash

DATE=$(date +%F)

iptables-save > /root/fw-$DATE.iptables
ipset save > /root/fw-$DATE.ipset

給執行權限：

bash

chmod +x /root/backup-firewall.sh

加入 crontab：

bash

crontab -e

每天凌晨 3 點備份：

basic

0 3 * * * /root/backup-firewall.sh

✅ 六、如果發生誤封全站怎麼辦？

假設錯誤規則導致：

0.0.0.0/0 tcp dpt:80 DROP

網站全部無法連線。

只要執行：

bash

ipset restore < /root/ipset.backup
iptables-restore < /root/iptables.backup

30 秒內救回網站。

✅ 七、關於 Fail2Ban 的補充

如果你使用：

banaction = iptables-ipset-proto6-allports

Fail2Ban 重啟後會自動重建 ipset。

因此：

✅ 一般重開機不會遺失封鎖
✅ 但手動清空 firewall 會遺失

所以備份仍然是好習慣。

✅ 八、總結

🎯 最重要一句話

iptables 只是規則
ipset 才是黑名單

兩個都要備份，才算完整防火牆備份。

ls -d /var/vmail/*/* | awk '{print $NF}' | awk '{split($0,a,"/");  print a[5] "@" a[4]}' | grep '.com\|.hk'