How to Disable CSF Blocked IP Email Alerts and Reduce Notification Noise

On busy production web servers running ConfigServer Security & Firewall (CSF) with Login Failure Daemon (LFD), automated brute-force attempts can trigger dozens of automated alert emails per hour. Even after disabling LF_PERMBLOCK_ALERT and LF_NETBLOCK_ALERT in /etc/csf/csf.conf, CSF often continues sending notification messages.

The Culprit: LF_EMAIL_ALERT acts as a global master override that dispatches email notifications regardless of individual sub-alert flags.

Configuration Solution

Open /etc/csf/csf.conf and ensure all three alert directives are disabled:

# Disable automated IP block email notifications
LF_PERMBLOCK_ALERT = "0"
LF_NETBLOCK_ALERT = "0"
LF_EMAIL_ALERT = "0"

Reload CSF and LFD for the settings to take effect:

csf -r
service lfd restart

How to Transparently Route All Traffic Through a SOCKS/SSH Proxy on Linux and macOS (sshuttle)

Standard application-level SOCKS or HTTP proxy settings in Linux desktop environments (GNOME/KDE) frequently fail for stubborn proprietary applications (such as TeamViewer, VoIP tools, or CLI utilities) that ignore desktop proxy environment variables. sshuttle acts as a transparent, poor-man's VPN over standard SSH, routing all TCP traffic (and optionally DNS queries) without requiring root administrator privileges or TUN/TAP kernel modules on the remote host.

Advantages: No remote root required • Auto-routes TCP connections • Completely transparent to all running applications

1. Installation

# On Ubuntu / Debian:
sudo apt-get install sshuttle -y

# On macOS (Homebrew):
brew install sshuttle

# Or via Python pip:
sudo pip install sshuttle

2. Routing Global Traffic

To forward all client internet traffic (excluding your local LAN subnets) through your remote SSH server:

# Transparently route all default IPv4 subnets and DNS:
sshuttle --dns -r username@remote-server-ip:22 0/0 -x 192.168.0.0/16 -x 10.0.0.0/8

Every running program on your workstation—including apps with broken native proxy settings—will instantly route traffic through the encrypted SSH tunnel.

[Solved] Fixing Broken DomainKeys and DKIM Signatures Sent via PHP mail()

When sending emails through PHP's native mail() function on a server configured with SPF, DomainKeys, and DKIM (such as Plesk), desktop mail clients (Outlook, Thunderbird) may sign outbound emails correctly, but emails dispatched from web scripts fail DKIM verification with invalid domain signatures.

The Trap: Setting a raw From: string inside $additional_headers causes the sendmail wrapper to misidentify the originating signing domain d=$DOMAIN.

The Problematic Call

// This breaks DKIM signatures by overriding the sender envelope incorrectly:
mail($to, $subject, $message, "From: Name <user@domain.com>");

The Solution

Explicitly pass the envelope sender using the -f flag in the 5th parameter ($additional_parameters):

// Correct invocation with verified envelope sender:
mail($to, $subject, $message, "", "-f user@domain.com");

Verification Tip: Send a test email to check-auth@verifier.port25.com. The automated robot will reply within seconds with a detailed SPF, DKIM, DomainKeys, and SpamAssassin diagnostic report.

[Solved] Postfix SASL Authentication Failure: realm changed: authentication aborted in Plesk

When enabling STARTTLS on a Plesk server running Postfix, mail clients like Mozilla Thunderbird may connect normally, while Microsoft Outlook clients repeatedly fail with authentication popups and the following mail log errors:

Environment: Plesk • Postfix with STARTTLS • Cyrus SASL Authentication

postfix/smtpd[1929]: warning: SASL authentication failure: realm changed: authentication aborted
postfix/smtpd[1929]: warning: SASL DIGEST-MD5 authentication failed: authentication failure

Root Cause & Solution

Outlook struggles with DIGEST-MD5 SASL negotiation over TLS on certain Cyrus SASL configurations. Restricting the SASL mechanism list to CRAM-MD5, PLAIN, and LOGIN resolves the negotiation conflict:

1. Edit /usr/lib64/sasl2/smtpd.conf and update mech_list:

   mech_list: CRAM-MD5 PLAIN LOGIN

2. Edit /etc/postfix/main.cf and confirm security options:

   smtpd_sasl_security_options = noanonymous

3. Restart services:

   service postfix restart
   service saslauthd restart

How to Fix VMware ESXi 6.0 Root Account Lockout and Brute-Force Restrictions

Starting with version 6.0, VMware ESXi introduced an automated security lockout feature that locks the root account after consecutive failed login attempts. On hypervisors exposed to public networks, malicious automated SSH bots frequently trigger this threshold, inadvertently locking legitimate administrators out of the vSphere Client and Web UI.

Security Best Practices: Enforce SSH key-based authentication • Restrict ESXi management firewall to designated administrative IPs.

1. Unlocking the Root Account via Local Console (DCUI)

Log in via the physical or out-of-band Direct Console User Interface (DCUI), navigate to Troubleshooting Options, enable the ESXi Shell, and reset the lockout counter:

# Check failed login attempt count
pam_tally2 --user root

# Reset failed attempt counter and unlock account
pam_tally2 --user root --reset

2. Permanent Hardening: Restrict Management Access

To eliminate unauthorized brute-force attempts permanently:

1. Disable SSH password logins in /etc/ssh/sshd_config:

   PasswordAuthentication no

2. Restrict the ESXi management firewall rule for the vSphere Client (port 443 / 902) to your office or VPN gateway IPs:

   esxcli network firewall ruleset set --ruleset-id vSphereClient --allowed-all false
   esxcli network firewall ruleset allowedip add --ruleset-id vSphereClient --ip-address 203.0.113.10

Essential Techniques to Block Browser Fingerprinting, Canvas Tracking, and Audio APIs

Standard "Private Browsing" or "Incognito" modes prevent local history from saving to disk, but they do little to protect your identity from sophisticated web trackers. Modern tracking networks rely on device fingerprinting—measuring system fonts, GPU rendering quirks via HTML5 Canvas, WebGL parameters, audio latency, and installed plugins to create a persistent hardware signature across sessions.

Auditing Tools: Test your browser uniqueness at EFF Panopticlick (Cover Your Tracks) and BrowserLeaks.

Key Tracking Vectors and Countermeasures

• HTML5 Canvas Fingerprinting: Trackers draw invisible shapes and text behind the scenes; minute GPU driver rendering variations produce a unique hash.

  Defense: Install privacy tools like Canvas Defender or Firefox's native privacy.resistFingerprinting = true in about:config.

• AudioContext API Tracking: Variations in audio buffer processing across system sound cards provide another identifiable vector.

  Defense: Block non-consensual Web Audio processing through extension policies.

• System Font Enumeration: Tracking scripts measure font rendering metrics across hundreds of installed fonts.

  Defense: Restrict font queries to standard platform fonts (layout.css.font-visibility.standard = 1 in modern Firefox).

• WebRTC IP Leakage: WebRTC STUN requests can expose real public and private LAN IPs even when connected behind a VPN proxy.

  Defense: Set media.peerconnection.enabled = false.

How to Log PHP mail() Sender Scripts and Headers to Detect Outgoing Spam

When a web server hosting multiple PHP applications or CMS sites is compromised by spammers, identifying the exact malicious PHP script sending unauthorized emails can be notoriously difficult. In PHP 5.3 and newer, built-in configuration directives allow you to track the exact script filename and originating source of every outgoing message.

Key Directives: mail.log for auditing script paths • mail.add_x_header for tracking script UID in email headers.

1. Enable mail.log

Open your server's php.ini (or pool configuration in PHP-FPM) and configure a dedicated mail log:

; Log all mail() function invocations, including script path and line number
mail.log = /var/log/php_mail.log

Ensure the web server user (e.g. apache or www-data) has write permissions to the destination file:

touch /var/log/php_mail.log
chown www-data:www-data /var/log/php_mail.log
chmod 660 /var/log/php_mail.log

2. Enable X-PHP-Originating-Script Header

To embed the sender script path directly into outgoing mail headers, enable mail.add_x_header:

; Adds X-PHP-Originating-Script header containing the UID and filename
mail.add_x_header = On

When an email is sent, the recipient headers will contain:

X-PHP-Originating-Script: 1000:contact_form.php

This allows you to immediately trace spam reports back to the offending script or compromised user account.

Automated Dynamic IP Whitelisting for CSF Firewall Using PHP and Bash

When administering remote Linux production servers protected by ConfigServer Security & Firewall (CSF), dynamic residential IPs frequently get blocked or locked out of management portals. Here is a lightweight, automated mechanism to dynamically whitelist your current IP address simply by visiting a private URL on your server.

Architecture: PHP capture endpoint • Fast-polling background Bash daemon • CSF Perl reload

1. The PHP Endpoint (whatis.php)

Create a secure PHP script in your web root that logs the visitor's remote client IP to a temporary staging file:

<?php
// Protect with an authentication token or secret parameter in production
file_put_contents("/tmp/iplog", $_SERVER["REMOTE_ADDR"]);
echo "IP captured: " . htmlspecialchars($_SERVER["REMOTE_ADDR"]);
?>

2. The Shell Whitelister Daemon (/script/ip)

Create a root shell script to inspect the staging file, update /etc/csf/csf.allow, and reload firewall rules:

#!/bin/bash
i=1
while [ $i -le 10 ]
do
    status=$(cat /tmp/iplog 2>/dev/null)
    if [ -n "$status" ] && [ "$status" != "0" ]; then
        echo "$status" >> /etc/csf/csf.allow
        echo "$status" >> /etc/csf/csf.ignore
        echo "0" > /tmp/iplog
        # Note: Use csf.pl -r inside scripts for reliable Perl-based reload
        /etc/csf/csf.pl -r > /tmp/csf.log 2>&1
    fi
    sleep 5
    (( i++ ))
done

Make the script executable:

chmod +x /script/ip

3. Cronjob Schedule

Add a root crontab entry to execute the daemon once every minute:

* * * * * /script/ip

Implementation Tip: Calling csf -r from non-interactive shell scripts often fails to reload properly. Invoking the underlying Perl script /etc/csf/csf.pl -r ensures firewall tables reload reliably.

How to Run mini_sendmail in a Chrooted PHP-FPM Environment (CentOS & Debian)

Chrooting PHP-FPM worker pools provides robust filesystem isolation on multi-tenant servers. However, standard mail dispatch breaks because PHP's mail() function relies on executing a local sendmail binary (which requires extensive shared libraries and access to /etc). mini_sendmail solves this by providing a lightweight, statically linkable MTA forwarder that relays directly to localhost port 25.

Stack: PHP-FPM Chroot • mini_sendmail • CentOS 6 / Debian 6

1. Preparing the Chroot Filesystem

Inside the jail directory, ensure character devices and DNS resolvers are accessible:

cd /path/to/jail
chmod 0666 dev/{tty,null,zero}
echo "nameserver 8.8.8.8" > etc/resolv.conf

2. Compiling and Patching mini_sendmail

Download and extract the source:

cd /usr/src
wget http://acme.com/software/mini_sendmail/mini_sendmail-1.3.6.tar.gz
tar -zxf mini_sendmail-1.3.6.tar.gz
cd mini_sendmail-1.3.6

When running inside a chroot jail without /etc/passwd, getlogin() fails with can't determine username. Fix this by hardcoding the pool user in mini_sendmail.c around line 148:

// Replace: username = getlogin();
// With your PHP-FPM pool user:
username = "fpm_user";

Compile and install into the jail's usr/sbin/sendmail:

make
cp mini_sendmail /path/to/jail/usr/sbin/sendmail
chmod 755 /path/to/jail/usr/sbin/sendmail
chown fpm_user:fpm_user /path/to/jail/usr/sbin/sendmail

Now PHP scripts running inside the chroot jail can execute mail() and messages are cleanly forwarded to your server's primary MTA.

Hardening Web Servers: Nginx Symlink Protection and PHP-FPM Chroot Jails

Securing shared hosting environments and multi-tenant web servers requires preventing unauthorized symlink traversals and isolating application processes. Here are two powerful security features in Nginx and PHP-FPM that significantly harden your stack against cross-account directory traversal attacks.

Security Highlights: Prevent unauthorized symlink following in Nginx • Isolate execution pools in dedicated chroot jails with required pseudo-devices

1. Restricting Symlink Traversal in Nginx

By default, Nginx follows symbolic links without verifying ownership. The disable_symlinks directive allows you to strictly control link traversal:

# Allowed options: off | on | if_not_owner
disable_symlinks if_not_owner;

When set to if_not_owner, Nginx verifies that the symlink and the target file/directory belong to the same owner, effectively blocking unauthorized access to system files or other users' web roots.

2. PHP-FPM Chroot Jails

To provide true isolation, you can lock each PHP-FPM worker pool into its own chroot directory. A quick way to bootstrap a clean environment is by extracting a minimal OS template (such as an OpenVZ minimal template matching your host distribution) into the jail root.

Creating Essential Device Nodes in the Jail

For PHP and system libraries to function correctly (especially DNS resolution, random entropy, and error logging), create the necessary character devices inside the jail directory:

cd /path/to/jail
mkdir -p dev etc usr/share/zoneinfo

mknod -m 666 dev/null c 1 3
mknod -m 666 dev/zero c 1 5
mknod -m 666 dev/random c 1 8
mknod -m 666 dev/urandom c 1 9

Also copy /etc/resolv.conf and /etc/hosts into the jail's etc/ folder so PHP can perform external network queries and DNS resolution.