Mastering Linux Security: Real‑World Attack Vectors and Defense Strategies

Preface

In practice, the hardest attacks to defend are those close to the application layer, such as bots targeting private live‑stream protocols that can overwhelm channel, login, and payment services, eventually turning into DDoS attacks.

The closer to the application layer, the more difficult and risky the defense becomes, requiring a combination of big‑data analysis, machine learning, and traffic modeling, whereas lower‑level attacks have more mature solutions.

Business‑level DDoS attacks on private protocols (YY protocol, audio/video protocols) are especially challenging; for example, if a system can only handle 20 million PCU and traffic exceeds that, flexible mitigation strategies are needed.

The following three parts cover the author’s practical experience at YY Live.

1. Linux Security Landscape

YY Live runs tens of thousands of Linux servers, with only a few hundred Windows machines, reflecting the high Linux adoption in internet companies.

Why Linux security is complex

Linux’s widespread open‑source ecosystem brings many components and frameworks, which in turn introduces numerous vulnerabilities:

Struts2 Remote Code Execution (CVE‑2017‑5638)

Linux Kernel Privilege Escalation – Dirty Cow (CVE‑2016‑5195)

ElasticSearch Remote Code Execution (CVE‑2014‑3120)

Bash Remote Execution (CVE‑2014‑6271)

Nginx Remote Code Execution (CVE‑2014‑0088)

MongoDB Anonymous Login

Heartbleed

1.1 Vulnerability Impact

Struts2 vulnerabilities often require 24‑hour patching; failure can halt business. Dirty Cow is a well‑known privilege‑escalation bug that affected many servers. Ransomware based on DDoS extortion and MongoDB data theft are also common.

1.2 Linux Security Challenges

Rapid business iteration, open network boundaries, diverse open‑source components, complex architectures, and lack of standardization all increase security difficulty. Frequent version releases leave little time for thorough security design, and distributed deployments create complex network perimeters.

1.3 Real‑World Production Issues

Common problems include unknown processes consuming resources, inability to kill stubborn processes, key leakage (e.g., keys stored in emails), Redis default anonymous access leading to data loss, and OOM caused by hidden malware.

2. Linux Attack Techniques

2.1 Attack Vectors

Understanding the attacker’s methods is essential. A typical case is exploiting Redis’s default anonymous login to write a reverse shell.

2.2 Penetration Steps

Typical penetration workflow:

Scan to discover live IPs and firewall status.

Probe open ports and services.

Identify vulnerable open‑source components or misconfigurations.

Gain foothold, then elevate privileges to root.

2.2.1 SSH Brute‑Force

Best practice is to restrict SSH access to jump hosts and change the default port to reduce exposure.

2.2.2 History Manipulation

Attackers may clear command history to hide their tracks; clearing history after a session is recommended.

2.2.3 Redis Exploitation

Redis’s anonymous access allows writing a reverse shell to the filesystem; disabling unauthenticated access mitigates this risk.

2.2.4 Privilege Escalation Demo

Demonstrations of kernel‑level privilege escalation (e.g., Dirty Cow) show how a regular user can obtain root privileges, emphasizing the need for timely patching.

2.2.5 Process Injection

Injection requires understanding ELF format, system calls, and the RIP register to hijack execution flow.

3. Linux Defense Strategies

3.1 Layered Defense

Vulnerability scanning, intrusion detection, proactive defense, alerting, behavior audit, incident response, and standardization together form a comprehensive defense strategy.

Balancing security with rapid business releases is crucial; excessive gating can hinder product velocity.

3.2 Practical Defense Measures

3.2.1 Vulnerability Scanning

Automated scans trigger email alerts with a 24‑hour remediation window for discovered vulnerabilities.

3.2.2 Intrusion Detection

Suspicious processes generate real‑time alerts to prevent business impact.

3.2.3 Behavior Auditing

Monitoring abnormal command history clearing or key leakage helps identify compromised accounts.

3.2.4 Incident Response

Pre‑defined response plans for DDoS spikes or intrusion events ensure rapid mitigation and root‑cause analysis.

3.2.5 Standardization

Establishing security standards aligned with company culture and development stage improves overall resilience.

Conclusion

Absolute security does not exist; continuous improvement, balancing security with business agility, and applying models like PDCA are essential for effective Linux attack‑defense cycles.