In the process of using cloud servers, almost every operations and maintenance personnel will experience malicious scanning, brute-force login attacks, and frequent probing of websites or ports. With the openness of the internet and the widespread availability of cloud computing resources, this phenomenon has become commonplace. Whether the server is deployed domestically or overseas, as long as it is exposed to the public internet, attack traffic and port scanning occur almost daily. Many people mistakenly believe that only large enterprises or high-traffic websites become targets; in reality, most scans are randomly executed by automated scripts or botnets. Their purpose is not to target specific business needs, but to find system vulnerabilities, weak passwords, open ports, or misconfigured hosts. Once exploited, this can lead to anything from excessive CPU and bandwidth usage to data breaches or even system compromise.

　　When a server is being scanned or attacked, the first step is to identify the type of threat. Common attacks include brute-force attacks on SSH or RDP logins, web application vulnerability scanning, DDoS attacks, open port probing, and man-in-the-middle attacks. Different types of attacks require different levels of defense. At the system's core, ports are the entry point for attacks; therefore, managing and hiding ports is the first step in defense. After deploying a cloud server, many users tend to keep the default configurations, such as SSH port 22, database port 3306, and remote desktop port 3389. These default ports are most easily identified and brute-forced by scanning tools, so it is recommended to change the default ports immediately during the initial deployment phase. Taking Linux systems as an example, you can edit the SSH configuration file:

vim /etc/ssh/sshd_config
Port 2222
PermitRootLogin no
PasswordAuthentication no

　　After changing the port number, restart the SSH service:

systemctl restart sshd

　　At the same time, direct login as the root user should be disabled, and a connection should be established using a regular user account with a key to completely eliminate the possibility of brute-force password cracking.

　　If it is a Windows cloud server, the RDP (Remote Desktop) port should be changed. This can be done through registry operations:

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 23389 /f

　　A system restart will take effect after the changes are made. In addition, cloud vendors generally provide security group management functions, which can further restrict access from an external level. For example, only necessary ports such as 80, 443, 22 (or a new port), and 3389 (or a new port) can be opened, and access sources can be restricted to specific IP ranges. This way, even if a scanning script detects the port, it cannot establish a connection, fundamentally reducing the risk.

　　When a server has already suffered a large-scale port scan or attack, analyzing logs is key to locating the problem. Linux users can quickly check SSH login attempts using the following command:

grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head

　　This lists the IP addresses from which brute-force attacks are originating and the number of attempts. If certain IP addresses appear frequently, they can be blocked directly through a firewall. For example, using iptables:

iptables -A INPUT -s 192.168.1.100 -j DROP

　　Or use firewalld:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' drop"
firewall-cmd --reload

　　If using ufw (Ubuntu's default firewall), the command is even simpler:

ufw deny from 192.168.1.100

　　These commands can quickly block abnormal IP ranges to prevent them from continuing to access the network. For large-scale scans, the Fail2ban automated blocking mechanism can be used. Fail2ban monitors system logs and automatically adds the same IP to the firewall blacklist when it detects repeated failed attempts.

apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

　　The configuration file is located at /etc/fail2ban/jail.local, and the blocking policy can be adjusted as needed.

[sshd]
enabled = true
port = 2222
filter = sshd
maxretry = 3
findtime = 600
bantime = 3600

　　This way, if an IP address commits three incorrect passwords within 10 minutes, it will be blocked for one hour, significantly reducing the risk of brute-force attacks.

　　For web attacks and port scanning, it is recommended to use a firewall in conjunction with a Web Application Firewall (WAF). Common attacks such as SQL injection, XSS, directory traversal, and scanner requests can all be blocked by a WAF. For example, users who have installed Nginx can add simple anti-scanning rules:

if ($http_user_agent ~* (acunetix|sqlmap|nikto|nmap|dirbuster)) {
    return 403;
}

　　This rule can directly block access from common scanning tools. For more complex defense needs, security components can be used. These can not only detect abnormal traffic but also automatically identify malicious patterns and block attacking IPs.

　　Besides application-layer defense, network-layer protection is equally important. When server response slows down or bandwidth usage is abnormal, it may be a DDoS attack. This type of attack overwhelms bandwidth or CPU with a large number of requests, causing service inaccessibility. Countermeasures include enabling cloud provider protection services or enabling SYN cookies on the server side and limiting the number of concurrent connections. For example, in Linux, execute:

sysctl -w net.ipv4.tcp_syncookies=1
iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT

　　This can alleviate connection overhead caused by SYN Flood attacks.

　　If the attack intensity is too high and the duration is long, temporary network disconnection or changing the public IP address can be used. Some cloud services support quick replacement of elastic public IP addresses, which can temporarily interrupt the attacker's scanning process. However, this method is only a stopgap measure; fundamental protection still requires strengthening configuration at the system level.

　　For long-term protection, it is recommended to deploy an Intrusion Detection System (IDS) and security monitoring. For example, installing OSSEC, Wazuh, or AIDE can regularly scan for file integrity, detect permission changes, and identify system anomalies. If the server is compromised, these tools can help quickly locate the intrusion path.

　　Server logs should be backed up regularly and automatically rotated using logrotate to prevent logs from being overwritten. For example, add the configuration file `/etc/logrotate.d/nginx`:

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload nginx > /dev/null 2>&1 || true
    endscript
}

　　This maintains nearly two weeks of log records for later analysis.

　　Besides technical measures, security strategies are equally crucial. Any cloud server should adhere to the "least open" principle, opening only ports necessary for business operations and setting complex passwords and multi-factor authentication (MFA). Use the cloud console's SSH key pair login function instead of plaintext passwords. High-risk services such as databases and management backends should not be directly exposed to the public network; they can be accessed through the internal network or by enabling a jump server mechanism.

　　In a security defense system, monitoring and response are the final link. Administrators should set up security alert mechanisms, such as through Fail2ban, UFW, or the cloud vendor's monitoring system, to immediately send email or SMS alerts when abnormal logins, port scans, or abnormally high CPU usage occur. Additionally, scheduled tasks can be added to crontab to periodically check system port status.

netstat -tulnp | grep LISTEN > /root/port_status.log

　　The system compares the current state with the previous one using a script, and immediately issues an alert if a new port is found.

　　For operations teams, protection is not a one-off task, but a continuous optimization process. As attack methods evolve, firewalls and blocking rules alone are insufficient to guarantee security. More advanced strategies include Security Automated Orchestration (SOAR), real-time traffic analysis, and threat detection combined with AI. Even individual developers can leverage open-source tools to create lightweight security loops and achieve dynamic, interconnected defenses.

　　The ultimate goal is to achieve a balance between high availability and high security for servers. Over-defense can lead to service unavailability, while insufficient protection leaves hidden vulnerabilities. Therefore, a reasonably layered security system is crucial: network layer defense is responsible for resisting external flood attacks, system layer defense is responsible for port and account security, and application layer defense focuses on website vulnerabilities and data security. Only when these three layers work together can stability be maintained in the face of complex attacks.

　　In the global cloud computing environment, attack frequency has become the norm and cannot be completely avoided. What we can do is minimize losses through log analysis, automated defense, and good security practices. Whether it's a personal project or a corporate server, once connected to the public network, security must be the top priority in operations and maintenance. Prevention is always more cost-effective than remediation; only by establishing a robust security system can servers provide stable and reliable service throughout their long operational lifecycle.