Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
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 news
We found 1 articles for you...
77
security advisoryremote accessLinux administrationSecuring Remote Access to Linux Servers: Best Practices for 2026
Linux runs the internet. More than 96% of the world’s top one million web servers operate on Linux-based systems. That makes every linux server a target by default. Attackers do not go where defenses are strongest; they go where the infrastructure is exposed. . Attackers do not need to break everything. One weak login is enough. One open port, one forgotten service, one stale account that still works from three jobs ago. That is usually where server security starts to fail, not in some dramatic exploit chain. Remote access has always been the soft spot in Linux administration. SSH gets hit constantly. Bots hammer exposed ports, old credentials resurface, and misconfigured services sit there longer than anyone wants to admit. The work is basic, but it matters: cut the exposure, tighten authentication, read the logs, and shut down whatever should not be reachable. SSH Is Still the First Line of Defense If your server is on the internet, someone is already trying to log in. That is just the baseline now. Default SSH settings are built for convenience, and convenience is not what you want on a public-facing box. Start by moving SSH away from port 22 . It will not stop someone who is actually targeting you, and it is not a replacement for real hardening. But it does cut out a lot of low-effort scanning, which means cleaner logs, less firewall noise, and fewer false positives wasting your time when something real starts moving. SSH needs more than a port change. Limit who can log in. Disable root login. Review allowed users. The daemon should expose only what the admin workflow actually needs, because anything extra becomes something else to patch, monitor, or explain later. Ditch Password Authentication Entirely Passwords are a liability. Brute-force attacks, credential stuffing, phishing, reused creds, all of it gets easier when password-based SSH login stays enabled. Switch to SSH key pairs and treat passwords as something that should not be part of remote serveraccess anymore. Generate an Ed25519 key. It is faster and more secure than RSA at comparable key lengths. Copy the public key to the server, then open /etc/ssh/sshd_config and set: PasswordAuthentication no PubkeyAuthentication yes PermitRootLogin no Restart the SSH daemon after editing the file. Keep your existing session open and test the new connection in another terminal before you close anything. Locking yourself out of your own server is a rite of passage, but it does not need to happen today. Two-Factor Authentication Adds the Second Wall Key-based authentication is strong. Adding two-factor authentication makes remote login much harder to abuse if a private key gets stolen from a laptop, copied by malware, or pulled from a bad backup. The key should not be the whole story. Google Authenticator works cleanly with PAM on most major distros. Duo Security is better suited for teams that need centralized management and reporting. Either way, 2FA adds a pause point that attackers cannot easily automate around. This is not about making admin work annoying. It is about assuming one control may fail. That assumption is usually correct. Firewall Rules Should Be Simple and Strict A firewall should block everything by default and open only what is needed. Not what might be useful later. Not what was needed during setup and then forgotten. Needed now. On Ubuntu and Debian systems, ufw keeps the basics readable: ufw default deny incoming ufw default allow outgoing ufw allow from 203.0.113.5 to any port 2222 ufw enable Replace the IP and port with your own. If you manage servers from a fixed IP or a small trusted range, allowlisting those addresses is one of the cleaner firewall rules you can put in place. It cuts down noise before authentication even starts. Every exception should have a reason. A temporary open port has a habit of becoming permanent if nobody writes it down. VPNs and Encrypted Tunnels Keep Access Controlled VPNs sit in a usefulplace for Linux administrators. They are not magic, and they do not replace SSH hardening, but they keep management traffic inside a controlled path instead of leaving SSH exposed to the wider internet. For teams, that means fewer public login surfaces. For individual admins, it also means steadier access to documentation sites, package mirrors, security databases, and research tools that may be restricted or throttled by region. The practical value is simple enough: admin traffic moves through an encrypted tunnel before it reaches the server. For Linux administrators, understanding proper VPN setup on Linux is useful because it protects management traffic and keeps work resources reachable without opening more services than needed. A VPN should sit in front of good server-side controls, not replace them. Fail2Ban Handles the Repetitive Noise No sysadmin watches authentication logs manually all day. Fail2ban does that job quietly. It parses auth logs, spots repeated failures, and bans offending IPs through firewall rules without waiting for a human to intervene. Set the SSH jail with a reasonable maxretry value. Three to five failed attempts is enough for most systems. Use a ban time of at least an hour, and consider longer bans for repeat offenders on servers that get hit constantly. Fail2Ban will not stop every attacker. Distributed botnets can rotate IPs, and slow attempts can slip under thresholds. Still, it removes a lot of junk from the board, and that makes real triage easier. The Principle of Least Privilege Is Where Cleanup Starts The principle of least privilege sounds obvious until you audit a real server. Every user, service, daemon, and cron job should have only the permissions it needs. No more. Production systems rarely look that clean. Shared root access hangs around. Old sudoers entries survive because nobody wants to break a workflow. Service accounts get more permission than they need, then nobody revisits them for two years. That is how smallcompromises get room to spread. Start with the accounts. Then check sudo access. Then review services. A restricted account gives an attacker less room for lateral movement, fewer files to touch, and fewer commands that matter. Good places to look: /etc/sudoers and files under /etc/sudoers.d/ old user accounts that no longer need access services running as root without a clear reason shared admin credentials cron jobs and automation tokens This is not glamorous work. It is the kind of cleanup that prevents a bad login from turning into a full host compromise. Keep Systems Patched Relentlessly Patching still gets missed. Not because admins do not know better, but because maintenance windows slip, staging takes time, and production systems always have some reason to wait. Attackers like that. Old vulnerabilities are still useful because plenty of systems remain unpatched after fixes are available. The exploit does not need to be new if the target is behind. That is the uncomfortable part. Enable automatic security updates where it makes sense. On Debian and Ubuntu, unattended-upgrades handles this cleanly. On Red Hat-based systems, dnf-automatic does the same job. For critical systems, test patches in staging first, but do not let testing become a permanent excuse. Intrusion Detection Gives You Something to Work With Most attacks should be blocked by authentication controls, firewall policy, and patching. Intrusion detection is for cases that get through or start from inside. You need to know when something changed. AIDE can build a cryptographic baseline of the filesystem and alert when important files are modified. Auditd gives deeper syscall-level visibility, which helps when you need to know what ran, who ran it, and when. The output can be noisy. Tuning takes time. Still, during incident response, noisy data beats no data. Knowing which files changed and which commands executed is the difference between focused triage and weeks of forensicguessing. Logging Has to Be Active There is no such thing as useful logging if nobody reads the logs. Disk space full of ignored auth events is not security. It is storage. Track the things that show real access and real change: successful logins, failed login bursts, sudo use, new source IPs, service restarts, and edits to sensitive files. Logwatch can send daily summaries for smaller setups. Graylog or the Elastic Stack works better when multiple servers need centralized search, alerting, and dashboards. Even a rough script that emails you when someone authenticates from a new IP is better than nothing. Crude tools catch real compromises all the time because they are actually watched. SSH Certificates Help Teams Scale Access Managing individual SSH keys is fine when the team is small. Ten people, a few servers, clear ownership. Past that, key management starts to rot. SSH certificates, signed by an internal Certificate Authority, bring control back into one place. Certificates can expire automatically. Access can be scoped by user and host. Revocation does not require manually removing keys from every server. This is where remote access starts to scale without chaos. It also gives security teams a cleaner way to answer a basic question during an audit: who could log in, where, and for how long? Zero-Trust Architecture Fits Modern Infrastructure The old model was simple. Protect the perimeter, then trust what is inside. That model does not fit modern infrastructure anymore. Cloud instances, remote workers, contractors, multi-region deployments, and private admin panels all blur the perimeter. There may not be one clean “inside” to trust. Zero-trust architecture starts from the opposite assumption: every access request is untrusted until it proves otherwise. Tools like Tailscale can apply this model to SSH and internal services without a full infrastructure rebuild. Cloudflare Access can do similar work for web-based admin panels. The point is not thelabel. The point is to stop treating network location as proof of safety. Disable What You Do Not Need Every open port is an attack surface. Every running service that is not actively used is another thing to patch, monitor, and defend. Most servers accumulate small exposures over time. Run: ss -tulpn That shows listening sockets. Cross-reference the output against what the server actually needs to do. If a service should not be running, disable it: systemctl disable --now servicename Minimal cloud images are usually cleaner than old bare-metal systems, but drift still happens. A temporary service gets enabled during troubleshooting. A package opens something unexpected. A test daemon stays up because nobody circled back. Check anyway. Keep Up With a Field That Keeps Moving Security is not finished after one hardening pass. A checklist from 2022 may miss newer attack patterns, deprecated recommendations, or defaults that changed since the server was first built. That happens fast. Use official distribution security guides, vendor advisories, and reputable cybersecurity resources. You do not need to read everything. You do need a habit that keeps your assumptions from going stale. The best teams turn lessons into runbooks. They patch the process after the incident, not just the host. Backups and Recovery Still Matter Hardening remote access reduces risk. It does not remove the need for recovery. Ransomware, destructive intrusion, failed patching, admin error, and compromised automation can still take systems down. Backups should be offline, off-site, and tested. If you have never restored a backup, you do not really know if you have one. It is just a hope sitting in storage. Automate backups, verify them regularly, and keep at least one copy beyond the reach of the production server. If an attacker gets root on the box, they should not be able to delete every recovery path. Final Thoughts: Layers, Not Silver Bullets No single tool secures remote access to a Linux server . Not SSH keys alone. Not a firewall alone. Not 2FA alone. Security works better as a stack, where one layer catches what another misses. Start with the basics. Harden SSH , disable password authentication, configure firewall rules , and limit who can access the service. Add two-factor authentication, install fail2ban , patch consistently, and review access with the principle of least privilege in mind. Then go deeper. Add intrusion detection, centralize logs, use SSH certificates for teams, tighten exposed services, and move toward a zero-trust architecture where it makes sense. Review the setup every few months. Attackers are patient, systematic, and persistent, so the defensive work has to be the same. . Secure your Linux servers by tightening remote access protocols, implementing SSH keys, and utilizing 2FA for better protection.. remote access security, linux servers, ssh configuration, firewall management. . MaK Ulac
May 13, 2026
•
Server Security
72
network securitypacket filteringiptablesSecuring Your Network with Iptables Configuration for Desktops
Today I will show you the iptables rules I set on my main personal computer, with detailed comments about why I came to use these rules after several years of Linux desktop usage. The rules I use now have been simplified as much as I could and are based on common rules and advice that can be found on the network and also on input I got from experienced network administrators. I. So here they are: # iptables -v -L Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 663K 905M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 105 6300 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT icmp -- any any anywhere anywhere icmp destination-unreachable 0 0 ACCEPT icmp -- any any anywhere anywhere icmp time-exceeded 0 0 ACCEPT icmp -- any any anywhere anywhere icmp source-quench 0 0 ACCEPT icmp -- any any anywhere anywhere icmp parameter-problem 0 0 DROP tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination We The link for this article located at 503 Service Unavailable Blog is no longer available. . Enhance your desktop security with iptables by establishing effective rules that balance strong defense and user convenience for optimal performance. Linux Firewall Rules, Iptables for Desktop, Personal Security, Network Protection. . Anthony Pell
Apr 06, 2010
•
Firewalls
72
security practicesserver securityiptablesEffective Iptables For Securing Linux Servers Against Spam Attacks
'Spamming', when used in a different context, does not necessarily have to be email specific. If you ever had a chance to play arcade fighter's such as Street Fighter 2, you'll notice that certain fighters have "cheap" moves that can be "used over and over", such as M. Bison's scissor kick corner trap (ah the old days). A player could pretty much "spam" this combo over and over. The interesting part about this cheap combo is that it could be countered just as easily with some skill. A basic set of good iptables rules is the perfect counter punch to a slew of common spamming attacks - no need to have SpamAssassin or procmail process the email when it doesn't even get through the front lines! Read on to gain a good base understanding of iptables and its rules. Ha-dou-ken! . The link for this article located at SearchEnterpriseLinux.com is no longer available. . Understand the principles of iptables to strengthen the defenses of your Linux server and safeguard it against prevalent spamming threats.. iptables Security, Firewall Setup, Network Security Best Practices. . Brittany Day
Jul 20, 2007
•
Firewalls
74
network monitoringbandwidth managementiptables usageEmploying Iptables for Effective Bandwidth Management on Linux Systems
Linux has a number of useful bandwidth monitoring and management programs. A quick search on Freshmeat.net for bandwidth returns a number of applications. However, if all you need is a basic overview of your total bandwidth usage, iptables is all you really need -- and it's already installed if you're using a Linux distribution based on the 2.4.x or 2.6.x kernels. Most of the time we use iptables to set up a firewall on a machine, but iptables also provides packet and byte counters. Every time an iptables rule is matched by incoming or outgoing data streams, the software tracks the number of packets and the amount of data that passes through the rules. . It is easy to make use of this feature and create a number of "pass-through rules" in the firewall. These rules do not block or reroute any data, but rather keep track of the amount of data passing through the machine. By using this feature, we can build a simple, effective bandwidth monitoring system that does not require additional software. The link for this article located at Linux.com is no longer available. . Effortlessly track network usage with UFW by setting up straightforward filtering policies, eliminating the need for additional tools.. Iptables Usage, Bandwidth Management, Linux Administration, Network Monitoring. . Benjamin D. Thomas
Dec 27, 2005
•
Network Security
72
network securitysecurity strategiesfirewall managementAnalyze Packet Handling In Firewalls: Reject Versus Deny Decision Impact
... there are a number of issues considered all too rarely by firewall administrators. Most IP level firewalls have a number of options for handling a packet. The packet can typically be accepted, dropped, or sent through another set of rules for inspection (allowing you to break up your ruleset into more manageable pieces). . .. ... there are a number of issues considered all too rarely by firewall administrators. Most IP level firewalls have a number of options for handling a packet. The packet can typically be accepted, dropped, or sent through another set of rules for inspection (allowing you to break up your ruleset into more manageable pieces) When blocking a packet, you are faced with an important choice; whether to drop it silently, or generate an ICMP error message. Each choice has several advantages, and also creates a variety of potential problems. If you generate an error message (i.e. ICMP unreachable), then the remote end will usually immediately stop trying to connect. This makes detecting some types of port scans more difficult since the remote end will likely send off only one packet, and give up after it receives the first error message. This also makes "shotgun" port scanning (i.e. where the attacker simply tries several thousand ports in rapid order) much easier, since the software will receive a definitive answer as to whether the port is blocked or not. Sending an error message does have several advantages, though, the primary one being to make life more difficult for someone who wants to spoof your IP addresses. Since your firewall is likely to generate ICMP error messages, the victim being attacked (by what looks like packets from your systems) will know something is up. To prevent you from sending error messages the attacker must take you offline, or otherwise act overtly to prevent data getting from the victim's network to yours and back. The link for this article located at SecurityPortal is no longer available. . ... there are a number of issuesconsidered all too rarely by firewall administrators. Most IP level. there, number, considered, rarely, firewall, administrators, level. . Anthony Pell
May 23, 2001
•
Firewalls
72
security toolnetwork managementfirewall rulesConstructing Packet Filtering Firewalls With Mason Tool
Using the Mason firewall tool, you can easily construct a packet filtering firewall. Mason constructs a firewall for you by listening on your network for normal data and building the rules accordingly. . . .. Using the Mason firewall tool, you can easily construct a packet filtering firewall. Mason constructs a firewall for you by listening on your network for normal data and building the rules accordingly. The link for this article located at William Sterns on LinuxMo is no longer available. . Implement Mason's firewall to develop a robust packet filtering mechanism that dynamically aligns with the regular traffic patterns of your network.. Mason Firewall, Packet Filtering, Network Management. . Anthony Pell
Mar 08, 2000
•
Firewalls
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!
Explore top 10 tips to secure your open-source projects now. Read More