There is a constant battle taking place on your network between the attackers and your defensive front. In this video, you’ll learn about honeypots, honeynets, fake telemetry, and DNS sinkholes.
<< Previous Video: Site Resiliency Next: Cloud Models >>
A honeypot is a system, or series of systems, that’s designed to look very attractive to an attacker. And hopefully, the attacker will try to gain access to these fake honeypot systems that are on your network. The actual attacker is probably not a human being– it’s probably an automated system. But that means that we can look to see what processes the attackers are using to identify, and then what methods they’re using during their attack of, these types of systems.
The honeypot is effectively a virtual world so that the attacker would be trying to gain access to a fake system and not to your actual production data. There’s many different kinds of honeypot software that you could install on your network. You could use Kippo, Google Hack Honeypot, or Wordpot, for example.
And with the software you’d install, it is a constant battle to make sure that the software you’re using is something that can accurately represent real data and real systems. The attackers have systems in place to perform checks to make sure that the systems they’re attacking are real and not honeypots. Your honeypot software has to be able to look and feel like a real system so that an attacker will attempt the exploits against that honeypot.
Once you start adding more honeypots to your network, you’ve created a honeynet. This is multiple honeypots where you can begin gathering information from multiple sources. You may find that an attacker starts on one server and goes to others. Or you may find that multiple attackers arrive at one time performing different functions on different honeypots. A good example of a honeynet and a system that’s in place to be able to share the information that is found in these honeynets can be found at projecthoneypot.org.
Inside of your honeypots and your honeynets, you’re going to put your honeyfiles. This is very attractive bait that you’re hoping that the attacker will go after. This might be a file name, for instance, called passwords.txt which is oh so appealing to that attacker. They want to be sure they gain access to that file.
If that file is accessed by the attacker, you can receive an alert that says that someone must have gained access to passwords.txt. It’s effectively a way that you can know if someone did try to attack that system and what type of information they were able to gather.
One of the advantages we have with our modern technology is the ability to gather large amounts of data, in some cases very diverse data, and be able to analyze that data to try to find things that are similar or contrasting within those data files. This is machine learning that takes this big data and is able to identify patterns and information within that very large data source. To be able to have this machine learning understand what we’re looking for, we need to train it with actual data.
So we’ll feed it with malware, ransomware, viruses, and anything that will show the machine what bad data, or malicious data, might look like. The machine learning programming will then get an understanding of the type of data it should be looking for and how it may be able to identify this malware from the way that it operates rather than from a specific signature. The attackers know that you’re using this type of example to be able to train the machine.
So they’ll add their own fake telemetry into this data to try to get the machine to think that the malware is actually something good. This means that they can send this fake telemetry into the machine. And once the training is over, they can then send their malicious software through, and the machine will not be able to identify it.
Another useful tool for a security professional is a DNS sinkhole. The DNS, of course, is the domain name service that is handing out IP addresses that are associated with fully qualified domain names or FQDNs. It’s very common for a client with an FQDN to be able to ask a DNS server for the proper IP address so that it can then communicate directly with that service.
A DNS sinkhole, however, performs the opposite of this process. When the client requests the IP address of a particular FQDN, this device gives a response back with incorrect or invalid information about that service. This can be bad if an attacker is implementing a DNS sinkhole, because they may be able to redirect users to a specific location or may create a denial of service where no one is able to communicate to the proper service.
This is more commonly used, however, to provide intelligence for the security professional. We know that there are certain sites that a user will visit if they happen to be infected with a type of malware. So instead of allowing that user to communicate to that external server, we’ll instead configure a DNS sinkhole. And if anyone ever requests the IP address of that malicious site, we will provide it with an IP address of a machine inside of our location that we can then create a report on to determine who might be infected with this malware in our organization.
This is a function that’s often integrated into an intrusion prevention device or next-generation firewall. If someone tries to communicate out to one of these known malicious sites, the DNS sinkhole will send an IP address that redirects them to a known good site.
And this also will create an alert, or an alarm, so that the security team within the organization will know that a particular device is infected with this malware. This means that the device with the infection will not be able to communicate out to the command and control. And it also means that your security team can clean those devices before that infection spreads.