Web services and e-commerce businesses have grown rapidly in recent years and, as a result, web hosting services have become not only affordable but also scalable. One of the widely used web hosting services is shared hosting due to affordable pricing and simplicity. Although it is affordable and user-friendly, it has some downsides, especially in terms of security. Because multiple websites are hosted on a single server, a single website can be hacked and cause disruptions to other websites hosted on the server. This phenomenon is known as cross-account contamination. In this type of contamination, if one account gets compromised, it affects the other accounts hosted on the same server. In addition, the resources of the other accounts are also misused, resulting in outages for other accounts on the server [1].

Today most security measures are based upon traditional rule and signature-based technologies, such as firewalls, IDS/IPS and antivirus software. They are designed to prevent known attacks, and are not very effective in preventing unknown or zero-day attacks. Also, the early stages of a complex attack may be very hard to detect with traditional means. Manually monitoring security data on a large shared hosting platform is not an option, due to the overwhelming amount of information that must be processed. Something more automated is needed [2].

Security analytics has been touted as a number of different solutions to achieve proactive security. Unfortunately, there is little information available about what type of data should be monitored in order to alert system administrators of an attack before significant damage is done. In this paper, we make two contributions: 1) We present an empirical study of an attack dataset collected from five production servers hosting 707 web sites over a period of 30 days. The systems we examine are multi-tenant Linux shared hosting systems with no security products installed. These scenarios are largely unexplored by the research community as they relate to proprietary cloud platforms as opposed to the open-source infrastructure of public clouds. 2) We also present a predictive security analytics system that not only alerts on potential attacks but also can remediate them prior to any damage being done. This is the first paper to take a 360-degree view of attacks on multi-tenant infrastructure. We are also the first to propose a proactive security analytics system that can monitor systems without impacting on-going transactions [3].

Literature Review

Multi-Tenant Security Challenges: Shared hosting is, as far as I can tell, a huge potential source of vulnerability. A few of the vulnerabilities include: - With shared hosting, you are more likely to run into security exploits due to the fact that you are using hardware, software, bandwidth, etc. on a server with a ton of other people. If a person’s site is hacked and a backdoor or exploity is left behind, there is a much higher chance that the entire server will be exploitable to other users on the server because of the many users that are logged in. - Session isolation on a shared server isn’t as isolated as you’d hope. Because you’re all using the same machine, the applications that you have logged into can quite feasibly access information from other users on the machine. In a very real way, your session IDs, and the information they contain, are “exposed” to the rest of the users on the shared server [1]. Cross account contamination refers to the attacks or scenarios where an attacker uses the proximity of accounts to gain elevated access or launch subsequent attacks across those accounts. This is considered a high severity threat Modern cloud environments are dramatically different from traditional on premises infrastructure. Many cloud security issues are unfamiliar to teams who are used to on premises environments [3]. Low cost and high volume is built in to the Shared Host pricing model. There is consequently little investment in preventative measures to mitigate threats, and security is generally only proactively implemented to core components, with reactive countermeasures being implemented as they are required [4].

Log-Based Anomaly Detection and Predictive Analytics

Authentication and system logs are a very good source of information for a security monitoring solution. Common sources include Apache/Nginx web server logs, auth.log and /var/log/secure, and ModSecurity/Fail2Ban logs [2,5]. In this talk we will demonstrate how we managed to apply the latest developments in machine learning such as Isolation Forest, One-Class SVM and Autoencoders, that are unsupervised learning algorithms, to identify unusual patterns of network traffic which indicate anomalous behavior. It is notoriously difficult to obtain enough labeled training data for all known types of attacks. So, this talk explores an alternative approach that uses the unsupervised learning paradigm to monitor the network activity [6]. Predictive analytics extends detection by forecasting future incidents through time-series analysis and supervised learning [7]. Federated learning has emerged as a promising approach for distributed log analysis across multiple servers [8].

Predictive Security Frameworks

Recent work has proposed AI-powered frameworks for adaptive threat management in multi-tenant cloud environments [9]. Centralised monitoring platforms have demonstrated effectiveness in managing distributed hosting setups [4]. All current frameworks are designed with cloud-native applications in mind running on cloud infrastructure and are not well suited to the traditional Linux Shared Hosting environment.

Research Gaps

Multi-tenant security has developed in recent years, but there are still some unsolved research questions. Unfortunately, we could not find any studies that analyse the security of traditional Linux systems in shared hosting environments where thousands of websites and accounts are hosted. In order to fill this knowledge gap, this paper performs an in-depth analysis of common shared hosting environments, including a large-scale national research network (NREN) infrastructure. Another gap is related to the investigation of the root causes of security incidents that are encountered [3]. Second, scalable predictive models for high-density environments with 500 or more co-located websites have not been rigorously evaluated. Third, the ethical implications of extensive AI-driven monitoring in shared hosting contexts, particularly regarding tenant privacy, require further investigation [10]. This paper attempts to fill these gaps by presenting an empirical study of the I/O activity of five production servers over a period of 30 days.

Experimental Environment

The research work was conducted on 5 production Linux shared web hosting servers provided by the author. The hardware and software details are shown in Table 1. 

Table 1: Server Infrastructure Specifications

None of the servers had Fail2Ban applications installed and there were no iptables DROP firewall rules on any of the systems. This is very common on small to medium sized shared web hosting sites and our test site provided an excellent opportunity to carry out empirical threat assessment.

Data Collection

The information used for this authentication log data was extracted from the system log on each server. The system log is different on each OS. On Ubuntu based systems, it is in /var/log/auth.log, on AlmaLinux in /var/log/secure. The older log files were also used to cover the full 30 days, that ended on 17 Mar 2026, starting from 15 Feb 2026. All failed authentication log messages, ip addresses of the brute force attempts, usernames that were targeted, and time of the attempts were extracted by using command line utilities like grep, awk, sort and uniq.

Anonymous Data was removed from this analysis: Client account usernames, which were housed on the server. They were ignored during the analysis and not are included in this report. IP addresses from the attacking systems were kept since they are external systems as opposed to client accounts housed on the server.

Metrics

The primary quantitative measure is the count of failed SSH login attempts (Failed password events) per server per week. Other quantitative measures include the number of unique IP addresses involved, the distribution of usernames targeted, and the attack volumes on the 5 servers. These measures give an idea of the frequency and characteristics of brute-force attacks in the testbed.

Overall Attack Volume

Over the course of the 30-day monitoring period, we detected a total of 1,460,787 failed SSH login attempts across the 5 servers we are currently watching. This data is summarized in Table 2 on a weekly basis for each of the systems. 

Table 2: Failed SSH Login Attempts by Server and Weekly Period

As one can tell by examining the tables, the rates at which these attempts were fired off the systems varied a great deal across all machines and virtually all times.

Server iwt2 recorded the highest total attack volume (480,976 attempts), followed by sh1 (422,246). The week of February 22 to March 1 was the most active across all servers, accounting for 546,856 attempts (37.4% of the 30-day total). This concentration suggests coordinated attack campaigns targeting multiple servers simultaneously during this period.

Unique Attacking IP Addresses

In Table 3 we list the number of unique attacking IP addresses for a given server over the last three days (March 15–17), which we use as a fixed short-term reference point for all servers. Across all servers, over the period of just three days, there were 1,674 unique IP addresses involved in the attacks.

Notably, IP address 206.189.202.201 appeared as the most active attacker on both iwt2 and alma1, contributing 2,450 attempts in the most recent log window on iwt2. Similarly, 193.32.162.82 was active across both mainsh and iwt1, suggesting coordinated multi-server attack campaigns originating from common sources.

Table 3: Unique Attacking IP Addresses and Top Attacking Sources

Targeted Username Analysis

Table 4 Targeted Usernames for all Servers in the Test Group The root account was the most targeted valid system account. Other than the root account, the most targeted accounts were mostly invalid usernames. Such attempts are typical of the brute force or dictionary attacks that attempt to guess valid names for the usernames to breach an account.

The number of failed login attempts for a username suggests a dictionary-based scanner is being used by an attacker to try a large number of usernames. A common trait of the site's username list was that the most common usernames were the same on all servers (root, admin, ubuntu, test). This implies that the attacker is likely using a common dictionary of usernames. The fact that some of the servers were also being hit for database service accounts (mysql, postgres) suggests the attacker is not limited to trying to login via SSH.

Table 4: Targeted Usernames Across All Servers (Current Log Window)

Security Controls Assessment

Table 5 summarises the state of active security controls across all five servers at the time of the study.

The complete absence of Fail2Ban across all five servers and the lack of any active iptables DROP rules means that all 1,460,787 recorded failed login attempts proceeded without automated blocking or rate-limiting. Attackers encountered no automated resistance, enabling sustained high-volume brute-force campaigns to continue uninterrupted throughout the 30-day observation period. This finding represents a critical security gap and directly motivates the proposed predictive analytics framework.

Table 5: Security Controls Assessment Across All Servers

Proposed Predictive Security Analytics Framework

Framework Overview

Based on the findings of the experiments done in this research, a predictive security analytics framework for large-scale multi-tenant Linux shared hosting environment has been proposed. The proposed framework addresses the vulnerabilities that have been exposed in this research study namely lack of automatic blocking, large-scale distributed brute-force attacks and variety of attack sources and victims.

Data Ingestion and Preprocessing

Lightweight agents such as Filebeat and rsyslog are installed on each machine in the environment. These agents pull authentication, web server and resource logs off the local log files and send them to a log aggregator node in real time. The data is then parsed into feature columns from the log data that include the timestamp of the event as well as the source IP, target username for authentication events, event type for both authentication and web server events and the identifier of the web server for web server events. The timestamp for these feature columns is then synchronized to match the timestamp of the system events they are being correlated against.

Anomaly Detection Module

Anomaly detection The anomaly detection module applies unsupervised machine learning to the identified behavior and output anomalies. Isolation Forest and One-Class SVM are used as the primary algorithms for the module as they can efficiently deal with scenarios where little to no labeled data is available and can identify two types of anomalies: - Point anomalies (an abnormal instance in the data) - Contextual anomalies (anomalies that occur in a particular context i.e. within a given time window) Dynamic baselines for each server and each hosting account are calculated in order to account for the changes in the normal traffic behavior.

Threat Classification and Correlation

Once an anomaly is detected by our scan component, it will be sent to our correlation engine. The correlation engine will then search through different sources and timeframes for any relevant information that it can use to make its findings more meaningful. All our correlation rules are built using known patterns of attacks such as: High frequency of login attempts from the same IP address (Brute-Force) High number of login failures spread across multiple IP addresses occurring after long periods of time (Distributed Brute-Force) High frequency of login attempts to many accounts within a short period of time (Credential Stuffing) Correlating information across multiple servers enables us to determine which IP addresses are involved in coordinated attacks and block them site wide across our entire infrastructure.

Automated Mitigation

The mitigation module will take the threat classification(s) that it has identified, and convert it into rules that can be applied on the firewall of the server, either by using iptables or the CSF (ConfigServer Security and Firewall) application. IP addresses that exceed the maximum failed attempts as defined within the threshold section for a given time frame will be blocked. Blocked IPs will be blocked across the cluster, meaning if an IP is blocked on one server it will be blocked across the entire cluster. Block duration will be dynamic and will be based on the nature of the attack as well as the severity of the IP that is attacking the server.

In our research so far we have uncovered a vast and very active threat landscape. Looking at a 30-day period, a 30-day period of 1,460,787 failed SSH login attempts against 707 virtual websites hosted on 5 servers, none of which were protected by any automated blocking mechanisms, shows that even shared hosting platforms using the most popular shared hosting software packages will remain almost constantly under attack if no counter measures are in place. The daily average of 48,693 attempts on the 5 servers we have been using in our testing, is clearly far too many to be managed in any way by a human operator.

The 37.4% concentration of monthly attack volume observed within a single week (February 22 – March 1) points away from simple opportunistic scanning activity and rather points towards coordinated attacks. The fact that an attacking IP reappears on different servers – as is the case with the IP 206.189.202.201 and 193.32.162.82 – indicates that an organised attack group is targeting the shared hosting environment.

Default Dictionary Seen in Username Pattern Appears to be part of a large-scale credential stuffing attack using default dictionaries. High rates of failed attempts (38% on sh1 and 67% on iwt2) seen at each location point towards a scanning activity to find mis-configured or legacy accounts and does not suggest a focused attack against human users, and therefore points more towards an opportunistic attack on the infrastructure.

This type of behavior would be blocked by our proposed framework. The cross-server IP correlation mechanism would have prevented the IP addresses of repeated attackers from being allowed through on any of the five servers. The per-IP rate limiting would have turned such high traffic attacks such as the 5220 login attempts from a single IP to sh1 into short-lived events that happen within a few minutes.

A major drawback of this work is that the ML model was not yet implemented and validated within the observation time frame. The empirical data used here forms the basis of the threat environment, the system framework and consequently the validation of the proposed countermeasures. The measures for the attack detection accuracy – precision, recall and F1-score – will be determined within the implementation of the prototype. Moreover, it should be mentioned that the five-server dataset used in this work is a typical example for small and medium-sized hosting infrastructure. It is not yet known how large hosting infrastructures (enterprise level) behave.

In this paper, we empirically investigated various types of security threats that were encountered on five production Linux shared web servers, which hosted 707 different websites, over a period of 30 days. The main results were that the servers were hit by 1,460,787 brute force SSH login attempts originating from 1,674 unique IP addresses, with no preventive measures implemented on any of the five systems. To the best of our knowledge, this is the first quantitative measure of brute force attacks on an average traditional Linux shared web hosting server in the open literature, in the absence of any preventive countermeasures, such as a login prevention system.

In light of the obtained results, we recommend a predictive security analytics framework for shared hosting environment using log-based anomaly detection, cross-server threat correlation and automated mitigation. Log analysis is a well-studied subject, while anomaly detection in the shared hosting environment and cross-server threat correlation remain unchecked due to operational challenges and the different threat profile faced by multi-tenant shared hosting environments compared with cloud-native environments. The proposed framework bridges this research gap. In our future work, we will be implementing and testing the proposed framework on the study servers and evaluating its performance metrics such as true detection rate, false alarm rate and the reduction of effective attacks reaching the system defenses.

Conflict of Interest Statement

The author declares no conflict of interest. The research was conducted using servers managed by the author in a professional capacity. No external funding was received for this study.

Acknowledgements

The author acknowledges the support of the Department of Cybersecurity, College of Computer Science and Mathematics, Tikrit University, Iraq.

1. Gruber, J. et al. "Contamination of Digital Evidence: Understanding an Emerging Challenge." ScienceDirect, 2023.

2. "Comprehensive Analysis and Evaluation of Anomalous User Activity in Web Server Logs." MDPI Sensors, 2024.

3. "Abusing Locality in Shared Web Hosting." ResearchGate, 2020.

4. "How Shared Hosting Providers Respond to Vulnerability Disclosures." arXiv, 2025.

5. "Enhancing Anomaly Detection in Linux Audit Logs with AI." NVIDIA Developer Blog, 2024.

6. "Best Practices for Anomaly Detection on Linux Servers." WafaTech, 2025.

7. Kataria, N. "AI-Assisted Forecasting and Capacity Planning in Multi-Tenant Environments." International Journal of Artificial Intelligence, Data Science and Machine Learning, 2026.

8. Himler, P. et al. "Anomaly Detection in Log-Event Sequences: A Federated Approach." ScienceDirect, 2024.

9. "Enhancing Security and Performance in Multi-Tenant Cloud Computing Environments." ResearchGate, 2025.

10. "International AI Safety Report 2026." internationalaisafetyreport.org, 2026.