Stay Ahead With Linux Security HOWTOs
How to Secure My Network
access control Linux administration
access control Linux administration Most SSH hardening advice ends at the same recommendation: Disable password authentication and use SSH keys. . That's good advice. It removes entire classes of attacks, including password spraying, credential stuffing, and brute-force attempts against exposed servers. The problem is what happens next. Many administrators treat SSH keys as the finish line when they are really the beginning of the hardening process. Attackers rarely care whether they obtained access with a password or a private...
Jun 05, 2026
How to Secure My Networksecurity advisory remote access
security advisory remote access Most of the time, nobody notices. SSH authentication succeeds, no alerts are generated, and the connection looks exactly the way it did the day the key was installed. That's part of the problem. . When security teams investigate unauthorized access on Linux systems, they often focus on passwords, exposed services, or vulnerable software. Trusted access receives less attention. Yet a single forgotten or unauthorized SSH key can provide the same access as a legitimate user while attracting very...
Jun 03, 2026
How to Secure My Networkintrusion detection application security
intrusion detection application security The wrong IPS rule can look like a security fix right up until it becomes an outage. . On Linux systems, detection and prevention are often discussed together, but they do not carry the same operational risk. One tells admins that something suspicious happened. The other can decide whether traffic is allowed to continue. That is why IDS vs IPS is not just a definition to memorize. It is a deployment decision about where to monitor, where to block, and how much confidence a team needs before...
Jun 01, 2026
How to Secure My Networkunauthorized access security techniques
unauthorized access security techniques Exposed SSH servers are continuously hammered by brute-force attacks, password spraying, credential stuffing, and recycled passwords from infostealer dumps. Attackers rotate usernames, test weak credentials, and probe for anything that gives them initial access. The logs usually look messy long before the compromise happens. . The difficult part is separating harmless failures from actual intrusion activity. One failed login from an internal workstation rarely matters. Repeated failures...
May 28, 2026
How to Secure My Networksecurity advisory incident response
security advisory incident response The first 30 minutes after discovering a compromised Linux server usually decide how much evidence remains available. One rushed reboot or cleanup attempt can wipe logs, terminate malicious processes, or remove network activity that investigators still need to review. Attackers also do not usually stay on one system for long once access is established. Early response is mostly about preserving visibility. Collect process information. Save network connections. Limit access carefully before...
May 28, 2026
Refine HOWTOs
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security HOWTOs
We found 2 articles for you...
167
security advisoryincident responsemalware detectionHow to Respond After Detecting a Compromised Linux Server
The first 30 minutes after discovering a compromised Linux server usually decide how much evidence remains available. One rushed reboot or cleanup attempt can wipe logs, terminate malicious processes, or remove network activity that investigators still need to review. Attackers also do not usually stay on one system for long once access is established. Early response is mostly about preserving visibility. Collect process information. Save network connections. Limit access carefully before making major changes to the system. . Step 1: Verify the Server Is Actually Compromised Start by confirming the server is actually compromised. Broken applications, failed deployments, and unstable services can create symptoms that look malicious at first. Early triage is mostly about identifying unauthorized access, suspicious processes, and unexpected network activity before making changes to the system. who w last -a Look closely at: Unknown usernames Source IP addresses you do not recognize Logins at unusual hours Simultaneous sessions from different locations Sessions that remain active longer than expected An SSH login from another country at 3 AM does not automatically confirm compromise, but it should immediately raise questions. The same goes for service accounts logging in interactively when they normally do not. Once login activity looks suspicious, move directly into process inspection. Attackers often leave behind running malware, reverse shells, persistence scripts, or crypto miners. ps auxf top pstree -p This stage is less about memorizing process names and more about spotting behavior that feels wrong for the system. Things worth investigating include: Suspicious Behavior Why It Matters Processes running from /tmp Malware often hides in temporary directories Randomized process names Attackers rename malware to avoid detection Unexpected parent-child relationships A web server spawning shells is a bad sign High CPU usage with no explanation Common with crypto mining malware Shells started by application users May indicate command execution abuse A compromised web server spawning /bin/bash underneath an Apache or Nginx process deserves immediate attention. After checking processes, inspect network activity. A server talking to unfamiliar systems or listening on unexpected ports may already be under remote control . ss -plant lsof -i -P -n Pay attention to: Unknown listening ports Outbound connections to unfamiliar IPs Established sessions with cloud VPS providers Reverse shell behavior Services binding to unusual interfaces A reverse shell often appears as a process maintaining an outbound connection to a remote host over a strange high-numbered port. If the server normally only handles web traffic but suddenly maintains persistent outbound sessions to external infrastructure, that is not normal operational behavior. Step 2: Do Not Reboot the Server Yet In most cases, rebooting a compromised Linux server too early destroys valuable evidence . Memory-resident malware disappears. Active network connections vanish. Temporary files get deleted. Shell history stored only in memory may never be recoverable again. A reboot can also terminate the exact malicious process you were trying to investigate. That sounds helpful until you realize it removes the ability to understand what the attacker was doing, how they got in, and whether they still have access somewhere else. The following artifacts may disappear after a reboot: RAM-based malware Active reverse shells Running attacker processes Unsaved shell history Temporary files under /tmp Active network sessions Evidence tied to process memory Avoid rebooting the server unless the situation is actively getting worse. Preserve logsfirst. Save process information. Capture active network connections before changing services or killing processes. In ransomware or destructive attacks, emergency shutdowns may still become necessary. Outside of those situations, immediate reboots usually create more problems for the investigation. Step 3: Isolate the Server Carefully Most compromised servers should be isolated quickly, but investigators still need access to the system. The goal is to limit attacker movement without cutting off visibility completely. Good containment limits external access while keeping the server reachable for evidence collection and review. Good Containment Methods Action Why It Helps Remove the server from the load balancer Prevents users from reaching a compromised application Restrict inbound traffic with firewall rules Limits new attacker access Isolate the system in a dedicated VLAN Reduces lateral movement risk Block internet egress traffic Stops outbound command-and-control communication Preserve secure SSH access Allows investigators to continue evidence collection A cloud workload might be isolated by changing security groups. An on-premises server might move into a quarantine VLAN. The exact method changes between environments, but the objective stays the same. Bad Containment Methods Some responses create more problems than the attackers themselves. Pulling the power cable Wiping the virtual machine immediately Deleting suspicious files before analysis Restarting services blindly Running cleanup scripts without evidence collection Deleting malware immediately feels productive, but it often destroys indicators investigators need later. The same malicious file may reveal persistence methods, attacker tooling, or lateral movement paths across the environment. Containment should slow the attacker downwithout destroying the evidence trail. Step 4: Capture Volatile Evidence Immediately Volatile evidence disappears fast. Running processes terminate. Network connections close. Logs rotate. This is the stage where responders start preserving everything they may need later for investigation, reporting, or legal review. Begin with process information. Save Process Information These commands create snapshots of currently running processes. ps auxf > /root/processes.txt pstree -p > /root/pstree.txt The redirected output preserves the process tree exactly as it existed during the investigation. That matters because attackers often terminate malware once they realize they have been detected. Move next into network evidence. Save Network Connections ss -plant > /root/network_connections.txt lsof -i -P -n > /root/open_sockets.txt This helps identify: Remote command-and-control infrastructure Reverse shells Internal lateral movement Suspicious listening services Unexpected outbound sessions A single established connection to an unfamiliar VPS provider can become the clue that ties the compromise together later. Then, preserve user activity. Save Logged-In User Activity who > /root/logged_in_users.txt last -a > /root/login_history.txt Historical login records often reveal how long the compromise existed before detection. Attackers regularly use valid credentials after initial access, especially when moving laterally. Logs should also be preserved before rotation occurs. Preserve Logs Before Rotation cp -r /var/log /root/log-backup journalctl > /root/journalctl.txt Linux systems rotate logs automatically. A busy server may overwrite critical authentication or application records quickly , especially during active attacks. Useful logs commonly include: Log Source What It Reveals /var/log/auth.log SSH logins and failed authentication /var/log/secure Security-related events on RHEL-based systems journalctl Systemd event history Web server logs Exploitation attempts and suspicious requests Cron logs Unauthorized scheduled tasks At this stage, documentation matters almost as much as evidence collection. Record timestamps. Save commands used during the investigation. Keep notes on every change made to the server. Step 5: Check for Persistence Mechanisms Attackers rarely compromise a server and leave voluntarily. Persistence mechanisms help them regain access after reboots, password resets, or partial cleanup efforts. This is why compromised systems often appear clean at first and then become compromised again days later. Cron jobs are one of the most common persistence methods on Linux systems. Inspect Cron Jobs crontab -l ls -la /etc/cron* Look for: Scripts executing from /tmp Obfuscated shell commands Base64-encoded payloads Unknown scheduled jobs Tasks running as root unexpectedly Attackers like cron because it survives reboots and blends into normal system administration. SSH keys are another common persistence method, especially after credential theft. Review SSH Keys cat ~/.ssh/authorized_keys Unauthorized SSH keys allow attackers to reconnect without passwords. Compare keys against known administrators and remove anything unexplained only after preserving copies for investigation. Persistence also appears inside systemd services. Inspect Systemd Services systemctl list-units --type=service systemctl list-unit-files Suspicious services often: Use vague names Restart automatically Execute scripts from unusual directories Launch hidden shells or networking tools A fake service named system-update.service launching a binary from /tmp/.cache should not be ignored. Startup scripts deserve inspection too. Check StartupScripts Common locations include: /etc/profile /etc/rc.local /etc/init.d/ /etc/bash.bashrc Attackers sometimes inject commands directly into startup scripts so malware launches every time a user logs in or the server boots. Kernel-level persistence is harder to detect and far more dangerous. If root access was obtained, trust in the operating system itself becomes questionable. Step 6: Determine How the Attackers Got In Understanding the initial entry point matters because cleanup without fixing the original weakness usually leads to reinfection. Attackers rarely use complicated techniques when simple exposure works. The most common Linux compromise paths include: Exposed SSH services Weak or reused passwords Vulnerable web applications Public-facing admin panels Credential theft through phishing Unpatched software packages Default credentials left unchanged Authentication logs provide a good starting point. lastb grep "Failed password" /var/log/auth.log Large numbers of failed SSH logins may indicate brute-force activity. A successful login immediately after repeated failures deserves investigation. Web servers should also be reviewed carefully. Exploited applications often leave traces in access logs. Things to look for include: Indicator Possible Meaning Requests containing long encoded strings Command injection attempts Requests to unknown PHP or JSP files Web shell activity POST requests to admin endpoints Credential abuse Repeated exploit attempts Automated scanning Outdated packages create another common entry point. Attackers routinely target publicly known vulnerabilities within days of disclosure. The longer internet-facing systems remain unpatched, the higher the risk becomes. The investigation may eventually show that the compromise began outside the server itself. Stol FinalThoughts A compromised Linux server can turn into a larger incident quickly if the response is rushed. Reboots, cleanup attempts, and configuration changes made too early often remove the evidence investigators still need. Early response work is mostly about preserving visibility long enough to understand the scope of the compromise. Save process data. Preserve logs. Identify active connections. Check whether the attacker established persistence or moved into other systems. A server may also appear stable after basic remediation while the original access path still exists. Unpatched applications, exposed admin services, stolen SSH keys, and reused credentials commonly lead to repeated compromise. In higher-severity incidents, rebuilding from a trusted image is often safer than attempting partial cleanup on a compromised host. Especially after root-level access or suspected persistence inside the operating system. FAQ Should I disconnect a compromised Linux server from the network immediately? Usually, yes, but isolation should be controlled. The goal is to limit attacker movement while preserving evidence and maintaining investigator access. Instead of powering the server off immediately, restrict inbound and outbound traffic carefully. Remove the system from production traffic if possible while preserving secure access for forensic review. Should I reboot a hacked Linux server? Usually no. Rebooting destroys volatile evidence, including memory artifacts, active attacker sessions, temporary malware files, and live network connections. Exceptions exist during destructive ransomware events or situations where active compromise threatens other systems immediately. What logs should I check after a Linux server compromise? Start with authentication and system logs. Common sources include: /var/log/auth.log /var/log/secure journalctl Apache or Nginx access logs Cron logs Audit logs Application logs These logs help identify loginactivity, exploitation attempts, persistence, and lateral movement. How do attackers maintain persistence on Linux servers? Attackers commonly maintain persistence through: SSH authorized keys Cron jobs Systemd services Startup scripts Web shells Kernel modules Hidden user accounts Persistence mechanisms are designed to survive reboots and partial cleanup. Can a compromised Linux server ever be trusted again? Sometimes, but root-level compromise changes the situation significantly. If attackers gained administrative access, complete trust in the operating system may be impossible to restore confidently. Many organizations rebuild compromised systems entirely instead of attempting a deep cleanup. What is the first thing to collect during incident response? Volatile evidence should be collected first. That usually includes: Running processes Active network connections Logged-in users Memory artifacts Open sockets Authentication logs This information disappears quickly once systems reboot or attackers detect investigation activity. Related Reading What Is SELinux? A Practical Take for Linux Admins Understanding Log Management and Analysis Tools for Linux Systems Top Linux Vulnerability Scanners in 2026: A Guide to Open-Source Security Tools Why CI/CD Pipelines Became Targets in Software Supply Chain Attacks RubyGems Attack Highlights Open Source Supply Chain Risks for Linux Teams . Learn critical steps to respond effectively after detecting a compromised Linux server to preserve evidence and contain threats.. Linux Security Incident Response, Server Compromise Analysis, Malware Detection Tactics, Evidence Preservation Strategies. . Dave Wreski
May 28, 2026
•
How to Secure My Network
167
incident responseopen sourcesecurity toolsKali Linux Tutorial: Using Pentesting Tools And Best Practices
Kali Linux turns 10 this year, and to celebrate, the Linux penetration testing distribution has added defensive security tools to its arsenal of open-source security tools. . It remains to be seen if Kali Purple will do for defensive open source security tools what Kali Linux has done for open source pentesting, but the addition of more than 100 open source tools for SIEM , incident response , intrusion detection and more should raise the profile of those defensive tools. For now, Kali is primarily known for its roughly 600 open source pentesting tools, allowing pentesters to easily install a full range of offensive security tools. In this article, we’ll focus primarily on how to use this powerful OS to run a pentest and mistakes to avoid. We’ll give you an overview of what can be achieved with Kali Linux using a short selection of pre-installed tools. While this guide serves as an introduction to common pentesting phases , with practical examples that highlight best practices, it’s not a substitution for a complete professional pentesting methodology. . Explore Kali Linux's pentesting tools and best practices for effective security assessments and defensive measures.. linux, turns, celebrate, penetration, testing, distribution. . Brittany Day
May 06, 2023
•
How to Secure My Network
167
digital forensicsincident responseUnix systemsKey Procedures for Conducting Forensic Analysis on Unix Systems
This document, written by Dave Dittrich, provides a great foundation for performing a postmortem on your box once it's been rooted.. . This paper, written by Sarah Lang, details crucial procedures for performing forensic investigations on breached Linux environments.. Forensic Analysis, Unix Systems, Digital Forensics, Incident Response. . Anthony Pell
Nov 29, 2004
•
How to Secure My Network
160
incident responseOpenBSDUnixIncident Response Tools For Unix: OpenBSD, Linux, And More
This article is the first in a three-part series on tools that are useful during incident response and investigation after a compromise has occurred on a OpenBSD, Linux, or Solaris system.. . Explore the world of Unix systems through this insightful introduction to key incident response tools, aimed at improving security and optimizing efficiency. Incident Response Tools, Unix Security, System Investigation. . Anthony Pell
Nov 23, 2004
•
How to Harden My Filesystem
167
network securityincident responserisk assessmentDeveloping a Comprehensive Network Security Policy Guide
This documentation discusses how one can correctly creat a network security policy. This document is divided into three areas: preparation, prevention, and response.. . Establishing a solid network security policy is vital for protecting digital assets. Focus on preparation, prevention, and response to safeguard your organization. Network Security, Policy Guidelines, Risk Management. . Anthony Pell
Nov 23, 2004
•
How to Secure My Network
160
intrusion detectionDoS attackincident responseIntrusion Detection Strategies for Access Attempts and DoS Threats
This documentation will discuss intrusion detection and help you recognize and detect port probes, port scans, denial of service (DoS) attempts and unauthorized access attempts.. . This guide assists you in identifying and monitoring intrusion risks such as network scans and denial-of-service attacks.. Intrusion Detection Strategies, DoS Attacks, Access Attempts, Security Monitoring. . Anthony Pell
Nov 23, 2004
•
How to Harden My Filesystem
167
incident responsesystem recoverysecurity guidelinesProcedures to Follow for Recovering from UNIX or NT System Breach
This documentation sets out suggested steps for responding to a UNIX or NT system compromise.. . Follow these steps to handle a security breach effectively: identify issues, isolate systems, assess damage, and ensure backups before taking action. System Recovery, UNIX Security, Incident Management. . Anthony Pell
Nov 23, 2004
•
How to Secure My Network
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More