This file will have the following format: zone Ĭreate a blackhole.hosts file that will look like a basic zone file: $TTL IN SOA ns.rootshell.be. Include in your “ nf” a list of malicious domains: include "/etc/named/bad-domains.zones" This is good for detection but what about adding some proactivity? What about configuring your local resolver to prevent it to resolve malicious domains? This can be also achieved using a simple configuration change. Great! But when this rule will be fired, it will already be too late and the risk to have the user infected is still important. The “ URL” field is extracted from the bind logs using the existing OSSEC decoder. Lists/bad-domains.txt DNS query for malicious domain! By indexing a list of bad domains, it’s possible to detect suspicious DNS traffic with a simple rule like this one: The classic types of information that can be found in CDB lists are: users, IP addresses, domains, ports, etc. CDB is a convenient way to index constant databases and perform lookups on them. This can be achieved with the “ CDB list” feature implemented into OSSEC. To achieve this, I’m using OSSEC to collect bind logs and search for interesting domains. First step, the detection! It is indeed critical to be notified in case of connectivity attempts with a malicious domain. Two actions are performed by those systems: To redirect the traffic to a black-hole (usually the loopback or 127.0.0.1) and to generate an alert to warn the security teams that a device tried to reach a blacklisted domain.ĭo you know that this feature can be easily implemented? Here is a quick overview of my setup. A DNS firewall will have a good knowledge of all those malicious domains and prevent users/applications to access them. The DNS protocol can also be used to transport other data. Another step is, once the infection completed, the communication with a C&C to request actions to be performed or to exfiltrate data. First, a user can be redirected to a malicious website which will send a payload to the browser (or any other application). Malicious DNS activity may occur at different steps to infect a computer. Malware authors or attackers register thousands of domain name, usually based on random strings. This is a mandatory network service and attackers know this! If the registration of domain names was very expensive a few years ago, today it became very cheap (when not free!). Their primary goal is to translate all FQDN (“ Fully Qualified Domain Names“) into IP addresses (v4 or v6). Most organizations have internal DNS resolvers. It’s a fact: without DNS, no Internet! We have to life with DNS servers infrastructures. But what is a “ DNS firewall” or “ Strong DNS Resolver“? It’s not a new buzz… The DNS protocol is well-known to be a excellent vector of infection and/or data exfiltration. For a while, I see more and more the expression “ DNS Firewall” used in papers or presentations. It looks that our beloved DNS protocol is again the center of interest for some security $VENDORS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |