In short: Security monitoring for servers means continuously watching web servers for signs of an attack, instead of reacting only when customers complain. We monitor files, processes, logins, connections and logs of your PHP servers and give an understandable assessment of every anomaly. That way you detect problems earlier and have the necessary traces in an emergency.
Why server security monitoring matters right now
PHP2Shell has shown how quickly a new vulnerability can become a threat to millions of servers. Unit 42 counted more than 22.6 million exposed, potentially vulnerable instances. At the same time, there are no published, confirmed indicators of compromise. Anyone who wants to know whether something is happening on their own server has to watch behavior.
Many break-ins are discovered late, often by third parties: a Google warning, a block by the hosting provider because of spam sending, a tip from a customer. By then, logs have often been rotated and traces lost. Security monitoring shortens this time and makes sure the logs are still there when you need them. For management this means above all one thing: decisions in an emergency are based on facts rather than assumptions.
What we monitor
| Area | What we look for |
|---|---|
| Files | new or changed PHP files, executable code in upload folders, changes to .htaccess and configuration |
| Processes | commands started from PHP workers, unknown long-running processes, crashing workers |
| Logins | SSH and panel logins, new admin accounts in the CMS, clusters of failed attempts |
| Network | unusual outgoing connections, sudden mail sending, new open ports |
| Logs | conspicuous request patterns, clusters of errors, gaps in logging |
| Version state | PHP, CMS and package versions compared against known security updates |
How such signals can be verified manually is described in Analysing web server logs after an attack. For admin access, we additionally recommend the measures from Protecting admin logins against brute force.
How does PHP SOS help?
- Establish the baseline: We record servers, applications, existing logs and previous monitoring, and define what is normal. Without this baseline, anomalies cannot be reliably recognised.
- Set up monitoring: We set up file integrity checking, log forwarding to a separate storage location and rules for typical consequences of an attack. Logs are stored so that an attacker on the web server cannot simply delete them.
- Fine-tuning: During the first weeks we adjust the rules so that you are not flooded with false alarms, for instance from regular updates or deployments.
- Report and assess: We report anomalies with an assessment: what was observed, how likely an attack is and what to do next.
- Reporting: At regular intervals you receive a summary with events, pending updates and recommendations.
Keep logs on a separate system. For PHP2Shell, the trade press advises securing server logs from 20 October 2026 onwards. If you store them centrally, you still have them even if the web server has to be rebuilt.
What an alert from us looks like
A warning is only useful if it is understood. That is why every alert contains the same building blocks:
- What was observed? For example: a new PHP file appeared in a website's upload folder, and shortly afterwards a PHP worker opened an outgoing connection to an unknown address.
- How do we assess it? The new file and the connection are proven. A connection between them is probable. Whether data was transferred is unknown.
- What have we already done? For example, backed up the file and, if agreed, put the website into maintenance mode.
- What do you need to decide? For example, whether the website stays offline until the cause is clarified.
Harmless events, such as a regular plugin update, we recognise from the baseline and summarise in the report instead of bothering you with them one by one. Over time, the monitoring gets to know your systems better.
What you get and what we need
You get a monitoring setup with documented rules, traceable alerts with a recommended action, regular reports and central storage of the logs. In the case of a confirmed incident, the data flows directly into incident response.
We need from you:
- administrator access to the servers to set up agents and log forwarding
- an overview of applications, planned deployments and maintenance windows
- a contact person who receives alerts and can make decisions
- coordination with your data protection officer, because logs can contain personal data such as IP addresses
What we do not promise
Monitoring does not detect every attack. Skilled attackers try to stay unnoticed, and some vulnerabilities leave hardly any traces. Monitoring increases the likelihood of noticing a break-in early and provides reliable data. It replaces neither updates nor hardening.
We also do not set response times across the board; they depend on the agreed level of support. Monitoring delivers its benefit best as part of a security maintenance contract, in which updates, backups and monitoring are regulated together.
Frequently asked questions
What is the difference between normal monitoring and security monitoring?
Normal monitoring checks whether a server is reachable and has enough resources. Security monitoring looks for signs of an attack, such as new executable files, unusual processes or foreign logins. The two complement each other.
Does monitoring detect an attack via PHP2Shell?
There are no published, confirmed indicators of compromise for PHP2Shell. Monitoring can, however, make typical consequences of a break-in visible, such as new PHP files or commands started from within a PHP process. There is no guarantee of success.
Do I have to install software on the server for this?
Usually yes, for example an agent for file integrity and log forwarding. We agree with you, and where applicable your hosting provider, which tools we use so that operations and data protection fit.
Does security monitoring also work with shared hosting?
Only to a limited extent. Without access to processes and system logs, what remains is mainly monitoring of files and content from the outside. Complete monitoring requires your own or a managed server.