An internet-exposed server is a constant target, regardless of the time of year. To demonstrate this, I set up a honeypot and left it online for seven days in August, a period often perceived as quieter. The collected data is clear: malicious activity never stops, and every system accessible from the network is under constant scrutiny. The objective was to quantify the volume and type of attacks directed at a freshly installed Linux system, without specific hardening, simulating a server that might have been overlooked or superficially configured. The data gathered offers a realistic snapshot of the daily threat faced by IT infrastructures.
Tested on: Ubuntu 22.04 LTS · Cowrie Honeypot 2.4.0 · August 2026
Prerequisites / Test Environment
For this analysis, I used Cowrie, a low-interaction SSH and Telnet honeypot. Cowrie emulates a Linux system, logging every access attempt, command executed, and file downloaded by attackers. The honeypot was installed on a VM running Ubuntu 22.04 LTS, directly exposed to the internet with a public IP address. No additional hardening or security configurations were applied, beyond the basic requirements for Cowrie’s operation. The choice of August was intentional: it’s a month when many organizations operate with reduced staff, potentially slowing down incident response. This scenario helps understand what happens to an exposed server without active protection, a risk many legacy or misconfigured environments face daily.
What Happens to an Exposed Server in August
During the seven days of exposure (August 5th to 12th), the honeypot recorded incessant activity. The most significant traffic was directed towards the SSH service, with an average of almost 170 login attempts per day. These attempts were almost exclusively brute-force, with attackers trying common username and password combinations. Read also: Passwordless SSH Linux: Configure Keys in 5 Minutes (2026)
Analyzing SSH Traffic
The main Cowrie log shows a continuous stream of failed authentication attempts. The most targeted usernames included ‘root’, ‘admin’, ‘user’, ‘test’, and service names like ‘oracle’ or ‘postgres’. Attempted passwords were often weak or default. This type of attack is automated and does not require advanced skills, but it is extremely effective against systems with weak credentials or those not protected by mechanisms like account lockout or MFA.
To analyze login attempts, I used simple commands to extract and count data from Cowrie logs:
# Count failed SSH login attempts
grep 'Failed password' cowrie.log | wc -l
# Identify the most common usernames used in attacks
grep 'Failed password' cowrie.log | awk '{print $9}' | sort | uniq -c | sort -nr
# Identify the most active source IP addresses
grep 'Failed password' cowrie.log | awk '{print $11}' | sort | uniq -c | sort -nrScans and Web Exploit Attempts
Beyond SSH, the honeypot also recorded web scanning attempts. Although Cowrie is primarily an SSH/Telnet honeypot, I observed HTTP traffic on common ports (80/443) indicating automated scans for vulnerable directories or exposed web services. These attacks aim to identify known CMS installations, administration panels, or sensitive configuration files. While Cowrie doesn’t emulate a full web server, logging these HTTP requests in system or firewall logs is an important signal.
For a deeper analysis of web traffic, a specific honeypot like Dionaea or a web application firewall (WAF) in logging mode would be necessary. However, the presence of these scans confirms that attackers look for any weak point, not just standard management service ports.
Geographical Origin and Attacker Typology
Source IP addresses for attacks originated from a wide range of countries, with a strong concentration from regions known for hosting botnets and malicious infrastructure. I identified over 20 unique IPs that attempted persistent attacks. These were not sophisticated actors, but rather automated bots scanning the internet for easy targets. Their persistence is the real threat: even if each individual attempt can be blocked, the overall volume can overwhelm defense systems or go unnoticed without adequate monitoring. Read also: UFW Firewall Ubuntu: Complete Configuration from A to Z (2026)
This constant activity underscores the importance of implementing geoblocking or blocklists for known IPs, even if these measures are not a definitive solution.
Common Errors and Troubleshooting
A common mistake in managing exposed servers is underestimating how quickly they are detected and attacked. A server without a configured firewall or with weak credentials can be compromised in hours, if not minutes. Another error is relying solely on a single defense mechanism. While a honeypot is useful for intelligence gathering, it is not an active security solution. It is crucial to combine the use of firewalls, intrusion detection/prevention systems (IDS/IPS), multi-factor authentication (MFA), and strong password policies. Read also: Fortinet PSIRT: Segmented Network Exposure Assessment
In case of compromise, timely response is critical. A honeypot can help understand attacker tactics, but a real production system requires a well-defined incident response plan, with procedures for isolating, remediating, and restoring systems. Lack of adequate logging is another problem: without detailed logs, it is almost impossible to understand what happened or how the compromise occurred.
FAQ – Frequently Asked Questions
Do attacks decrease during holiday periods?
No, honeypot data shows that automated attacker activity remains constant. Bots do not take holidays and continue scanning the internet 24/7. In fact, holiday periods might be seen as an opportunity by attackers, knowing that IT team vigilance and responsiveness could be reduced.
What is the first step to protect an exposed server?
The first step is to implement a firewall (like UFW on Linux or FortiGate) to limit access to only necessary ports and services. Subsequently, it is crucial to configure SSH authentication to use only public keys and disable direct root access, as well as implement a system like Fail2ban to block IPs attempting brute-force logins.
Can a honeypot be compromised?
Yes, although a honeypot is designed to be a secure environment for data collection, misconfiguration or vulnerabilities in the honeypot software itself can expose it to risks. It is important to keep it updated and isolated from the production network to prevent it from becoming an entry point for real attacks.
Should I disable Telnet?
Absolutely. Telnet is an insecure protocol that transmits credentials in plaintext. Although less common than SSH, I observed Telnet login attempts on the honeypot. Disabling Telnet and using only SSH (with appropriate security measures) is a fundamental practice.
Conclusions with Operational Takeaways
The August honeypot experiment confirmed a crucial fact: cyber threats are persistent and automated. Every server exposed to the internet is a target, regardless of its purpose or the time of year. The operational takeaways are clear:
- Firewall: Configure a firewall to expose only strictly necessary services.
- SSH Hardening: Disable direct root access, use only SSH keys, implement MFA, and change the default SSH port (while not a security measure, it reduces log noise).
- Monitoring: Implement a log monitoring system (SIEM/EDR) to detect login attempts and anomalies in real-time.
- Awareness: Educate the IT team on the importance of perimeter security, even during periods of lower activity.
Do not wait for a real incident to strike to understand the importance of security. Every second of unprotected exposure is a calculated risk that could prove costly.
Sources
Updated: August 2026
