The Problem

My server load was pinned at 100%, with php-fpm processes consuming the bulk of the CPU. Using tools like htop and ps, I traced the activity back to a few specific WordPress sites hosted on the server.

The common culprit? Bot traffic hammering uncached pages and XML-RPC endpoints.

The Fix (3-Part Solution)

1. Block Bots with .htaccess

I edited the .htaccess file for each affected site and added rules to block known abusive bots by user agent:

# Block bad bots by user-agent
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} (semrush|ahrefs|mj12bot|dotbot|python-requests|curl|wget|masscan|sqlmap|fimap|nmap|nikto) [NC]
RewriteRule .* - [F,L]
</IfModule>

This simple change started deflecting unnecessary load before it could hit WordPress or PHP.

2. Install and Configure Fail2Ban

I installed Fail2Ban to automatically block IPs that triggered suspicious patterns in my Apache logs (like repeated bot-like requests):

sudo yum install epel-release -y
sudo yum install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Then, I created a jail to detect and ban bad bots:

/etc/fail2ban/jail.d/apache-badbots.conf

[apache-badbots]
enabled = true
port    = http,https
filter  = apache-badbots
logpath = /usr/local/apache/logs/access_log
maxretry = 10
findtime = 300
bantime = 3600

/etc/fail2ban/filter.d/apache-badbots.conf

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*(crawler|bot|spider|python|curl|wget).*HTTP.*"

With this in place, the server now proactively bans repeat offenders and malicious bots.

3. Restart PHP-FPM and Apache to Flush Load

Once the defenses were in place, I restarted the two main services to clear out any bloated or stuck processes:

systemctl restart ea-php81-php-fpm
systemctl restart httpd

This dropped my CPU usage almost instantly and gave the server a clean slate to work with.

Summary

After these changes:

• CPU usage dropped from 100% to <10%
• PHP-FPM processes normalized
• The server has stayed stable under load, even with continued traffic

If you’re running cPanel/WHM and notice unexplained high load:

• Check your access logs
• Filter bots at the .htaccess level
• Set up Fail2Ban to auto-ban bad actors
• And always restart PHP-FPM/Apache after config changes

Here’s the csv format for the headers and for the Folders – I couldn’t get it to link via the name so I have it cross-reference the Label ID to match the folders:
email, label
example_email@yahoo.com, Label_55

This is what the output looks like:

Here’s my code if anyone wants to make their own python script:

import os
import pickle
import pandas as pd
import base64
from google.oauth2.credentials import Credentials
from google.auth.transport.requests import Request
from googleapiclient.discovery import build
from googleapiclient.errors import HttpError
from google_auth_oauthlib.flow import InstalledAppFlow
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

# Step 1: Authentication and Service Initialization
def authenticate_gmail_api():
    SCOPES = ['https://www.googleapis.com/auth/gmail.modify']
    creds = None

    if os.path.exists('token.pickle'):
        with open('token.pickle', 'rb') as token:
            creds = pickle.load(token)
    
    if not creds or not creds.valid:
        if creds and creds.expired and creds.refresh_token:
            creds.refresh(Request())
        else:
            flow = InstalledAppFlow.from_client_secrets_file(
                'credentials.json', SCOPES)
            creds = flow.run_local_server(port=0)
        with open('token.pickle', 'wb') as token:
            pickle.dump(creds, token)

    service = build('gmail', 'v1', credentials=creds)
    return service

# Step 2: Read Filters from CSV File
def read_filters_from_csv(csv_file):
    filters_df = pd.read_csv(csv_file)
    return filters_df

# Step 3: Search for Matching Emails
# Step 3: Search for Matching Emails
def search_emails(service, query):
    try:
        # Modify the query to explicitly search only within the INBOX
        query = f'label:inbox {query}'
        results = service.users().messages().list(userId='me', q=query).execute()
        messages = results.get('messages', [])
        return messages
    except HttpError as error:
        print(f'An error occurred: {error}')
        return []


# Step 4: Apply Filters and Move Emails
def apply_filters(service, filters_df):
    for index, row in filters_df.iterrows():
        email_filter = row['email']
        label = row['label']

        query = f'from:{email_filter}'
        messages = search_emails(service, query)

        if not messages:
            print(f'No emails found for {email_filter}')
            continue

        for message in messages:
            msg_id = message['id']
            # Move email to the specified folder (label)
            service.users().messages().modify(
                userId='me',
                id=msg_id,
                body={'addLabelIds': [label], 'removeLabelIds': ['INBOX']}
            ).execute()
            print(f'Email from {email_filter} moved to {label} and archived.')

# Step 5: Retrieve and List Label IDs
def list_labels(service):
    results = service.users().labels().list(userId='me').execute()
    labels = results.get('labels', [])

    if not labels:
        print('No labels found.')
    else:
        print('Labels:')
        for label in labels:
            print(f"{label['name']} - {label['id']}")

# Step 6: Main Function
def main():
    # Authenticate and create the Gmail API service
    service = authenticate_gmail_api()

    # Uncomment the line below to list all labels and their IDs
    list_labels(service)

    # Load filter rules from CSV
    csv_file = 'filters.csv'  # Replace with your CSV file
    filters_df = read_filters_from_csv(csv_file)

    # Apply filters to emails
    apply_filters(service, filters_df)

if __name__ == '__main__':
    main()

I added google, Gmail, and youtube to the whitelist, and tested resetting DHCP and DNS. The only thing that seemed to work temporarily was to restart the pfsense device. I searched bing.com for the first time in years, also google on my phone, and none of the forums had the answer. One post on reddit even said “It’s not pfsense, this is known in the industry as a layer 8 issue. Check pfblocker logs and look for the blocks. A note on the whitelist, sometimes you may need to clear your state table (shouldn’t have to but with any rule changes, clearing the states is a good troubleshooting thing)” Reading this, I felt hopeless and went to bed.

The next day, I cleared the states, and nothing still. The problem this time was permanent on my desktop but periodic for other devices that were on the wifi, which confused me more. So then, by finally looking through the proper logs, I found in pfblockerng that IP’s which I crossed referenced as googles servers, were being blocked by the “Block snort2c hosts” rule in the firewall. Okay, so I searched the snort2c table to find those exact IPs from google. Finally!

My current solution (which is still a work in progress) was to reset the snort2c table, which for some reason had the resolved google servers for google.com on the block table. I realized that even though I had whitelisted www.google.com and google.com, they were being blocked because pfblockerng / snort2c added the resolved google IP as a block.

Now all I need to do is diagnose why the rule in pfblockerng is causing the snort2c block, regardless of the addition of google to the whitelist. I’ll post an update when I find the best solution vs. just resetting the snort2c table.

Update | 10-6-2022

I’ve got an update to this post and so even though pfblockerng is showing the blocked IPs from google, apparently, Suricata is to blame. Hold on, I’m no pfsense master, just a humble student of networking, I’ll get to the point.

After some additional research on the all-mighty google – I think I might have found a solution (still testing the viability at the moment). Seems as though the best solution is to have a modified “Remove Blocked Hosts Interval” of 1 hour.
“Please select the amount of time you would like hosts to be blocked. Note this setting is only applicable when using Legacy Mode blocking! This setting is ignored when using Inline IPS Mode.
Hint: in most cases, 1 hour is a good choice.”

To find this setting: Services -> Suricata -> Global Settings -> towards the bottom [Remove Blocked Hosts Interval]
I changed mine from 4 days to 1 hour in hopes that google IPs being blocked by snort will at least be removed at a faster rate than before in my configuration.
I also chose to turn on logs for Suricata below the remove blocked hosts setting.

References:
https://forum.netgate.com/topic/131510/pfsense-keeps-blocking-google-com-i-lost-all-hope
https://www.reddit.com/r/PFSENSE/comments/oq4s6s/pfsense_blocking_googlecom_and_searches_but/
https://forum.netgate.com/topic/171592/suricata-blocking-google-gmail
https://www.reddit.com/r/PFSENSE/comments/qnhqvr/help_100_packet_loss_on_wan_link_not_isp_does_not/

***https://forum.netgate.com/topic/137889/snort/2*** Solution