A "BLOCK" status means the request did not reach the application. A high number of BLOCK requests indicates active searching, not proof of intrusion.<\/p>\n\n\n\n
This article will distinguish between different stopping methods using the following three terms.<\/p>\n\n\n\n
- \n
- BLOCK<\/strong> ...SiteGuard rejects it before it reaches the app.<\/li>\n\n\n\n
- 403<\/strong> ...Apache rejects the request.<\/li>\n\n\n\n
- DROP<\/strong> ...firewalld drops the packet, so from the sender it looks as if nothing arrived<\/li>\n<\/ul>\n\n\n\n
![\"A](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/01-log-reading.png\")
These are the four things to extract from a single line of the log. The address and hostname are just examples.<\/figcaption><\/figure>\n\n\n\n Policy<\/h2>\n\n\n\n
The primary method will be using SiteGuard's official signature. The IP list is kept as a supplement. Since the source changes daily, manually tracking the list will not be the main countermeasure.<\/p>\n\n\n\n
The actions taken were in the following order, starting with those closest to the log.<\/p>\n\n\n\n
- \n
- Close files that do not need to be made public.<\/li>\n\n\n\n
- Make unused hostnames invisible from the outside.<\/li>\n\n\n\n
- Put the app on a security release in its own product line, and limit the app admin screen to the work network<\/li>\n\n\n\n
- Remove the version string from the response header.<\/li>\n\n\n\n
- For a while, automatically keep away IPs that repeat the same failures<\/li>\n\n\n\n
- Automatically apply only OS security updates without requiring a restart.<\/li>\n\n\n\n
- DROP only the sources that stand out, as a supplement<\/li>\n\n\n\n
- Restrict SiteGuard's management port to only the work line.<\/li>\n<\/ol>\n\n\n\n
![\"Layers](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/02-layers.png\")
Most of these requests stop at SiteGuard. firewalld is only a supplement for sources that stand out.<\/figcaption><\/figure>\n\n\n\n 1. Close information that had been left exposed.<\/h2>\n\n\n\n
Requesting the server default document root by raw IP showed that
info.php<\/code> was returning 200. The body was phpinfo, listing the PHP version, paths, and loaded modules. It had been left there for diagnostics, so I moved the file and returned 403 for that path. I also changed the default document root so it does not show its contents.<\/p>\n\n\n\nI also checked each site's
.env<\/code> andweb.config<\/code> from the outside, using only the status code. All were 403 or 404, and no body was returned. That confirmed they were closed. I added no further deny rule.<\/p>\n\n\n\nOnly the HTTP methods necessary for the site were retained. Methods not used for normal browsing or form submission are rejected by Apache.<\/p>\n\n\n\n
![\"A](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/03-forbidden.png\")
Entering an IP address directly will result in a Forbidden error. Previously, internal PHP information was displayed here.<\/figcaption><\/figure>\n\n\n\n 2. Unused sites and hosts with only a name.<\/h2>\n\n\n\n
For sites that weren't functioning, I decommissioned them along with their document roots, virtual hosts, and unnecessary databases. The databases and users of the sites I kept were not touched.<\/p>\n\n\n\n
I kept the DNS wildcard.
*<\/code> As long as this exists, deleted names and non-existent subdomains will still be resolved to this server. Therefore, HTTPS connections from hosts other than those I know will result in a 403 error. This is to prevent unknown names from responding with the server's default certificate.<\/p>\n\n\n\nBefore and after the work, I checked that the public sites returned HTTP 200, and checked the certificate issuer and expiry.<\/p>\n\n\n\n
![\"A](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/04-wildcard-dns.png\")
The name still resolves. Open only hosts that exist, and return 403 for the rest. Hostnames are examples.<\/figcaption><\/figure>\n\n\n\n 3. App-side entry point<\/h2>\n\n\n\n
EC-CUBE was moved to a security release in its own product line. The change was the multi-factor authentication around the admin screen. I put production into a short maintenance window, took a database dump, applied the official diff, updated the schema, then ended maintenance. I checked the version string, related files, and the front and admin login responses, then called it done. Customizations such as addresses and invoices stayed.<\/p>\n\n\n\n
WordPress core and plugins were already current at the time. The only addition was rejecting
xmlrpc.php<\/code>. That unused path is an easy route for pingbacks and brute force, so I returned 403.<\/p>\n\n\n\nThe EC-CUBE admin panel had an empty field for allowed connections. I entered only the IP address of my work network here. On days when I connect from a different network, I add that IP address and clear the cache.<\/p>\n\n\n\n
I restricted access to the temporary PHP file I had been using for work, which was previously left unauthenticated, to only the same network connection. Although it wasn't a file that executed commands, it allowed me to see its internal paths and the progress of the work. I deleted it once I was finished.<\/p>\n\n\n\n
![\"On](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/05-admin-deny.png\")
The app's management screen will not open from unauthorized connections. The site name and address are hidden.<\/figcaption><\/figure>\n\n\n\n ![\"From](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/05-admin-allow.png\")
The login screen is accessible from the work network.<\/figcaption><\/figure>\n\n\n\n 4. Do not include the version in the header.<\/h2>\n\n\n\n
By default, PHP adds
X-Powered-By: PHP\/x.x.x<\/code> to the response headers.expose_php=Off<\/code>. After reloading php-fpm, this header disappears. The page does not change. This does not close the vulnerability. It only makes the version harder to guess.<\/p>\n\n\n\nexpose_php = Off<\/code><\/pre>\n\n\n\n5. Leave the repetition to fail2ban.<\/h2>\n\n\n\n
I installed fail2ban and set firewalld to DROP, for a while, IPs that keep failing or probing in the logs. I enabled these six jails.<\/p>\n\n\n\n
Jail<\/th> What it watches<\/th><\/tr><\/thead> sshd<\/td> SSH login failed<\/td><\/tr> apache-auth<\/td> Failures such as Basic Authentication<\/td><\/tr> apache-badbots<\/td> Known malicious crawlers<\/td><\/tr> apache-noscript<\/td> Probing for scripts that do not exist<\/td><\/tr> apache-overflows<\/td> Unusually long URLs, etc.<\/td><\/tr> recidive<\/td> Block IP addresses that have been blocked multiple times for an extended period.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n I added the work network to
ignoreip<\/code> so my own actions would not lock me out.<\/p>\n\n\n\nA side effect is that legitimate users can be cut off for a while. A company or carrier egress IP is sometimes shared with unrelated people. After enabling it, use
fail2ban-client status<\/code> to check the counts, and loosen or remove a jail that looks wrong.<\/p>\n\n\n\n01<\/p>
\ud83d\udeaa<\/p>
Few failures<\/p>
Still let it through<\/p><\/div>
02<\/p>
\u26a0\ufe0f<\/p>
Repeat in a short period of time<\/p>
The same sender continues<\/p><\/div>
03<\/p>
\ud83d\udd12<\/p>
Close for a while<\/p>
Temporarily DROP<\/p><\/div><\/div>
If the same sender repeatedly fails in a short period of time, I'll keep the door closed for a while.<\/figcaption><\/figure>\n\n\n\n 6. Automate only the OS security updates.<\/h2>\n\n\n\n
dnf-automatic<\/code> and apply only security updates automatically. I do not reboot automatically after a kernel update. The scope is narrower than updating everything, but it avoids an unplanned reboot taking the site down.<\/p>\n\n\n\n7. Block frequently occurring IP addresses as a backup.<\/h2>\n\n\n\n
I added only the source that stood out in the most recent logs to both SiteGuard's connection rejection and firewalld's DROP command. I didn't add country-specific rejections because there are legitimate access attempts from overseas.<\/p>\n\n\n\n
This is an initial step. Even if the same address continues to appear in the log afterward, if it's already blocked, we don't manually move each entry to the DROP list. Our primary focus remains on the official signature and its automatic updates. Even within the same campaign, the sender changes frequently.<\/p>\n\n\n\n
We don't blindly apply the publicly available list of notorious IP addresses. Older addresses and shared cloud ranges can sometimes inadvertently include legitimate communications. Manually adding only those entries that clearly indicate a scan from our own server logs is sufficient.<\/p>\n\n\n\n
8. SiteGuard's management port is only for the work line.<\/h2>\n\n\n\n
The SiteGuard admin screen listens on port
9443<\/code>. It is open only to the work network and localhost. Connections from anywhere else time out. Ports 80 and 443 of the public site are unchanged.<\/p>\n\n\n\nThis screen uses a different certificate than the one used by the production site's Let's Encrypt. If you open it by directly specifying the IP address, your browser will display a certificate warning. You can open it by proceeding to the details from an authorized connection.<\/p>\n\n\n\n
From elsewhere, reach it with an SSH local forward.<\/p>\n\n\n\n
ssh -L 9443:127.0.0.1:9443 user@your-server<\/code><\/pre>\n\n\n\nIn a local browser, open
https:\/\/127.0.0.1:9443\/<\/code> . A certificate warning is likely. If the work-network IP changes, update the firewalld allow rule. Forgetting that locks out only you.<\/p>\n\n\n\n![\"A](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/07-timeout.png\")
Connections from unauthorized lines will time out.<\/figcaption><\/figure>\n\n\n\n ![\"The](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/07-admin-login.png\")
On authorized connections, the login screen appears after exceeding the certificate warning. The address is hidden.<\/figcaption><\/figure>\n\n\n\n ![\"The](\"https:\/\/blog.coppe.jp\/app\/uploads\/2026\/11\/07-admin-open.png\")
The management screen after logging in. Only the signature breakdown is visible.<\/figcaption><\/figure>\n\n\n\n Left for later<\/h2>\n\n\n\n
The following three were considered but ultimately rejected.<\/p>\n\n\n\n
Additional IPv6 restrictions<\/h3>\n\n\n\n
This VPS did not have an IPv6 address at the time. The DNS entry AAAA remained. The name resolved to IPv6, but the server did not respond in IPv6. I decided that it would be sufficient to simply ensure that all but SSH, HTTP, and HTTPS were closed via firewalld just before enabling the address.<\/p>\n\n\n\n
Automatic DROP based on detection logs<\/h3>\n\n\n\n
This mechanism sends requests that the WAF has already rejected to firewalld based on their number. It is prone to involving shared IPs and cloud addresses for payment and APIs. Skipping the notification stage and automatically blocking them would have significant side effects given the current volume of requests.<\/p>\n\n\n\n
Constantly synchronize attack IP addresses with multiple other VPS servers.<\/h3>\n\n\n\n
The same campaign can hit several servers around the same time. Sources are often disposable, and a mistaken drop spreads to every server. It is easier to let SiteGuard BLOCK on each server, and to add by hand only what stands out in that server's log.<\/p>\n\n\n\n
Done for this round<\/p>
What went in<\/h3>
- Files that do not need to be made public and unknown hosts have been closed.<\/li>
- I updated the app and made the management screen accessible only through the work network.<\/li>
- I installed fail2ban and the OS security updates.<\/li>
- The admin port, and only the sources that stood out, were dropped as a supplement.<\/li><\/ul><\/div>
When a reason appears<\/p>
Add it then<\/h3>
- The day to enable IPv6<\/li>
- A day when the same source still surges after it has been blocked<\/li>
- The day when only the production management URL is being attacked repeatedly<\/li>
- A day when the same campaign stands out at once on several other servers<\/li><\/ul><\/div><\/div>
Some things are meant to be finished this time, while others can wait until a suitable opportunity arises.<\/figcaption><\/figure>\n\n\n\n Leave it so that it can be restored.<\/h2>\n\n\n\n
I copied the configuration files I was going to modify, noting the date and time, before starting the work. When updating the application, I left a database dump in a separate directory.<\/p>\n\n\n\n
The public site will be checked for the following changes each time they are made.<\/p>\n\n\n\n
- \n
- Whether the homepage returns HTTP 200<\/li>\n\n\n\n
- Certificate issuer and expiration date<\/li>\n\n\n\n
- Will the app's management screen only open from authorized connections?<\/li>\n\n\n\n
- Is the environment variable file still showing 403 or 404?<\/li>\n<\/ul>\n\n\n\n
What to watch afterward<\/h2>\n\n\n\n
I've finished the implementation for now. I'm continuing with the following three things:<\/p>\n\n\n\n
- \n
- If the IP address of your work network changes, update the SiteGuard management port and the permissions for the app's management screen.<\/li>\n\n\n\n
- Check SiteGuard's detections once a week. See if any new types of URLs have been added.<\/li>\n\n\n\n
- If the production admin URL keeps being targeted, the same IP surges after a DROP, or real harm appears, add something then.<\/li>\n<\/ul>\n\n\n\n
The sources that stood out the first time are included. Everything else is left to the official signature BLOCK. I do not copy busy log lines over by hand each time.<\/p>\n\n\n\n
Checklist<\/h2>\n\n\n\n
The steps to take when transferring to another VPS are as follows.<\/p>\n\n\n\n
- \n
- Check that the log you checked is judged as BLOCK.<\/li>\n\n\n\n
- Stop exposing phpinfo and the standard document root.<\/li>\n\n\n\n
- The status code confirms that the environment variable file cannot be read from outside.<\/li>\n\n\n\n
- Delete unused hosts and set unknown hosts to 403 for wildcard access.<\/li>\n\n\n\n
- Move the app to a security release in its own product line, and reject the unused
xmlrpc.php<\/code>.<\/li>\n\n\n\n- Enter the allowed IP addresses in the app's management screen.<\/li>\n\n\n\n
expose_php=Off<\/code> .<\/li>\n\n\n\n- Install fail2ban and exclude the work line from being targeted.<\/li>\n\n\n\n
- The OS will only have automatic security updates, and restarts will remain manual.<\/li>\n\n\n\n
- Only add the most prominent sources to SiteGuard and firewalld.<\/li>\n\n\n\n
- SiteGuard's management ports should be limited to the work network and localhost.<\/li>\n\n\n\n
- After the changes are reflected, check the response and certificates on the public site.<\/li>\n<\/ol>\n\n\n\n
It's impossible to eliminate entry points entirely. New sources, unknown attacks, and changes in operational lines will remain. The benefit of this approach lies in reducing the amount of material available for reconnaissance and unused entry points, and mitigating the impact of any slip-throughs through updates and reduced privileges.<\/p>\n\n\n\n
- 403<\/strong> ...Apache rejects the request.<\/li>\n\n\n\n