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
open sourcethreat detectionsecurity strategyHoneynets: Essential Tool for Threat Detection and Cyber Intelligence
Honeynets are an invaluable offensive security tool for learning the tactics and motives of the blackhat community and sharing the information and insights gathered. This article will explore what a Honeynet is, its value, how it works and the risks involved with deploying a Honeynet. It will also examine some great open-source honeynet options your organization may wish to consider. . What is a Honeynet? A Honeynet is a type of honeypot - or resource whose value is being probed, attacked, or compromised - that is designed specifically for research. The traditional value of honeypots has been their ability to deceive blackhats and detect attacks. Smokescreen Product Manager Amir Moin elaborates on the value of honeypots: “Organizations can reap a myriad of benefits from deploying honeypots as part of a comprehensive threat detection strategy. Quality deception technology can help identify targeted threats with a very low rate of false positives. This technology is highly effective in detecting credential phishing attacks, identifying privilege escalation and lateral movement, protecting remotely accessible services and improving active directory security.” A Honeynet is different from a traditional honeypot - it can be categorized as a research honeypot. This does not make it a better solution than a traditional honeypot; merely it has a different purpose. Instead of a honeynet’s value lying in the ability to detect or deceive attackers, its value lies in the ability to gain information on threats. The two biggest design differences between classic honeypots and honeynets are: A honeynet is not a single system, but rather a network of multiple systems. This network sits behind an access control device where all inbound and outbound data is controlled and captured. This captured information is then analyzed to gain insight into the tools, tactics, and motives of the blackhat community. Honeynets can utilize multiple systems at the same time, such as Solaris, Linux, WindowsNT, Cisco router, Alteon switch, etc. This creates a network environment that more realistically mirrors a production network. Also, by having different systems with different applications, such as a Linux DNS server or a web server administrators can learn about different tools and tactics. Perhaps certain blackhats target specific systems, applications or vulnerabilities. Having a variety of operating systems and applications enables researchers to accurately profile specific blackhat trends and signatures. All systems placed within the Honeynet are standard production systems. These are real systems and applications - the same ones that are found on the Internet. Nothing is emulated nor is anything done to make the systems less secure. The risks and vulnerabilities discovered within a Honeynet are the same as those that exist in many organizations today. One can simply take a system from a production environment and place it within the Honeynet. It is these two design differences that make a Honeynet primarily a research tool. It can be used as a traditional honeypot, for purposes such as detecting unauthorized activity; however, a Honeynet requires significantly more work, risk and administration. It is simply not worth the effort of building and maintaining a Honeynet merely to detect attacks. For the sole purpose of detecting attacks, administrators are far better off with the simpler honeypot solution mentioned above. The Value of a Honeynet Traditionally, information security has been purely defensive. Firewalls, Intrusion Detection Systems, encryption; all of these mechanisms are used defensively to protect one's resources. The strategy is to defend one's organization as best as possible, detect any failures in the defense, and then react to those failures. The problem with this purely defensive approach is that the enemy is offensive and on the attack. Honeynets attempt to change this approach to security by giving organizations the ability to be proactive and take theinitiative. The primary purpose of a Honeynet is to gather information about threats that exist. New tools can be discovered, worms can be captured and analyzed before they do extensive damage and attack patterns can be determined. Captured information can also be used as an early warning system, alerting users of attacks before they happen. Honeynets can also provide an organization with valuable information on its own security risks and vulnerabilities. Honeynets can consist of the same systems and applications that an organization is using for its production environment. Risks and vulnerabilities that exist in a Honeynet (which is far more closely monitored and analyzed) identify risks and vulnerabilities in an organization's production environment. For example, a company may want to implement a new web server interface for credit card use. Both the system and application can first be tested in a Honeynet environment to identify any unknown risks or vulnerabilities. Additionally, a Honeynet can help an organization develop its Incident Response capabilities. It can vastly improve an organization’s ability to detect, react to, recover from and analyze systems that have been compromised. The advantage of analyzing these compromised systems is that, since most of the answers already exist, these systems can be viewed as a 'challenge', allowing organizations to test their abilities to determine what happened using various forensic techniques. These results can be compared to the data captured from within the Honeynet. This information can also be used to determine if any other systems within an organization’s production network have been compromised. How Honeynets Work Conceptually, Honeynets are a simple mechanism. In many ways, a honeynet is similar to a fishbowl - researchers and security professionals can see everything that happens inside it and watch for and monitor attackers in the network. Also, just like a fishbowl, there are many options for adding to and altering a Honeynet. Traditionally, the greatest problem security professionals face in detecting and capturing blackhat activity is information overload. The challenge for most organizations is determining from vast amounts of information what is production traffic and what is malicious activity. Tools and techniques such as Intrusion Detection Systems, host based forensics, or system log analysis attempt to solve this problem by using a database of known signatures or algorithms to determine what is production traffic and what is malicious activity. However, information overload, data pollution, unknown activity, false positives and false negatives can make analyzing and evaluating activity extremely difficult. Like all honeypots, the Honeynet solves this problem of data overload through simplicity. A Honeynet is a network designed to be compromised, not to be used for production traffic. Thus, any traffic entering or leaving the network is suspicious by definition. Any connection initiated from outside the Honeynet into the network is most likely some type of probe, attack or other type of malicious activity. Any connection initiated from the Honeynet to an outside network indicates that a system was compromised - an attacker has initiated a connection from his newly hacked computer and is now going out to the Internet. This concept greatly simplifies data capture and analysis. There are two critical requirements that define every Honeynet: Data Control and Data Capture. If there is a failure in either requirement, then there is a failure within the Honeynet. Honeynets are extremely flexible tools; they can be built and deployed in a variety of different ways. As a result, almost no two Honeynets look the same; however, they must all meet the requirements of Data Control and Data Capture. Data Control is what mitigates risk. It controls the attacker's activity by limiting what can happen both inbound and outbound. The risk is that once an attacker compromises a system within the Honeynet, they can then use thatsystem to attack other non-Honeynet systems, such as organizations on the Internet. The attacker must be controlled so they cannot compromise non-Honeynet systems. Data Capture collects all the activity that happens inbound, outbound, or within the Honeynet. It provides valuable insight by capturing attackers’ activities. The trick is to both control and capture attackers’ activity, without them realizing that they are within a Honeynet. There is a third requirement, Data Collection; however, this is only for organizations that have multiple Honeynets in distributed environments. Many organizations will have only one Honeynet, so all they need to do is control and capture data. However, organizations that have multiple Honeynets logically or physically distributed around the world have to collect all of the captured data and store it in a central location. By doing this, the captured data can be combined, exponentially increasing its value. The Data Collection requirement provides the secure means of centrally collecting all of the captured information from distributed Honeynets. Data Control As stated above, data control is the containment of activity. When dealing with blackhats, there is always risk that must be mitigated. It is critical to ensure that once compromised, a honeypot cannot be used to harm any system outside the Honeynet (anything inside the Honeynet is fair game). However, the challenge is to control the data flow without making blackhats suspicious. Once a system is compromised, blackhats will often require Internet connectivity, such as retrieving toolkits, setting up IRC connections, etc. We have to give them the flexibility to execute these actions, as these are the very steps we want to learn and analyze. Also, blackhats may become highly suspicious if they cannot initiate any outbound connections. We made that very same mistake with our first honeypot. We did not allow any outbound Internet connections. It took the blackhat only fifteen minutes to figure outsomething was wrong, wipe the system drive, and leave the network. So, the trick is to give the blackhat flexibility to execute whatever they need, but without allowing them to use the compromised system to attack others with Denial of Service attacks, system scans and other types of exploits. Data Capture Data Capture encompasses the capturing of all malicious activities that occur within a honeynet. It is these activities that are then analyzed to learn about the blackhat community. The challenge is to capture as much data as possible, without blackhats figuring out what is going on. This is done with as few modifications as possible, if any, to a honeypot. Also, data captured must be stored remotely - it cannot be stored locally on the honeypot. Information stored locally could potentially be detected by the blackhat, alerting them that the system is a Honeynet. Data stored locally is at risk of being lost or destroyed. Successful Data Capture is done in layers - no single layer will capture adequate information. Rather - data must be gathered from a variety of resources. Only a multi-layered approach reveals “the big picture”. The first layer of logging activity is the firewall. The firewall logs all connections initiated to and from the Honeynet. This information is critical, as all connections are suspicious. Firewalls should be designed not only to log all connections, but to also alert the administrator whenever a connection is attempted. This is extremely useful for tracking scanning patterns. Additionally, a firewall can detect backdoors or proprietary ports. Most exploits create a shell or backdoor on a system. These backdoors are easy to detect when the firewall alerts of a connection on a system on a random high port. The firewall should also send an alert when a honeypot on the Honeynet initiates an outbound connection. The firewall once again logs this activity - indicating that a system was compromised. Another critical layer is the IDS system, which has twopurposes. The first, and by far most important, is to capture all network activity. The primary job of the IDS is to capture and record every packet that hits the wire. The IDS system resides on a 'port monitoring' port, so it can record all network activity. These records are then used to analyze blackhats’ activities. The second function of the IDS system is to alert an administrator of any suspicious activity within the honeynet. Most IDS systems have a database of signatures. When a packet on the network matches a signature, an alert is generated. This function is not as critical for a Honeynet, as any activity is considered suspicious by nature. However, IDS systems can provide detailed information about a specific connection. Data Collection Data Control and Data Capture are two requirements for Honeynet technologies. Any time an organization deploys a Honeynet, it is critical to ensure that these standards are met. Data Collection is different in that it is optional. Data Collection is the aggregation of data from multiple Honeynets to a centralized point. Its purpose is to exponentially increase the value of information collected. Most organizations deploy only a single Honeynet, so Data Collection does not apply. However, some organizations deploy multiple Honeynets. In these cases, there needs to be a standard for Data Collection. When part of a distributed environment, each Honeynet is assigned a unique identifier. Data sent by each Honeynet to a central location is tagged with the unique identifier. This data is then forwarded by each Honeynet to the single data collection point. Virtual Honeynets Virtual Honeynets take the same concepts used in classic Honeynets and implement these concepts into a single system. This implementation has both advantages and disadvantages over clasic Honeynets. The advantages associated with deploying virtual Honeynets are reduced cost and easier management, as everything is combined on a single system. However, this simplicity comes at acost. Virtual Honeynets limit the types of operating systems you can deploy by the hardware and virtualization software they require. In addition, virtual Honeynets carry increased risk - as an attacker could potentially break out of the virtualization software and take over the Honeynet system, bypassing Data Control and Data Capture mechanisms. Open-Source Honeynets: Detect Threats For Free Cyberattacks are rapidly evolving, posing a bigger threat to organizations’ security than ever before. Deception technology is invaluable in detecting advanced attacks and reflecting the costs of these exploits back onto the attackers. Are you looking for a way to recognize the benefits of deception technology for free? Deploying open-source honeynets makes this possible. Smokescreen Product Manager Amir Moin explains, “Deception technology is an effective approach to threat detection. However, some organizations might be apprehensive about investing time and money into this technology without being certain that it will work for them. Security teams at these organizations can use open-source honeynets to “test the waters” and demonstrate value to management without spending a dime.” Here are some great open-source honeynet options you may want to consider: All-in-One Modern Honey Network (MHN) is a centralized server for honeypot management and data collection. It combines Snort, Kippo, Dionaea and Conpot. MHN is user-friendly and easy to install. Honeydrive is a GNU/Linux distribution that comes pre-installed and offers a host of active defense capabilities. It can be viewed as the “anti-Kali”. Network Services Honeynets Cowrie is a medium to high interaction SSH honeypot which emulates an interactive SSH server with customizable responses to commands. It is designed to log brute force attacks and the shell interaction performed by attackers. Dionaea is a multi-protocol honeypot that covers everything from FTP to SIP. It excels in SMB decoys, and isable to simulate malware payload execution to analyze multi-part stagers. Honeyclients and Malware Analysis Cuckoo Sandbox is not technically a honeypot; however, it’s an excellent sandbox for malware analysis. This tool allows you to safely execute possible malware samples, and it provides a comprehensive report on the code executed. Thug is a low-interaction “honeyclient” that mimics the behavior of a web browser to analyze client-side exploits. Database and NoSQL Honeynets MongoDB-HoneyProxy is a honeypot proxy that emulates an insecure MongoDB database, logging all traffic to a dummy MongoDB server. ElasticHoney emulates an elastic search instance, searching for attempted remote code execution (RCE). Honeytokens Canarytokens by Thinkst Applied Research let you position decoy data across your systems for attackers to trigger, helping track activity on your network. Internet of Things (IoT) Honeynets Honeything is a honeypot for Internet of TR-069 Things. It is designed to act as a modem/router with RomPager embedded web server. It supports the TR-069 (CWMP) protocol. SCADA/ICS Honeynets ConPot emulates a wide range of operational technology control system infrastructures, and is designed to be easy to deploy, modify and extend. It provides common industrial control protocols , which can be used to build a system that mimics complex infrastructures to convince a malicious hacker that he or she just found a huge industrial complex. This honeynet also comes with a web server that can emulate a SCADA HMI. GasPot emulates a Veeder Root Guardian AST that is commonly used in the oil and gas industry for monitoring. Honeynet Care, Feeding and Risk Honeynets are not a "fire and forget" solution- they are a complex type of honeypot that requires constant maintenance, administration and vigilance. For maximum effectiveness, administrators need to detect and react to incidents as soon as possible. By watchingblackhat activities in real-time, one can maximize Data Capture and analysis capabilities. Also, to detect the unknown, suspicious activity must constantly be reviewed. This requires extensive time and analysis capabilities. For example, in just 30 minutes a blackhat can do enough damage to a compromised honeypot to require 30-40 hours in order to fully understand what happened. Constant maintenance is also required to ensure operability of a Honeynet. If something goes wrong - which is definitely not uncommon - the Honeynet Your alert processes may fail, disks can fill, IDS signatures can become outdated, configuration files can become corrupted, system logs will need to be reviewed and firewalls will need to be updated and patched. This represents just a small portion of the constant care and feeding that is required for a Honeynet to be successful. Your work has only begun when you implement a Honeynet! Virtual Honeynets eliminate some of the headaches associated with deploying and maintaining a Honeynet by combining all the elements of a Honeynet onto one physical system. Not only are all three requirements of Data Control, Data Capture, and Data Collection met, but the actual honeypots themselves run on the single system. The honeypots are actual operating systems. Nothing is emulated. The advantage here is one of both cost and efficiency. It is much cheaper to use a single system to run all the elements of a Honeynet, and it is much easier to deploy and maintain. Also, there are risks involved with building and implementing a Honeynet that must be considered. Before deploying a Honeynet, it is important to understand and acknowledge that blackhats will be attacking and compromising these systems. By setting up a network to be compromised, administrators expose both themselves and others to risk. They assume a responsibility to ensure that the Honeynet, once compromised, cannot be used to attack or harm other systems. However, with an Honeynet environment, there is always the potential forsomething to go wrong. There are a variety of measures that can be implemented to mitigate this risk; however, it is quite possible for a blackhat to develop a method or tool that allows them to bypass these access control methods. Also, one needs to be constantly testing and updating the environment to ensure control measures are working effectively. Never underestimate the creative power of the blackhat community! The use of a firewall, routers and other techniques can help mitigate the risk of a Honeynet being used to damage other systems. However, there is risk associated with any Honeynet regardless. Finally, Honeynets should not be viewed as a solution for all of an organization’s security problems. LinuxSecurity Founder Dave Wreski cautions: “Organizations should focus on best practices first, such as strong authentication, use of encrypted protocols, reviewing system logs and secure system builds. By prioritizing proper policies and procedures, risk can be greatly reduced. Honeynets do not reduce risk - they most likely increase it. Honeynets are designed to gather information on the enemy - they will not fix unsecured servers, nor will they fix bad processes or procedures.” Conclusion Honeynets are a type of honeypot designed to gather information - specifically the tools, tactics and motives of the blackhat community. This information can be used to protect organizations against various threats. There are two design differences between traditional honeypots and a Honeynet. The first difference is that a Honeynet is not a single system, but a network of multiple systems and applications. The second difference is that Honeynets are production systems - the same systems found on the Internet. Neither the systems nor the vulnerabilities are emulated. This combination makes Honeynets an excellent research tool. However, Honeynets require a tremendous amount of administrative overhead. The Honeynet administrator has the responsibility of ensuring that no other systems will beattacked from a compromised Honeynet. LinuxSecurity Founder Dave Wreski evaluates the risks and benefits associated with deploying Honeynets: “Without proper administration, the risks of using a Honeynet may outweigh the reward. This tool is not a cure-all or a “band-aid” for fundamental security flaws, and it may not be a suitable solution for every organization. Organizations should first focus on securing their systems. Once secured, they may then be able to utilize Honeynets as a powerful tool to take the initiative and learn more about both the enemy and themselves.” . What is a Honeynet? A Honeynet is a type of honeypot - or resource whose value is being probed, atta. honeynets, invaluable, offensive, security, learning, tactics, motives. . Brittany Day
May 18, 2020
•
102
intrusion detectionincident responsenetwork attackLinux Honeynet Incident Responses: Analyzing Attacks and Observations
Among other benefits, running a honeynet makes one acutely aware about "what is going on" out there. While placing a network IDS outside one's firewall might also provide a similar flood of alerts, a honeypot provides a unique prospective on what will be going on when a related server is compromised used by the intruders. . As a result of our research, many gigabytes of network traffic dumps are piling up on the hard drives, databases are filling with alerts, rootkits and exploit-pack collections are growing. This paper is an attempt to informally summarize what was happening to our exposed Linux machine connected to the Internet. The moment is even more appropriate since we are now changing the platform of the victim machine.. Our Linux honeypot survived dozens, if not more, system compromises including several massive outbound denial-of-service attacks (all blocked by the firewall!), major system vulnerability scanning and serving as an Internet Relay Chat (IRC) server for Romanian hackers - and other exciting stuff. I. Battleground: services and ports First, let us summarize the common exploits hurled at the exposed Linux machine. It won't likely be news to people who monitor activity outside their firewalls, but it may provide some insight into current security threats to others. Scans, "innocuous" connection attempts and various spam (on port TCP 25 and UDP 13x) are not included. a. RPC statd - the attack is SO ancient, that one might think that nobody will hope to find a vulnerable box with that flaw. After all, who in his right mind will be fielding (for example) Linux Red Hat 6.0 when half a dozen Red Hat releases have come out since that time. We are talking August 2000 - it was indeed during the last millennium. Heavy scanning for this vulnerability was going on all through 2001 and even parts of 2002. One might think that all machines with that hole are either secured by the owners or by the intruders, upgraded or taken offline. However, lots of "hopefuls" are still trying the longcemented "door". Thus, the log files continue to be peppered with the classic: Mar 4 11:51:31 victim 29> Mar 4 11:51:31 rpc.statd[493]: gethostbyname error for ^X...^X...^Z...^Z...%8x%8x%8x%8x% 8x%8x%8x%8x%8x%62716x%hn%51859x%hn................................................ .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. .................................................................................. ....................../1..|Y.A^P.A^H...A^D.....^A.f...^B.Y^L.A^N..A^H^P.I^D.A^D^L. ^A.f...^D.f...^E0..A^D.f......1..?.. and snort continue spewing forth the good old: Jan 24 20:46:41 bastion snort: [1:1282:1] RPC EXPLOIT statdx [Classification: Attempted Administrator Privilege Gain] [Priority: 1]: {UDP} 10.0.0.10:931 -> 1.2.3.4:1024 And here is how this attack looks to the anomaly-based Bro NIDS, recently deployed in our honeynet: 1047644757.152094 10.0.0.10/939 > 1.2.3.4/portmap: bad_RPC_program 1047644757.152094 10.0.0.10/939 > 1.2.3.4/portmap: bad_RPC Bro detects a different stage of the same attack. b. WU-FTPD - this attack can also be categorized as "Stone Agey", but it is still very popular among the amateur attackers. It is this attack that led to those impressive statistics publicized by the Project Honeynet - default Red Hat box will be "owned" within 3 days from being connected to the internet. An extremely popular choice, this attack is used in countless autorooters, exploit scanners and other "tools for beginners". Here is how the attack looks to snort: Jan 26 20:37:16 bastion snort: [1:1378:7] FTP wu-ftp file completionattempt { [Classification: Misc Attack] [Priority: 2]: {TCP} 10.0.0.10:33761 -> 1.2.3.4:21 Jan 26 20:37:16 bastion snort: [1:1622:5] FTP RNFR ././ attempt [Classification: Misc Attack] [Priority: 2]: {TCP} 10.0.0.10:33761 -> 1.2.3.4:21 and to Bro: 1048402337.496125 FTP_ExcessiveFilename 10.0.0.10/1641 > 1.2.3.4/ftp #94 excessive filename: 00000000000000000000000000000000..[494].. c. IIS exploits - we have observed dozens of different Unicode strings and .ida requests aimed to hurt the Microsoft IIS web server. Starting from the classic one used by the worms in 2001 to the more obscure modern variant: Here is the excerpt of the HTTP protocol decode by Bro: /scripts/..%2f../winnt/system32/cmd.exe?/c+dir /scripts/..%35c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c%5c../winnt/system32/cmd.exe?/c+dir /scripts/..%5c../winnt/system32/cmd.exe?/c+dir /scripts/root.exe?/c+dir /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /msadc/..%5c../..%5c../..%5c/..\xc1\x1c../..\xc1\x1c../..\xc1\x1c. ./winnt/system32/cmd.exe?/c+dir /MSADC/root.exe?/c+dir /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%uc bd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090 %u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a It is obvious that those cannot affect the Linux Apache web server of the honeypot and are provided here only due to their extreme volume. It is interesting to note that some IP addresses receive much more than their share of such hits. This phenomenon is notexplained yet. d. OpenSSL flaw that allows the non-root access is a very popular choice as of today. While not giving root, it seemingly helps the script kiddies to learn about local exploits. It is suspected that its popularity is in part due to readily available and reliable exploit openssl-too-open (...) Here is the log trace of the openssl hit in Apache errror_log: [Mon Mar 3 06:40:48 2003] [error] mod_ssl: SSL handshake failed (server ns1.bkwconsulting.com:443, client 10.0.0.10) (OpenSSL library error follows) [Mon Mar 3 06:40:48 2003] [error] OpenSSL: error:1406908F:lib(20):func(105):reason(143) And here is the snort message: Feb 2 00:45:53 bastion snort: [1:1887:1] EXPERIMENTAL WEB-MISC OpenSSL Worm traffic [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:2328 -> 1.2.3.4:443 e. MS-SQL Slammer, while being called a flash worm, is still knocking on the UDP 1434. The volume has subsided as most of the affected hosts are taken offline, butol Slammer is till there, slamming away at closed ports of the Linux honeypot. Here is what snort says upon seeing it: Mar 10 22:01:11 bastion snort: [1:2003:2] MS-SQL Worm propagation attempt [Classification: Misc Attack] [Priority: 2]: {UDP} 10.0.0.10:1140 -> 1.2.3.4:1434 f. Here are some other less frequent attacks that flash by. A number of hits against vulnerable PHP were observed. The attack did not succeed and was seen only once or twice: Mar 10 14:57:15 bastion snort: [1:1425:6] WEB-PHP content-disposition [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:57774 -> 1.2.3.4:80 Mar 10 14:57:15 bastion snort: [1:1423:7] WEB-PHP content-disposition memchr overlfow [Classification: Web Application Attack] [Priority: 1]: {TCP} 10.0.0.10:57777 -> 1.2.3.4:80 g. What is not there? Old bind attacks (very popular in 1999) are gone, hopefully for good, and new ones (based on the recent Bind bigs) failed tomaterialize. SSH bugs are not actively exploited, while version surveying is observed pretty often. It is not clear why this is the case. Here is a summary of all events and attacks: The color indicates alarm severity. It resembles what is reported by DShield.org. Web attacks (80,443) "top the charts", and are followed by the recent MS-SQL hits (1434) and FTP (21) - the all time favorite. Proxy scans (1080, 3128,8080) are also very popular. Strangely, SNMP (161,162) is also in the picture, though appear to be just probes and not exploit attempts. II. Artifacts - exploits, rootkits and tools Intruders who visit our friendly neighborhood honeynet, rarely come empty-handed. They bring all sorts of gifts, such as exploit scanners, autorooters, rootkits, DoS tools and other goodies. Most of the captured kits are very simple, use only publicly available technology and carry all the signs of being created by unskilled people. They often corrupt the system and utilize such amazingly "stealthy" capabilities as using the root directory of the system to store their files or changing the root password ("owned means owned, right?") Exploits and automated exploitation tools, while seeming impressive, use very old attacks (such as those described above) and are not even attempting to hide their activities. Most of those tools are designed to scan huge pools of IP addresses for one or two vulnerabilities, manifesting the ultimate "opportunity hack" of going for the "low-hanging fruit". However, new and innovative tools do get brought in by the tide. For example, the covert channeling binary or the IPv6 tunnel tool were discovered by the Honeynet Project. III. Example Incidents Here are brief descriptions of several incidents that recently occurred in our honeynet. The classic WU-FTPD incident starts from an anonymous login to the FTP server. Then in a few minutes or hours the server is hit by the TESO "wurm" exploit. It has a recognizable signature of trying to create a directory 7350 (TESO). In a fewseconds, intruder tries to get his rootkit from a drop site (often some free storage site or even a Yahoo account) which is then deployed. Most observed rootkits start a ssh daemon on high port as a main backdoor method. On the next session (which occurs within hours or even days), we often see him getting scanners and trying to exploit more machines. The more recent openssl incidents are more interesting since the attacker does not have root upon breaking into the system (such as, user "apache"). One might think that owning a system with no "root" access is useless, but we usually see active system use in these cases. Here are some of the things that such non-root attackers do on such compromised systems: 1."IRC till you drop" Installing an IRC bot or bouncer is a popular choice of such attackers. Several IRC channels dedicated entirely for communication of the servers compromised by a particular group were observed on several occasions. Running an IRC bot does not require additional privileges. 2."Local exploit bonanza" Throwing everything they have at the Holy Grail of root access seems common as well. Often, the attacker will try half a dozen different exploits trying to elevate his privileges from mere "apache" to "root". 3. "Evil daemon" A secure shell daemon can be launched by a non-root user on a high numbered port. This was observed in several cases. In some of these cases, the intruder accepted the fact that he will not have root. He then started to make his new home on the net more comfortable by adding a backdoor and some other tools in "hidden" (".. " and other non printable names are common) directories in /tmp or /var/tmp. 4. "Flood, flood, flood" While spoofed DoS is more stealthy and harder to trace, many of the classic DoS attacks do not require root access. For example, ping floods and UDP floods can be initiated by non-root users. This capability is sometimes abused by the intruders, using the fact that even when the attack is traced the only found source would be acompromised machine with no logs present. 5. "More boxes!" Similar to a root-owning intruder, those with non-root shells may use the compromised system for vulnerability scanning and widespread exploitation. Many of the scanners, such as openssl autorooter, recently discovered by us, do not need root to operate, but is still capable of discovering and exploiting a massive (thousands and more) system within a short time period. Such large networks can be used for devastating denial of service attacks (for example, such as recently warned by CERT). Worms and other automated entities are also common. We observed many different OpenSSL worms (for their taxonomy, see this), including some with novel components such as Windows OpenSSL exploit, DoS agents, IRC bot deployment by the worm, automated local exploitation via ptrace bug, different backdoors, etc. Windows worms are also on the prowl. CodeReds, MS SQL and others are not gone. Their traces surface in the logs on the regular basis. They seem to be leading their own lives with ups and downs, sudden bursts of activity, and never seem to go away. Many other "fun things" are also hitting the shores of our honeynet. Among them are such beasts as the packets from 255.255.255.255, port 31337, various kinds of spam (email, MS RPC, web forms), a lot of various reconnaissance attempts (mostly scans and pings). Scans for proxies (1080,8080, 3128) are also extremely popular, as mentioned above. Anton Chuvakin, Ph.D., GCIA, GCIH is a Senior Security Analyst with netForensics, a security information management software company that provides real-time network security management solutions. His areas of infosec expertise include intrusion detection, UNIX security, forensics, honeypots, etc. In his spare time he maintains his security portal Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Information Security Publications. . Investigations have uncovered terabytes of data packets showcasing multiple events and intrusions within our Unix honeypot.. Honeynet Research, AttackObservations, Incident Responses, Intrusion Detection, Security Threats. . Brittany Day
Apr 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