Explore top 10 tips to secure your open-source projects now. Read More
×
Server Security
data privacy automation
data privacy automation Every system admin has lived through the same Monday morning ritual. A queue of forty tickets, half of them password resets, permission errors, or disk space warnings that any experienced technician could resolve in under two minutes. The other half require actual judgment. For years, automation promised that software would eventually sort the two apart on its own. That promise is now being tested in production Linux environments. . Early results are reshaping how IT teams think about tier-1...
Jul 17, 2026
Privacydata collection automation
data collection automation You're running a web scraping project to collect pricing data from e-commerce sites. You set up a pool of datacenter proxies, launch your scripts, and within minutes — banned . CAPTCHAs everywhere. Your data pipeline stops before it really begins. . It's a frustrating scenario that plays out daily in ad verification, market research, and multi-account management. The website doesn't know you're doing legitimate research or monitoring. It just sees traffic coming from IP ranges it recognizes as...
Jul 17, 2026
Security Trends security advisory social engineering
security advisory social engineering Business Email Compromise used to be a numbers game — mass-blasted emails, broken English, an obvious "URGENT WIRE TRANSFER" subject line. That era is over. Generative AI has turned BEC into a tailored, low-noise operation that mimics writing style, voice, and even video presence. This piece looks at what's actually changed under the hood, what defenders are testing in response, and why so many organizations are still structurally unprepared for it. . The Infrastructure Problem Nobody Wants to...
Jul 17, 2026
Security Trends cybersecurity Linux documentation
cybersecurity Linux documentation Linux operating systems have gained prominence due to their stability, adaptability, and excellent security options. In the case of developing documentation, designing cybersecurity dashboards, or educational material, visuals are of vital importance when it comes to making things clear. The use of icons allows one to understand the message regarding alerts, authorization, encryption, authentication, or the state of the system just by looking at the visual cue without having to read long...
Jul 17, 2026
Security Vulnerabilities security advisory linux distribution
security advisory linux distribution ESET researchers identified 11 old and forgotten Linux UEFI shim bootloaders at versions 0.9 and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party certificate authority, regardless of the installed operating system (OS). Reported shims can be exploited to execute untrusted code during system boot, enabling attackers to deploy malicious UEFI bootkits even on systems with UEFI Secure Boot enabled.....
Jul 16, 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
Is continuous patching actually viable?
Loading...
Explore Latest Linux Security news
We found 65 articles for you...
74
security advisorynetworkinglinuxIPv4 vs. IPv6 Proxies in 2026: Which One Should You Run on Your Linux Stack?
For years, IPv4 was the only proxy type that really mattered for anyone running automation off a Linux box. IPv6 was the protocol everyone said they’d migrate to, but almost nobody actually did. In 2026, that’s finally starting to shift. . The problem is that most admins stick with IPv4 out of habit. They know it; it’s what their tooling defaults to, and they don’t see a reason to change. Some are overpaying for addresses they don’t need. Others would quietly break their scrapers, scripts, or account setups the moment they switched. On a server juggling dozens of outbound connections, picking the wrong protocol isn’t just a billing question; it changes how reliable your jobs are and how your traffic looks to the other end. This guide breaks down which one actually fits your setup. The Current State of IPv4 and IPv6 Adoption For most of the internet, IPv4 is still the default. It’s the foundation almost every website, API, and tool was built on. We officially ran out of new IPv4 addresses years ago, but that scarcity never pushed everyone onto IPv6 the way people expected. IPv6 was supposed to be the fix — a practically limitless address space that solves the supply problem for good. Google, Facebook, and Cloudflare all fully support it today, and pretty much every modern Linux distribution ships with dual-stack out of the box. But plenty of smaller sites, older tooling, and corporate networks still haven’t caught up. The result is a split internet. Right now, around 40-45% of traffic runs over IPv6, driven mainly by major mobile carriers and large tech platforms. The rest is still IPv4-only — so if you point an IPv6 proxy at a target that doesn’t support it, the connection simply won’t complete. Compatibility With Common Tools and Target Sites Most failed IPv6 rollouts come down to compatibility. The major sites — Google, YouTube, Facebook, and anything behind Cloudflare — are already IPv6-enabled. But a long tail of smaller sites, niche marketplaces,aging e-commerce platforms, and corporate domains is still IPv4-only. For those, an IPv4 proxy is the only thing that will actually connect. On the tooling side, support is uneven. Modern HTTP clients and scrapers handle IPv6 fine — a recent curl, Python’s requests, and most current browsers will use it without complaint. Older scrapers, hand-rolled scripts, and some SEO software won’t, and a few will hang or fall back unpredictably on a dual-stack lookup if you haven’t tuned how the resolver picks an address family. Anti-detect browsers and multi-accounting tools usually stay on IPv4 because account trust scores are still built on IPv4 history. APIs and third-party services are all over the map on IPv6 support, so the safe default when your work depends on an API is IPv4. The rule is simple: if every target and every tool in your stack fully supports IPv6, switching can save real money. If even one link in the chain doesn’t, stay on IPv4. Pricing Differences and Why They Exist IPv4 addresses are scarce. There are roughly 4.3 billion of them, and nearly all are already in use. New blocks change hands on a secondary market, and prices keep climbing because demand is high and supply is fixed. Proxy providers pay real money for those addresses, and that cost lands on your bill. IPv6 is the opposite. The address space is so large that supply is effectively unlimited, so providers can obtain ranges at almost no cost. That’s why IPv6 plans can run far cheaper — some providers price IPv6 proxies at as little as 10 to 20% of the equivalent IPv4 plan. Where IPv6 Makes Sense If the target already supports IPv6, the math is hard to ignore. Google, YouTube, and other major tech platforms These networks have supported IPv6 for years. If most of your traffic goes to Google properties, paying IPv4 prices often doesn't buy you anything. Large-scale scraping jobs When a target is fully IPv6-enabled, address availability stops being the limiting factor. The bigger thecrawl, the bigger the savings. Social media monitoring and automation X, Instagram, TikTok, and similar platforms generally handle IPv6 traffic without issue. Some operators still prefer a private residential proxy setup for reputation reasons, but that's a separate decision from the protocol itself. Ad verification Google Ads, Meta Ads, and other large advertising networks are already operating in IPv6 environments. Verification traffic can usually move over without changing the workflow. Mobile-focused projects Many carriers adopted IPv6 long before fixed-line providers. If you're collecting mobile data or testing mobile applications, you'll often find yourself working in IPv6-heavy environments anyway. Internal testing and staging Easy savings. If you're controlling both ends of the connection, compatibility concerns largely disappear. Where IPv4 Still Has the Edge IPv6 availability isn't the issue anymore. Compatibility is. Older websites and smaller platforms Plenty of e-commerce stores, local businesses, forums, and government systems still run IPv4-only infrastructure. API-heavy workflows One endpoint supports IPv6. The next one doesn't. Documentation is often inconsistent, which makes IPv4 the safer option when reliability matters. SEO tooling and rank tracking Much of the SEO ecosystem was built around IPv4 assumptions. IPv6 support exists in some places, but not always consistently. Multi-account operations Reputation systems, trust scoring, and verification workflows still lean heavily on IPv4 history. The connection works. The account may not. Anti-detect browser environments Most anti-detect setups were designed around IPv4. Changing protocols can create inconsistencies that operators would rather avoid. Sneaker, ticketing, and limited-drop sites These are often the last places you'd want protocol-related surprises. Most operators stick with IPv4 and remove the variable entirely. Security and PrivacyConsiderations on Linux For anyone running this on a Linux host, the protocol choice has a couple of security angles worth keeping in mind — not just cost and compatibility. The first is leakage. On a dual-stack box, a misconfigured client can quietly fall back to your machine’s native IPv6 address and bypass the proxy entirely, exposing the real egress IP you were trying to hide. Before trusting any IPv6 deployment, verify what traffic is actually leaving the box. Start with ip -6 addr and confirm the interface has the addresses you expect. Then check an external service to see which address is being presented upstream. Misconfigurations are common, especially in environments where IPv4 and IPv6 are running side by side. If IPv4-only egress is the goal, disabling IPv6 at the operating-system level is usually more reliable than hoping individual applications behave correctly. On Linux, that typically means setting the net.ipv6.conf.all.Disable IPv6 sysctl and confirm the change took effect before testing again. The second is reputation. IPv6 ranges are usually handed out in large contiguous blocks, so a target that sees abuse from one address can flag an entire /64 in one move, which makes a cheap IPv6 pool easier to burn through if you’re not careful. IPv4 reputation is tracked per address and tends to be more established, which is part of why account-trust systems still favor it. Match the protocol to the sensitivity of the work, not just to the lowest price. Conclusion At the end of the day, most workflows still run on IPv4, simply because it’s the version of the internet around which most targets and tools were built. IPv6 is the cheaper option with far more room to scale — but only when the specific targets in your stack can actually handle it. The deciding factor is knowing your targets and your tooling before you commit. If you’re working against the big tech platforms with full IPv6 support, the savings are worth chasing. If you’re dealing with older, smaller, or mixedsystems — or you need tight control over what leaves your host — IPv4 is still the safer call. . Explore the differences between IPv4 and IPv6 proxies for Linux, understanding compatibility, costs, and security implications in 2026.. IPv4 Proxies, IPv6 Proxies, Linux Networking, Security Best Practices. . Anthony Pell
Jun 09, 2026
•
Network Security
74
firewallnetworkingsecurity controlsLinux Firewall Rules Management Challenges Kubernetes Security
A Linux server running a few predictable services is relatively easy to secure. . You know which ports should be exposed and which processes are expected to communicate externally, and once the firewall rules are tuned properly, the environment usually remains stable for long periods. Troubleshooting is also fairly direct. If traffic fails, you inspect logs, trace connections, and work backward through the ruleset. Kubernetes changes almost all of that. The issue is not that Linux firewalling tools stopped working. nftables and iptables still process packets efficiently and remain deeply integrated into the networking stack. The problem is that modern orchestration layers introduced networking behavior that no longer maps cleanly to traditional host-level assumptions. Many Linux administrators discover this gradually. The first cluster may feel manageable, especially in a smaller environment. Then workloads begin to scale dynamically, service meshes are introduced, developers deploy additional namespaces, and suddenly the original firewall model becomes difficult to reason about operationally. The biggest challenge usually is not filtering traffic itself. It is understanding where enforcement is actually happening. Kubernetes Abstracts Networking Away From the Host One reason Kubernetes environments become harder to secure is that packet flow is no longer entirely controlled by the Linux machine. The host still matters, obviously. Traffic still traverses kernel networking layers, and tools like nftables remain relevant for local filtering and node-level hardening. But orchestration systems now make decisions above the operating system itself. A simple workload deployment can involve Kubernetes NetworkPolicies, cloud security groups, overlay networking, ingress controllers, service mesh policies, container runtime networking, and host firewall rules all at the same time. Those layers often interact in ways that are not immediately obvious during troubleshooting. For example,a Linux admin may inspect nftables rules and see no local traffic blocking, even though the actual restriction is enforced by a dynamically applied Kubernetes NetworkPolicy. The behavior itself is straightforward once understood, but troubleshooting becomes harder because enforcement is distributed across several layers rather than managed entirely from the Linux host. The official Kubernetes NetworkPolicies documentation gives a good overview of how these policies affect pod communication and namespace isolation in real-world environments. That changes the operational workflow considerably. Traditional Linux firewall troubleshooting was mostly linear. In containerized infrastructure, visibility becomes fragmented across multiple systems designed independently of one another. East-West Traffic Creates Most of the Operational Pain Perimeter filtering is usually no longer the hardest part. In many cloud environments, inbound traffic is already heavily restricted through load balancers, reverse prox ies, API gateways, or cloud-native filtering services. The more difficult problem is understanding internal communication between workloads. A compromised pod moving laterally inside the cluster often generates traffic that looks completely legitimate at the packet level. From the Linux host’s perspective, it may simply appear as normal encrypted communication between internal services. That is where traditional firewall logic begins to reach its limits. iptables and nftables understand ports, addresses, interfaces, and connection states very well. They do not understand workload identity, namespace trust boundaries, or application context without additional orchestration awareness layered on top. This becomes especially noticeable once teams start deploying microservices aggressively. Internal traffic volume is growing rapidly, and maintaining granular segmentation manually at the host layer is becoming operationally difficult to sustain. Most teams eventually respond by looseningcontrols simply because maintaining perfect granularity slows deployments down too much. nftables Is Cleaner Than iptables, but the Core Problem Remains Most administrators who have worked extensively with both systems would probably agree that nftables is easier to manage than older iptables configurations. The syntax is more consistent, IPv4 and IPv6 handling is unified, and maintaining larger rule sets is significantly less painful than dealing with sprawling legacy chains. Something like: nft add rule inet filter input tcp dport 22 ct state new accept It is much easier to reason about than older multi-table iptables structures. Performance improvements are also noticeable on busy systems. But migrating from iptables to nftables does not fundamentally solve the visibility problem introduced by Kubernetes and cloud-native infrastructure. The firewall still operates primarily at the node level. It still lacks awareness of workload orchestration, service relationships, and dynamic container behavior happening elsewhere in the stack. That distinction matters because many Linux teams initially expect nftables migration projects to improve security posture more than they actually do. In practice, the migration mainly improves maintainability. Why Linux Teams Started Layering Security Controls What most mature infrastructure teams eventually realize is that no single layer provides enough visibility anymore. Host-level filtering still matters. Kubernetes NetworkPolicies matter. Cloud-native ACLs matter. Identity-aware access controls matter. The environments that scale cleanly usually combine all of them rather than relying too heavily on a single approach. A fairly common operational pattern now looks something like this: The Linux host handles node-level hardening, SSH restrictions, local filtering, and outbound control. Kubernetes policies manage workload segmentation and namespace isolation. Cloud security groups enforce infrastructure-levelboundaries between services and environments. Centralized monitoring systems aggregate telemetry from all layers, enabling administrators to understand what is happening across the environment. That layered approach is more complicated initially, but it tends to age better operationally than directly managing every trust boundary from the Linux host. Logging Becomes More Important Than Rule Writing One thing that surprises many teams during Kubernetes adoption is how much time shifts away from writing firewall rules and toward understanding traffic visibility. Static environments are fairly predictable. Dynamic orchestration platforms are not. A service that behaved normally yesterday may suddenly exhibit entirely different traffic patterns due to autoscaling, deployment changes, or internal service discovery updates. That is why logging quality becomes critical. Linux administrators increasingly rely on: journal aggregation eBPF observability tools Kubernetes audit logs flow telemetry centralized traffic analytics Without visibility, troubleshooting becomes mostly guesswork. The challenge is no longer simply identifying blocked packets. It is understanding whether communication itself should exist in the first place. Where Cloud Firewalls Fit Into This One thing that changed significantly over the last few years is how organizations think about segmentation and visibility in hybrid infrastructure. In smaller environments, local firewalling may still be manageable directly from the host layer. In larger deployments spanning cloud providers, Kubernetes clusters, and mixed workloads, teams often need broader policy visibility than nftables alone can provide. That is part of why Cloud firewalls became more common operationally. Not necessarily as replacements for Linux-native controls, but as centralized enforcement and visibility layers sitting above fragmented infrastructure. For administrators dealing with distributed workloads, theoperational challenge is usually consistency rather than raw packet filtering performance. Maintaining comparable policies across cloud environments, container platforms, and traditional Linux systems manually becomes difficult over time. Final Thoughts Linux firewalling tools are still extremely effective at what they were designed to do. The issue is that modern infrastructure introduced orchestration layers and traffic patterns that extend far beyond the visibility of a single host. That does not make nftables or iptables obsolete. It simply changes where they fit inside the architecture. Most Linux teams are no longer trying to solve cloud segmentation entirely from the host layer. They are combining Linux-native controls with orchestration-aware policy systems, centralized visibility, and workload-level segmentation in order to keep dynamic environments manageable as they scale. . Explore why managing Linux firewall rules in Kubernetes is challenging and how to enhance visibility in dynamic environments.. Kubernetes Security, Linux Firewall, Cloud Security, Networking Policies, Network Visibility. . MaK Ulac
May 08, 2026
•
Network Security
67
networkingredhatipsecFreeS/WAN Weekly Report: IPsec Implementation on Zaurus and RedHat Issues
This issue, we have reports of FreeS/WAN running on the Sharp Zaurus (item 1) and having a few small issues with RedHat 8.0 (item 2). Claudia Schmeing has posted a new revision of our interoperation document (item 3). Item 4 has a great discussion on the use of routing protocols with FreeS/WAN.. . . . This issue, we have reports of FreeS/WAN running on the Sharp Zaurus (item 1) and having a few small issues with Red Hat 8.0 (item 2). Claudia Schmeing has posted a new revision of our interoperation document (item 3). Item 4 has a great discussion on the use of routing protocols with FreeS/WAN. . Investigate the implementations of FreeS/WAN on the Sharp Zaurus, while delving into routing strategies and addressing RedHat complications.. IPsec Security, FreeS/WAN Integration, Zaurus Connectivity. . LinuxSecurity.com Team
Oct 16, 2023
•
Cryptography
72
kernel updatefirewallnetworkingIPFire 2.27 Core Update 173: 4G Support and Enhancements
Get ready to experience the best of IPFire 2.27 – Core Update 173! Not only is this update introducing support for 4G and 5G modems that utilize the QMI interface, but also includes a kernel freshly picked from 6.1’s stable series as well as an array of package updates, security enhancements, and bug fixes so you can be sure your device is always up-to-date with the latest improvements! . The final update for 32-bit ARM devices running IPFire is being released at the end of this month. It’s time to migrate your installations over to a supported hardware architecture if you haven’t already done so; otherwise, you risk missing out on important updates and features! We are excited to announce the arrival of QMI support in IPFire! Qualcomm MSM Interface is a proprietary interface used for 4G and 5G cellular modems , and now with this Core Update, IPFire will be able to connect with these types of modems. It’s never been easier or faster – you won’t have any compatibility issues. Special thanks go out to Michael, who worked hard on refactoring various aspects of networking code as well as adding this feature. The link for this article located at UbuntuPit is no longer available. . Discover the groundbreaking updates in IPFire 2.27 – Core Update 174, featuring increased 4G modem compatibility and fortified security measures.. IPFire Update 173, Open Source Firewall, 4G Modem Support, Security Enhancements. . Brittany Day
Mar 01, 2023
•
Firewalls
76
securitynetworkingcommunity collaborationLinux Foundation's Open Metaverse Initiative for Collaboration
The Linux Foundation has announced plans to build an open-source metaverse which it says could be “as impactful as the World Wide Web”, so long as companies, developers, and founders come together to meet shared goals. . The aptly named Open Metaverse Foundation (opens in new tab) (OMF) has been divided into a series of groups, that it calls Foundational Interest Groups, designed to focus on different topics. They include transactions, virtual worlds and simulations, networking, security and privacy, and legal and policy, among others. A large number of organizations and open-source communities have come together to form the foundation, including ChainHub Foundation, OpenSDV, and Veriken, each bringing its own wealth of knowledge. . The Open Web Consortium is focused on bringing together entities to collaborate on common objectives in technological advancement.. Linux Foundation Open Source Metaverse, Community Collaboration, Digital Innovations, Open Metaverse Security. . Brittany Day
Jan 23, 2023
•
Organizations/Events
67
securityVPNcybersecurityExploring WireGuard Pros and Cons in Secure VPN Networking
The primary goal of any VPN is to create a secure encrypted tunnel for all your internet traffic by helping to shield it from hackers and others that want to take a peak, which may even include your ISP. . VPN providers can choose from many protocols - OpenVPN , IKEv2, L2TP, SSTP, more -to create and manage the encrypted tunnel. Each one comes with their advantages and disadvantages. OpenVPN is currently the most popular option, but its original design actually dates all the way back to 2001. As with all facets of technology, much has changed in relation to the internet and how its use has evolved during the last 20 years or so. WireGuard is a more recent entry into the world of VPN protocols and it's already gained acceptance across the cybersecurity sphere. During this article, we're going to be taking a closer look at WireGuard to find out why. We’ll explore its major pluses, as well as highlight one or two potential downsides. . VPNs use protocols like WireGuard for secure tunnels, but what are its pros and cons? Explore secure networking insights here.. WireGuard, secure VPN, networking protocols, OpenVPN security, cybersecurity practices. . LinuxSecurity.com Team
Jan 19, 2023
•
Cryptography
72
firewallnetworkingreleaseOpenWrt 22.03 Release: Firewall4 Enhances Support for 1580 Devices
OpenWrt 22.03 open-source Linux operating system for routers and entry-level embedded devices has just been released with over 3800 commits since the release of OpenWrt 21.02 nearly exactly one year ago. . The new version features Firewall4 based on nftables, switching from the earlier iptables-based Firewall3, and adds support for over 180 new devices for a total of more than 1,580 embedded devices, including 15 devices capable of WiFi 6 connectivity using the MediaTek MT7915 wifi chip. OpenWrt developers explain that Firewall4 keeps the same the UCI firewall configuration syntax and should work as a drop-in replacement with most common setups, just generating nftables rules instead of iptables ones. You’ll find more details about OpenWrt firewall configuration in the documentation . . OpenWrt 22.03 releases Firewall4, extending compatibility to 1,580 devices and bolstering security measures for embedded solutions.. OpenWrt, Firewall4, Embedded Systems, Network Security. . Brittany Day
Sep 19, 2022
•
Firewalls
210
security advisorypatchnetworkingCritical Stack Overflow in Linux Kernel Module Resolved
An exploitable bug sitting in a popular Linux kernel module has been found after five years. A patch is finally available, experts say. . An exploitable bug sitting in a popular Linux kernel module, has been found after five years, researchers have claimed. Detailing the findings in a blog post , researcher Samuel Page from cybersecurity firm Appgate said the flaw was a stack buffer overflow, found in the kernel networking module for the Transparent Inter-Process Communication (TIPC) protocol. Page describes TIPC as an IPC mechanism designed for intra-cluster communication. “Cluster topology is managed around the concept of nodes and the links between these nodes,” he says. . A critical vulnerability within a widely-used Linux kernel component has been discovered after a prolonged five-year period, with accompanying instructions for remediation made available.. Linux Kernel Patch, Stack Overflow Exploit, Kernel Security Fix, TIPC Module Bug. . Brittany Day
Feb 18, 2022
•
Security Vulnerabilities
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Is continuous patching actually viable?
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!