As a Linux administrator or security practitioner, you understand DNS's essential role in network security. Attacks and unauthorized access pose threats against DNS connections, so robust security protocols must be implemented to safeguard them. Zero-Trust DNS provides greater security, control, and flexibility over DNS traffic. . Security experts, like Bruce Schneier, have covered Microsoft’s plans to secure Windows DNS with Zero Trust , currently in private preview. However, if you’re a Linux user like me, you can still learn and benefit from Microsoft's work. While you’re not planning to switch to Windows anytime soon (I would hope!), let’s explore what you can learn from this initiative and practical measures you can take to improve DNS security. Understanding DNS & Its Importance Domain Name System (DNS) is an integral component of internet infrastructure that links domain names (such as example.com) with their associated IP addresses. Operating like a "phone book," DNS converts domain names into numerical IP addresses that network devices use for communication. DNS is a key component of network security by helping to detect potential threats or suspicious network activity. DNS logs and queries can aid in the identification of possible security risks, such as DNS spoofing or malware infections . Furthermore, DNS filtering services offer another layer of defense by blocking access to known malicious domains or providing protection against known phishing websites. Why Is DNS Vulnerable to Compromise? Despite its critical importance, DNS is vulnerable to compromise for the following reasons: DNS Cache Poisoning: Attackers can manipulate the DNS cache by exploiting vulnerabilities and injecting false information. By poisoning the DNS cache, attackers can redirect users to malicious sites or intercept communications. This can lead to phishing attacks or other cybercrime. DDoS attacks: DNS servers are susceptible to Distributed Denial-of-Service, or DDoS attacks ,which overwhelm them with massive traffic. This can cause service disruptions and make the DNS unavailable, preventing users from accessing websites. DNS Hijacking: Malicious actors may hijack DNS settings or compromise DNS servers to redirect users to malicious sites. This can be achieved through different techniques, such as DNS spoofing and DNS hijacking. The goal is to trick users into giving sensitive information or spreading malicious software. Lack of encryption: DNS queries and answers are sent in plaintext, which makes them vulnerable to interception and eavesdropping. Attackers can monitor DNS traffic to gather information on the websites users access, compromising their privacy and security. What Is ZTDNS & How Will Microsoft Use It to Improve DNS Security? Microsoft plans to enhance the security of Windows DNS with Zero Trust DNS (ZTDNS) , a recent initiative addressing long-standing security vulnerabilities associated with DNS (Domain Name System). DNS provides translation between human-readable domain names and numerical IP addresses but has long been vulnerable due to a lack of end-to-end encryption and potential malicious DNS servers. Until this point, prioritizing DNS security has typically forced admins to sacrifice visibility into network traffic. Admins have had to choose between unencrypted - and unprotected - DNS with monitoring capabilities or encrypted DNS that impedes monitoring and control. Integrating the Windows DNS engine and Windows Firewall directly into client devices, Microsoft’s ZTDNS seeks to help admins overcome this problem and achieve optimal security, visibility, and control simultaneously. How Does ZTDNS Work? ZTDNS blocks all outbound client device connections to IP addresses except protected DNS servers and necessary network services like DHCP and NDP. Any resolved IP addresses from the protected DNS servers will trigger exceptions in the firewall to allow outbound connections, effectively associating domain name resolutions withpermitted IP addresses. Optionally, administrators can use client certificates to enforce DNS resolution policies, enhancing security for remote or mobile device management. ZTDNS operates under the Zero-Trust Principle , which assumes all traffic is forbidden unless explicitly allowed. By default, it restricts outbound connections from other DNS servers except approved protective ones. ZTDNS doesn't introduce new network protocols but works seamlessly with either DNS over HTTPS (DoH) or TLS (DoT), offering significant security advantages network security while remaining compatible with both platforms. ZTDNS offers encrypted and authenticated connections between end-user clients and DNS servers, allowing administrators to securely limit the domains these servers can resolve. By integrating the Windows DNS engine with its filtering platform, ZTDNS provides organizations with an effective means to control and secure DNS traffic in Windows networks. Challenges & Considerations Although ZTDNS offers significant protection benefits, successful implementation may require extensive testing and organizational changes for optimal use. It is crucial to remember that ZTDNS is a DNS query encryption solution that reduces the visibility of DNS queries. However, this is compensated by providing endpoints with policy-enforced DNS solutions. Organizations must test their ZTDNS network configurations to ensure compatibility, functionality, and security. They will also need to adapt their operational and security practices. How Can Linux Users Improve DNS Security? While Linux users cannot directly benefit from Microsoft’s ZTDNS initiative, Microsoft’s recent efforts to lock down Windows DNS with ZTDNS underscores the importance of prioritizing robust DNS security regardless of the OS you use. To maximize DNS security in Linux environments, administrators can implement several best practices and practical measures: Implement DNSSEC (Domain Name System Security Extensions): DNSSEC addscryptographic signatures to DNS data to verify its authenticity and integrity, thus decreasing risks related to DNS spoofing and cache poisoning attacks. Use DNS Filtering: Deploy a DNS firewall or filtering solution to block access to malicious domains, block communication with known malicious IP addresses, and filter out any unauthorized DNS queries. Regular Patching and Updates: Ensure the DNS software and server remain up-to-date with the latest security patches to address vulnerabilities that attackers could exploit. Restrict Zone Transfers: Limit zone transfers to authorized DNS servers and networks to prevent unwarranted access to DNS data by attackers who can then conduct reconnaissance. Utilize DNS Logging and Monitoring: Enable DNS query logging and monitoring to detect abnormal or suspicious DNS activity, such as high volumes of failed or unusual queries that could signal an attack. Implement a Split DNS Architecture: Implementing a split DNS architecture will enable you to ensure internal DNS records do not appear on external networks, reducing attack surface area. Enable Response Rate Limiting (RRL): To prevent DNS amplification and DDoS attacks, configure RRL on DNS servers to limit how often they can answer identical queries. Strengthen Access Control and Authentication: Employ robust access control and authentication mechanisms to restrict access to DNS servers and ensure that only authorized personnel can modify DNS records or configurations. Regular Security Audits and Testing: Conduct regular security audits and vulnerability assessments on your DNS infrastructure to detect weaknesses or misconfigurations that attackers could exploit. Back-Up and Recovery Planning: Establish comprehensive backup and recovery procedures to safeguard DNS data in case of compromise or data loss. Implementing these best practices, Linux admins can significantly strengthen DNS security and reduce risks related to attacks or vulnerabilities involvingDNS-based attacks. Our Final Thoughts on the Importance of Linux DNS Security The critical importance of DNS security cannot be overlooked in any OS, and Microsoft's efforts to secure Windows DNS with Zero-Trust DNS (ZTDNS) demonstrate the tech giant’s recognition of this. Although Linux users cannot directly benefit from this initiative, there are practical measures and best practices they should engage in to strengthen DNS security in Linux environments, such as implementing DNSSEC, using DNS filtering, regular patching and updates, and conducting security audits. By prioritizing DNS security and following these practices, Linux admins can mitigate risks associated with DNS-based attacks and fortify their network infrastructure. . Linux administrators can boost DNS security by leveraging strategies from Microsoft’s Zero Trust DNS, covering DNSSEC, user education, and monitoring.. Linux Administration, ZTDNS, DNS Filters, Network Security Practices, Improving DNS Security. . Brittany Day
Cybercriminals implement scanning into their attacks to find network machines with open ports that they can utilize to bypass security and harm businesses and employees. Before launching an attack, threat actors run cloud security scanners like Linux Nmap that can sweep servers and find cybersecurity vulnerabilities to exploit. Once they identify a target, an intruder can use TCP stack fingerprinting to determine the type of machine they are breaching. . Organizations must work with the same tools that threat actors implement so employees can see what network security issues permit cybercriminals into a system. This article will discuss Nmap, how to utilize it in various privacy sandboxes, and how to prevent cloud security breaches from entering your server so you can improve your security posture. What is Nmap? Nmap is a free-to-download service under the GNU General Public License (GPL) that can analyze collected data regarding hosts and services within a network. We will focus on how to work with Nmap on the command line as we move forward. Let’s start with a few basic explanations and steps that can help with your understanding of this cloud security framework: Within the "nmap" command line, scans have an -s flag specifying their type. Select one of the scanner options and what host or network you want to target. You can scan one host or an entire network with the correct configurations. Providing a network address with "/mask" appended to it can help you learn more about your targets. Once you understand how Nmap functions, you can run root commands and custom packets that prove effective in your analysis. Specify networks with wildcards such as 192.168.7.*, 192.168.7.0/24, or 192.168.7.1,4,8-12 to scan selected hosts on a subnet. What Techniques Can I Use on Nmap to Find Cybersecurity Vulnerabilities on My Server? You must learn the various methods you can implement for testing your server so you can integrate security patching as best as possible tokeep your organization and employees secure. Here are some configurations you can utilize to strengthen data and network security: Ping Sweeping Intruders can sweep entire networks looking for targets with Nmap. This is usually done with a ping scan using the "-sP" flag. By default, Nmap will send an ICMP echo and a TCP ACK to each host it scans. Nmap will consider hosts that respond to either to be up. In this example, scan all hosts on the 192.168.7.0 network: # nmap -sP 192.168.7.0/24 Starting nmap V. 2.12 by Fyodor (
This article will discuss a very useful but seemingly overlooked functionality of Netfilter, a firewall code widely used in Linux, that provides content matching and filtering capabilities. . This feature is offered as patch to Netfilter kernel-space code (Linux kernel) and user-space code (iptables) Since version 1.2.7a, it's been made available as a separate package called patch-o-matic. Traditional network-level firewall can inspect packets based on IP addresses, ports, TCP/IP flags completely ignoring the content in the payload. Imagine, what you can do with a firewall that can inspect more than just headers but the content in payload of every packet. With that type of firewall, you can easily block malicious worms and viruses that , I believe, are still hiting your machine every minute of the day. More interestingly, there are tools that will convert snort signatures into iptables-aware format (even with hex string support), enabling intrusion prevention at the kernel space and stopping the attacks before they occur. Having said all that, I shall show you how to put things together: First thing you need to do is to grab all the required packages: Kernel source code which has Netfilter kernel-space code integrated and compatible with the latest Netfilter user-space code (version 2.4.18+) . The latest stable version can be downloaded at ( https://mirrors.edge.kernel.org/pub/linux/kernel/v2.4/linux-2.4.21.tar.bz2 ) Netfilter user-space code which is now iptables, (latest version is 1.2.8) but currently only version 1.2.7a supports hex string patch ( https://netfilter.org/projects/iptables/files/iptables-1.2.7a.tar.bz2 ) and the corresponding patch-o-matic package ( https://netfilter.org/projects/patch-o-matic-ng/files/patch-o-matic-20030107.tar.bz2 ) FWSnort, a perl script that will convert most snort rules into iptables rules. Don't forget to grab a hex string support patch that adds a hex-string capability to libipt_string.c to iptables source also. All these stuff areavailable at ( www.cipherdyne.com/fwsnort/ ) Unpacking them in appropriate directory: [tony@0x90 src]$ tar -jxf linux.2.4.21.tar.bz2 [tony@0x90 src]$ tar -jxf iptables-1.2.8.tar.bz2 [tony@0x90 src]$ tar -jxf patch-o-matic-20030107.tar.bz2 Apply libipt_string patch to iptables source and build iptables kernel and user spaces code: [tony@0x90 src]$ cd iptables-1.2.7a/extensions [tony@0x90 extensions]$ patch -p1 < libipt_string.c.patch [tony@0x90 iptables-1.2.7a]$ make KERNEL_DIR=../linux-2.4.21 [tony@0x90 iptables-1.2.7a]$ sudo make install KERNEL_DIR=../linux-2.4.21 Next step is to apply a string match support from a patch-o-matic package. A patch-o-matic is a series of Netfilter add-ons that provides extra functionality to original Netfilter. It has a nice automated script that will allow you to choose which patches you want integrated and checks their dependencies. You should be aware that,some patches might not work with one another, so carefully read the comments before you apply any patches. In this case, we will apply only string-match support patch: [tony@0x90 src]$ cd patch-o-matic-20030107 [tony@0x90 patch-o-matic-20030107]$ KERNEL_DIR=../linux-2.4.21 ./runme extra Welcome to Rusty's Patch-o-matic! Each patch is a new feature: many have minimal impact, some do not. Almost every one has bugs, so I don't recommend applying them all! ------------------------------------------------------- Testing... fuzzy.patch NOT APPLIED ( 2 missing files) The base/fuzzy patch: Author: Hime Aguiar e Oliveira Jr. Status: Under development , but works . This option adds CONFIG_IP_NF_MATCH_FUZZY, which allows you to match packets according to adynamic profile implemented by means of a simple Fuzzy Logic Controller (FLC) . Suppported options are: --upper-limit => Desired upper bound for traffic rate --lower-limit => Lower bound over which the FLC starts to limit traffic ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/v/q/?] N This patch is not of our interest, so answer no (N) to go to the next one. Keep going until you find our string-match (-m string -string) patch and answer yes (y) to apply it: Testing... string.patch NOT APPLIED ( 2 missing files) The extra/string patch: Author: Emmanuel Roger Status: Working, not with kernel 2.4.9 This patch adds CONFIG_IP_NF_MATCH_STRING which allows you to match a string in a whole packet. THIS PATCH DOES NOT WORK WITH KERNEL 2.4.9 !!! ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/v/q/?] y Testing patch extra/string.patch... Placed new Config.in line Placed new Configure.help entry Placed new Makefile line Patch extra/string.patch applied cleanly. Applying patch extra/string.patch... Patch extra/string.patch applied cleanly. Placed new Config.in line Placed new Configure.help entry Placed new Makefile line [Press enter to continue] Now, go back to the directory where you unpacked the kernel source and proceed with the compilation. (If you have compiled your own kernel before, you can just skip reading this section), Instructions on how to compileand customize your kernel can be read at (https://tldp.org/HOWTO/Kernel-HOWTO.html) [tony@0x90 linux-2.4.21]$ make mrproper && make menuconfig [tony@0x90 linux-2.4.21]$ make menuconfig [tony@0x90 linux-2.4.21]$ make dep && make bzImage [tony@0x90 linux-2.4.21]$ sudo make modules && make modules_install [tony@0x90 linux-2.4.21]$ sudo cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.21 [tony@0x90 linux-2.4.21]$ sudo mkinitrd -f -v /boot/initrd-2.4.21.img 2.4.21 Finally, we are done with building all the components, reboot the system and enjoy your new toy. Now let's test this new functionality and use it as an active defense system: # This rule rejects all incoming mails with a string of "Buy Now" which many people consider it #as spam iptables -A INPUT -p tcp -dport 25 -m string --string "Buy Now" -j REJECT --reject-with tcp-reset # Blocks superscan ping but allows other types ping iptables -A INPUT -p icmp -icmp-type 8 -m string -string "|0000000000000000|" -j DROP # This will reset any connection that attempts to access a shell, in which you will find in most exploit codes iptables -A INPUT -p tcp -m string --string "/bin/sh" -j REJECT --reject-with tcp-reset Let's see if it works, on the server side execute nc -vv -l -p 23, on the remote host execute: telnet 10.0.0.1 23 Trying 10.0.0.1 Connected to 10.0.0.1 Escape character is '^]'. hello /bin/sh Connection closed by foreign host. # Thanks to hex string support, now we can easily block x86 NOOP sleds used in most buffer overflow exploits (use this with care, since it is possible that binary files transfer in e-mail may contain these strings and will get dropped!) iptables -A INPUT -p tcp -dport 22 -m string --hex-string "|90 90 90 90 90 90|" -j DROP iptables -A INPUT -p tcp -dport 80 -m string --hex-string "|90 90 90 90 90 90|" -j DROP You can try any buffer overflow exploits and will find that most of them get silently dropped! Now, you begin to have some idea on how to use this new feature as a content-based firewall system either for your local host or internal network. The FWSnort script that you have downloaded in the beginning will come into play as we will use it to convert some snort signatures into iptables rules. First unpack the source and install it: [tony@0x90 fwsnort-0.1]$ sudo perl install.pl Edit the configuration /etc/fwsnort/fwsnort.conf file to suit your needs and start the conversion: [tony@0x90 fwsnort-0.1]$ sudo fwsnort -c /etc/fwsnort/fwsnort.conf --ipt-drop A converted set of snort rules will be written to /etc/fwsnort/fwsnort.sh in a form of a shell script. Modify it again to suit your need , and merge it with your existing firewall rule. One thing you should keep in mind when working with a large iptables rules is that, everytime you perform an APPEND or INSERT, iptables will allocate a memory and invoke this function every time , resulting in a very slow performance. Iptables has a solution to this problem byproviding you scripts that will load a large rule set into the kernel very quickly or dump the current rule set from the kernel into iptables configuration file. So I suggest you first run your firewall script and then save it as iptables format using the command: iptables-save > /etc/syconfig/iptables Then whenever you need to reload the firewall rule-set you simply issue the command iptables-restore , and all rules will be reloaded in a much faster manner. Up to this point, you may think that if this functionality is so powerful, why doesn't anyone use it in replacement for snort? Although, Netfilter can perform a stateful inspection of content in a packet at the network level, it still lacks advanced capabilities in handling fragmented packets, polymorphic shell codes, traffic normalization, etc. Snort, on the other hands, can perform a pattern matching using a much faster algorithm called Boyer-Moore, supports a stateful packet analysis and stream reassembly. If you are interested in using snort as defense system, there is an ongoing honeypot project ( ) that uses a modified version of snort called snort_inline and a special set of firewall rules to achieve a hybrid firewall system. In conclusion, I would like to comment that intrusion prevention is still at its early stage and there is no out-of-the-box product that will perfectly fits your requirements. Every network has its own culture and usage behavior thus needs a distinctly unique tuning. Don't simply rely on a single tool but do correlate data from various sources and use them to understand your network and improve your security infrastructure. Nawapong Nakjang has been working in the areas of information security, network security and cryptography for several years. Hisinterests include intrusion detection, honeypots, incident investigation, malicious code analysis, computer forensics and penetration testing. Occasionally, he writes security-related article and answers security questions in mailing lists. He plans to pursue his second degree in Information Security and publishes more papers to the security community. . Network security is crucial as new threats emerge. Netfilter, a robust Linux firewall, enhances security with advanced content filtering and intrusion prevention. Netfilter Content Filtering, Intrusion Prevention System, iptables Configuration. . Brittany Day
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
Get the latest Linux and open source security news straight to your inbox.