Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
Refine features
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 features
We found -3 articles for you...
102
security issuefirewallcyber attackDDoS Threats: Understanding the Limitations of Your Linux Firewall
Nowadays, Linux systems are considered fairly secure, as people think that Linux rarely gets infected with malware such as viruses, rootkits, worms, etc. You might also see that we hardly ever come across Antivirus software being sold for Linux, giving the illusion that Linux is an ultimately secure Operating System.. Given that roughly 75 percent of the world's servers run on Linux, we can’t truly believe that Linux is as secure as we think it is. Linux is only as secure as the person controlling and configuring it. Essentially, if a user has bad security practices, e.g. opening unauthorized emails or downloading potentially malicious links, then there is a very high chance that their Linux system will be compromised. A Linux firewall is defined as a solution or service that regulates, protects, and blocks network traffic as it passes to and from a Linux-based environment. Ultimately, it keeps your Linux systems secure by filtering certain network traffic that can be sent and received by the system itself. By default, Linux uses nftables, the successor of iptables, as a firewall and it does a fairly good job of keeping Linux Systems secure and mitigating potential attacks, especially if you have a good Security Engineer within your organization who is quite proficient with the tool. However, it does raise a very valid question: What attacks can’t this Linux firewall protect against? Whether you are using a paid firewall service or whether you are using the built-in iptables tool, there are just some attacks that the Linux firewall cannot protect against! Follow along with us as we go through what these attacks are and how they can affect your system. Nearly Impossible Attacks to Stop DDoS Attacks Like most cyberattacks, the deadliest ones come from within. Now with a normal DoS attack or DDoS attack, it can be managed and certain measures can be set in place to mitigate these attacks. The DDoS attack we will be talking about is a little more aggressive in terms of the methods it uses tosuccessfully execute the attack. We will be speaking on Reflection Attacks, specifically, reflected DoS and DDoS amplification attacks. I know you may be wondering what exactly is a Reflected Amplification attack but do not fear! Keep following along as we discover more about what they are. Reflected Amplification Attacks Reflection Amplification, simply put, is a combination of two techniques that allows cybercriminals to magnify the amount of malicious traffic they can generate and obscure the sources of the attack traffic. Let's split these two words to kind of get a better understanding. Reflection Attacks Simply put, reflection attacks are attacks that use the same protocol in both directions. The attacker spoofs the victim’s IP address and sends a request for information via UDP to servers known to respond to that type of request. The server answers the request and sends the response to the victim’s IP address. From the servers’ perspective, it was the victim who sent the original request. All the data from those servers pile up, congesting the target’s Internet connectivity. With the maximized bandwidth, normal traffic cannot be serviced and clients cannot connect. Any server open to the Internet and running UDP-based services can be used as a reflector. Amplification Attacks Amplification attacks increase the amount of data passing around. Essentially, an attacker uses a modest number of machines with little bandwidth to send fairly substantial attacks. Reflection /Amplification Attacks Together These two attacks alone can be fairly managed but when put together, not even the bests of firewalls can stop this, especially with a seasoned attacker behind the controls. They send a tremendous amount of spoofed packets causing systems to freeze, crash, or even reboot. The way an attacker carries on with this type of attack is actually through misconfiguration of the firewall in place. Almost all change and error is caused by human fault and in this instance, misconfigurationsof firewalls are the main culprit and reason for these types of attacks. Even then, if properly configured, you might still find yourself in the midst of a DDoS attack. Other Types of DoS/DDoS Attacks Buffer Overflow: Buffer Overflow attacks, as listed above, are a common type of DoS attack. It relies on sending an amount of traffi c to a network resource that exceeds the default processing capacity of the system. Ping of Death: Attackers send spoofed packets that ping every computer on the targeted network. The target responds and becomes flooded with responses from the malicious packet. It is also known as Internet Control Message Protocol (ICMP) Flood and Smurf Attack. SYN Flood: A SYN Flood attack exploits the TCP handshake – a method used for the TCP network to create a connection with a local host/client/server. Unfortunately, the handshake is left incomplete, leaving the connected host in an occupied status and unavailable to take further requests. Attackers will increase the number of requests, saturating all open ports and preventing anyone from connecting to the network. Teardrop: In a teardrop attack, IP data packet fragments are sent to the target network. The network then reassembles the fragments into the original packet. The process of reassembling these fragments exhausts the system and it ends up crashing. It crashes because the fragments are designed to confuse the system so it can never be put back together. If any of these other DoS/DDoS methods are used within a Reflection/Amplification attack, there is a good chance your Linux systems cannot withstand an attack of his magnitude. Misconfigurations in Web Applications Everyone that uses a web application has one thing in common, they are (mostly) all protected by a firewall. However, having a firewall doesn’t necessarily mean your system is secure. A firewall may be secure to the naked eye, but if it’s protecting a web application that has existing vulnerabilities, a Cyber Criminal can easilybypass it. There are countless examples of software vulnerabilities that hackers can exploit to bypass the firewall. Firewalls themselves also have vulnerabilities, normally caused by misconfiguration. Misconfigurations at the application layer, such as an error in configuring a WAF, can lead to a series of different attacks, such as SQL injections, CSRF, or even XSS. Furthermore, once the application vulnerability is exploited, it can lead to the Cyber Criminal gaining elevated access to the database, host server, and possibly more systems within a company. This is why it’s important to ensure to install the latest updates and patches and also, continually monitor events and logs. On top of staying up to date with updates and patches, as well as monitoring logs, you can invest in a good WAF. Malicious Scripts If an attacker manages to find their way onto your system, you would think your firewall or Intrusion Detection System would pick it up! Unfortunately, attackers have even managed to make their way around that. Nowadays, there are scripts that are meant to bypass firewalls and intrusion detection systems. Most Linux systems and servers deploy firewalls as a defense mechanism. In some malicious scripts, attackers try to disable the firewall (ufw) as a defense evasive tactic. Along with that, attackers also remove iptables rules (using iptables -F) because it is widely used for managing the firewall rules on Linux systems and servers. Another possible shell script would be one that disables certain Linux security modules such as SElinux, Apparmor, and other applications alike. These modules can be configured to grant users certain privileges and a seasoned attacker can create a script to manipulate these modules and grant themselves access as well. What Can YOU Do? I know we just went over nearly impossible attacks to defend against, so you must be thinking what can you possibly do?! Well, there are actually quite a few things we can do to mitigate these attacks. Follow along with the listbelow: Use up-to-date code dependencies, and third-party components, and update your web server/server Make sure you have recent security updates and patches installed for all software and hardware Properly configure any security tools and configuration files, such as PHP.ini and iptables, in your Linux environment Make sure that you have installed and properly configured an Intrusion Detection System Make sure to properly monitor any traffic that might seem suspicious Use vulnerability scanners to fully assess your web applications and your servers Limit any traffic to and from your server to malicious and black-listed IP addresses Properly educate yourself/your team on security protocols and stay up to date with recent malware/ransomware so you don't find yourself in a Zero-day attack If you follow along with this checklist and continually educate yourself on the possible vulnerabilities that are out there and that could potentially be in your system, you can properly mitigate most of these attacks. Our Thoughts As Cyber Criminals are using more sophisticated methods for attacks, it becomes increasingly important to monitor and record the activities happening on your system. It is important to have properly configured systems, firewalls, and all security features & patches updated to be able to properly defend against these types of attacks. It is a scary world out there and as everything becomes more digitized, we need to do our best efforts in keeping the systems that hold all our sensitive information safe. Make sure to check out our vulnerability basics (insert link here) article to further understand what vulnerabilities you might be encountering and make sure to check our WAF article to see how to keep your Web Applications secure! . As Linux systems gain traction globally, it's crucial to understand which threats can evade your firewall defenses and how to safeguard against these vulnerabilities.. Linux Firewall Attacks,DDoS Prevention,Security Best Practices.. Brian Gomez
Jul 27, 2022
•
102
traffic managementnetwork defensehoneypotExplore Innovative Honeypot Strategies For Engaging Attackers
Most of the papers deal with the potential gains a honeypot can give you, and the proper way to monitor a honeypot. Not very many of them deal with the honeypots themselves.. Honeypots are a hot topic in the security research community right now. It seems everyone is starting up their own honeypot system. Most of the papers deal with the potential gains a honeypot can give you, and the proper way to monitor a honeypot. Not very many of them deal with the honeypots themselves. Most honeypots as deployed as just an extra box someone has lying around. They slapped an OS on it, checksummed all the files, installed an IDS, and set about waiting for the hackers to arrive. Those kinds of honeypots ignore some of the most interesting parts of what a honeypot can do. Honeypots can be used to ensnare and beguile potential hackers; entice them to give you more research information, and actively defend your production network. We decided to write down some of what we think is cool and fun to do with honeypots. These techniques can be used to create an environment that keeps hackers interested in your honeypot, encourages them to upload new toys, and extract the maximum amount of data from them. Simulated Traffic One of the reasons most people do not see hackers doing interesting things on their honeypots is because there is nothing interesting for the attacker to play with. If you are going to find out what the attacker is all about, you need to make your honeypot interesting. One of the easiest ways to do that is to create simulated traffic to and from the honeypot. Replaying interesting traffic on the network can prompt the attacker to investigate other portions of your honeypot. Simulated traffic replayed over the wire can include e-mails, passwords, hostnames, or other common traffic. You want juicy traffic to entice the attacker to further investigate your machine and or network (honeynet). Simulated traffic can be used in conjunction with simulated targets. A simulatedtarget is where you can replay traffic from those simulated hosts to lure the attacker to further investigate those targets. Such traffic could be pop3, samba, FTP, or HTTP traffic coming from the simulated targets. Traffic from services known to have a bad security history will definitely prompt the attacker to investigate further. If you want to really see what the attacker is all about, simulate traffic that looks like someone trading MP3s, or traffic that looks like someone transferring business documents. If the attacker spends most of his time looking at the MP3 traffic, he is probably pretty harmless. If he spends his time looking at the documents, he is probably pretty dangerous. Simulated traffic can be used as a kind of referral service among honeypots. Drop some packets on the wire that contain usernames and passwords or contain hints that the really good stuff is stored at a different location. Different breeds of attackers will chase down different leads and attack your other honeypots. Simulated Targets Once an attacker has taken all the trouble to set up shop on your honeypot, he'll probably want to see what else there is to play with. If your honeypot is like most traditional honeypots, there's not much for an attacker to do once he gets in. What you really want if for the attacker to transfer down all the other toys in his arsenal so you can have a copy as well. Giving an attacker additional targets with various operating systems and services can help him decide to give you his toys. The targets can be real, but you'll get almost as much mileage if they're simulated. A good place to start is to put a phantom private network up hung off the back of the honeypot. Most corporate networks are divided into a private internal network and a public DMZ. It is poor security but common to find direct links from DMZ machines into the private network. If the attacker takes over the box and finds such a link, he is probably going to want to explore it. You cancreate whatever environment you want for him to explore. It should probably include a number of different operating systems running different services. Hopefully, the attacker will spot a service he has an exploit for and try to take it over. When the attacker transfers down the exploit, you'll get a copy to add to your library. The more compelling you make the simulated back end network; the more likely you'll get additional toys. Switching to a vulnerable OS/Service You have an exploit for a Wu-FTP server? I have one of those. Here you go. Keeping your production servers patched is a must, but keeping your honeypot patched just limits the amount of fun you can have with it. New exploits are generated for old vulnerabilities all the time. If you just ignore those exploits, you'll miss what's going on behind the scenes in the root kit development, distributed hacking tools, and anything else that requires them to actually get on your box. Nearly everyone that attempts an exploit has useful data to give. The trick is getting it from them. The best way to extract all the data is to let the exploit succeed and watch to see what they do. Even if they use an old exploit, they may use a new root kit or start up an IRC session that will lead you to some zero days. If someone has an exploit and take time out of their busy day to send it at your network, the least you can do oblige them with a root shell. To build an OS/Service switch, you'll need a public box, a switching box, and a number of boxes with various vulnerable services loaded on them. To cut down on the amount of real hardware, the vulnerable boxes can be replaced with VMWare instances. The switching box is an inline box with multiple interfaces. All new traffic is routed to the public box by default. Whenever and exploit is attempted on the public box, the IDS on the switching box looks up the OS and revision of attack and switches it over to the appropriate target. The operating system and services ofthe public box are what the attacker is going to see when he scans the box. You can use a few tricks to get people to try more exploits. One is to obfuscate the banners. Instead of having your web server identify itself as Apache, Identify it as Foobar.com front end proxy for Apache 1.3.19 and IIS 5.0 . Anything to get attackers to throw exploits at the honeypot. You're really interested in what he does after the exploit. After you're sure that you've extracted all useful data from a particular set of attackers, you can use utilities such as Hogwash or Snort-Inline to filter out that particular exploit or that particular root kit. The attacker may respond by changing their root kit or modifying their exploit in some way, but that in itself is interesting data. The hard part about running such an open honeypot is the recovery time. After each break-in, you need to clean off the attacker and reset everything for the next one. The two most popular methods are using ghost or VMWare. If you opt for ghost, you can simply ghost the drive before you put it up on the network and then restore the image as needed. With VMWare, you can keep a copy of the hacked image in an archive and the restart with a clean VMWare image. I've seen a few honeypots where the administrators used a file system mounted on a loop back interface. I believe they met with limited success. There are also some people experimenting with user-space Linux. It looks promising. Traffic Mangling Once you've got the Wiley hacker attacking your honeypot, the last thing you want to do is let him attack the rest of your network from the honeypot, or worse, attack someone else's network. A good line of defense in this instance is traffic mangling. Traffic mangling requires an inline box running software like Hogwash. The inline box can replace parts of an exploit with a broken equivalent. An example of a common mangler is to replace all instances of /bin/sh coming from the honeypot with /bin/hs. The attacker'sattempt to execv a shell on the remote box will fail. This particular mangler has provided me with hours of entertainment while I watched the attacker download his debugging tools, source code, and favorite traffic analyzers to try and find out why his exploits weren't working. A good policy is to set up manglers for all the exploits you can get your hands on and then some general rules such as replacing all sam._ with mas._ . It's impossible to stop all outgoing exploits with manglers, but it can give you peace of mind that the outside world is relatively protected from your compromised honeypot along with hours of fun watching attackers failed attempts to continue their attacks elsewhere. This implementation can be considered a form of data control which every honeypot/net should employ. Data control is a defense mechanism to stop attackers from attacking other machines or networks on the Internet from your honeypot. Connection and Byte Limiting Connection limiting can be used for both ingress and egress traffic. Connection limiting, like traffic mangling can provide you many hours of enjoyment watching intruders not understand why they can't have multiple outbound/inbound connections. If you only allow certain number of outbound connections and vice versa, these method can be somewhat easier to fingerprint, thus hinting to the attacker that he is currently on a honeynet or a system with traffic control. You can limit n number of connections inbound per x time frame. This would allow you control over your honeypot system in an attempt to control inbound recon and exploitation attempts. I have seen multiple compromises happen simultaneously. Egress connection limiting is a must for most honeypots. There are a number of ways you can go about it. You can restrict the honeypot to n simultaneous outbound connections. This will stop a number of DDOS agents and port scanning tools. As well as limit the damage an attacker can do by attempting to port-scan or even exploitexternal hosts. One of the things that will make the network folks and your ISP take an active interest in your honeypot is if you're infected with a DDOS agent. Most of the time the network admin, has his pager set to go off when the external link hits 100% saturation. To make matters worse, this usually happens at around 3 o'clock in the morning. You can limit the number of bytes transferred per second inbound or outbound. This method would be employed to stop the DDOS situation discussed above. This could also help kill some exploit attempts (e.g.: FreeBSD telnetd exploit). Unlike connection limiting, byte limiting is somewhat harder to fingerprint. A somewhat more elegant approach is to set the TCP window size in each packet to a small number. Although any of these methods will help, you should probably have a general purpose strategy to kill the honeypot if you see this process running somewhere. Bait-n-Switch The most basic, but among the most useful concepts a honeypot can be used for is to divert hackers from attacking your production network. This is commonly known as the bait-and-switch method. Bait-and-Switch consists of a production machine, the bait-and-switch machine, and a honeypot. A Bait-n-Switch honeypot needs three machines: your real web server, which can be an exact mirror of your web server minus all the sensitive data, and a BNS (Bait-And-Switch) box. Both the Honeypot and the Production web server are plugged directly into the BNS box. The BNS box runs an Intrusion Detection System. When the IDS determines that someone is an attacker, it starts redirecting the attacker's packets to the Honeypot instead of the production machine. On most networks having two machines with the same IP address is a bad thing, but that actually works in your favor with a BNS style honeypot. If the honeypot has the same IP and MAC address as the production server, the attacker may not notice that he's been switched. If he doesn't notice, you get to see all the funthings he had planned for your production server. If he does, he no longer has access to the production server and will probably go away. One current implementation of this approach is The Bait N Switch Project from Violating Networks. This method has defensive and research capabilities rolled into one system. Research comes into play once the attacker is switched and is now targeting the compromised honeypot (assuming the attack was successful). You have successfully defended your production machine and now have further research information on the attacker. Honeypots and The Law Whenever the topic of honeypots comes up, invariably there is someone who wants to debate the legalities of it. We're not lawyers, but here are some things you should think about when those inevitable discussions do come up. Entrapment is not a crime. It only applies to law enforcement and is only used as a defense to keep from going to jail. A normal citizen can't entrap anyone even if he really wants to. Trials generally have a bunch of people just like you in a jury box. If you're just trying to protect your networks, they will understand that. The legal system is not quite that messed up. Most of the time, the lawyers only get involved when there's enough money to make it worth their time. The FBI and other law enforcement agencies generally functions in the same manner. Unless you're prosecuting them, the chances of an attacker bringing any sort of legal action against you is zero. I've port scanned someone I don't know at least once a day for the last five years. I haven't seen the inside of a court room yet. Conclusions Honeypots can be a serious research endeavor, or something you can have fun with. Your fun will translate into interesting stuff for the attacker to play with. The attacker is much more likely to spend time with an interesting site than with a boring one. He probably already has all the credit card numbers and free porn he wants, but he may bewilling to send you a few more exploits for the chance to read about the affair you're having. There's no rule that says the network topology, has to be anything conventional when you're setting up your honeypot. Once someone logs in, you can present new hosts, traffic, and subnets that don't really exist. After all, they're only packets; you can craft requests and replies as well as a hacker. A honeypot is an illusion that you weave for the attacker. Your illusion can be as creative as you want it to be. A good illusion will get you zero day exploits, root kits, and loads of information on how attackers work. Above all, have fun with it. Jason Larsen Jason Larsen is the primary author of Hogwash. You can find his code is various projects including Snort , ATS, the GTK packet decoder, and a long list of others. He has been published in a number of online security journals and medical journals. He is currently the Network Security Architect for the Idaho National Engineering and Environmental Laboratories, a DOE nuclear research lab in central Idaho. Alberto Gonzalez Alberto Gonzalez is one of the leading contributors to the Bait N Switch Honeypot system. He also contributes to various other open-source projects including Hogwash and Bigeye. He is currently an Intrusion Analyst with EDS in Northern Virginia. He is also in the process of getting his GCIA certification from SANS.. Honeypots act as traps for cybercriminals and also enhance security strategies by revealing attack vectors and behaviors through decoys and analysis. Honeypot Techniques, Cybersecurity Research, Threat Simulation, Network Defense, Attack Patterns. . Brittany Day
Jul 22, 2003
•
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