Berkeley Internet Name Domain Spoofing Attack - Assignment Example

Introduction Everybody agreed that the internet and networking world needed a way to communicate with each other. In order to combat this problem people came up with an IP address system for each computer and server. However, people can not easily remember each IP address because of hard to remember numbers like 212.103.50.3. This number is just for just one website or server, so you can imagine how hard it would be if the client needed to have to type each and every IP address for every single website that they enjoyed visiting on a daily basis. For example, a website called "Albaheer" could have an IP address of 208.113.201.163, a number that most people would not be able to easily commit to memory. Still, if a client wanted to visit the site he would have to type all the digits of the IP address. Therefore, the interned needed a service that could be human-legible and easy to remember for humans. The domain name service (DNS) was thus invented in 1983. This new service was the solution for translate the domain name which is suitable for human-beings to IP address which is suitable for computers. There are different types of DNS such as Microsoft DNS, djbdns and Berkeley Internet Name domain (BIND). The BIND is the most commonly used for DNS server. The DNS has different types of attacks. These include the Denial of Service (DOS) attack, the spoofing attack or attacks against the DNS software. Attacks could in possibility lead to taking the host control over which could lead to further attacks. Names servers' response has two ways to operate for queries received: 1. Recursive; this particular type is used when a user made a request to name server and then the name server made non-recursive queries to find the data requested. 2. Non-recursive: this request used when a name server ask another name server for a data, the return will be A: an answer. B: send the request to another name server. C: an error about the name server has no data or information for the request. In this assignment I will focus on securing BIND from spoofing attack and the configuration needed to log that specific data transfer. Figure 1-1: Domain names, arranged in a tree, cut into zones, each served by a name server. Bind/DNS spoofing and poising attacks The attacker could affect the name server, which would allow recursive queries from any source to look up and cash the data. These zones would now be under attacker control and then the victim name server makes the attacker malicious name servers. This can result in the victim name server starting to cash and serve bogus data. This senior could be vulnerable in the name servers that allow the recursive from any source. Which, in most name servers comes by default. Also this could lead to a Denial of Server (DoS) attack or even possibly a Man-in-the-middle (MITM) attack. The network administrators have some options to secure the BIND from the spoofing attack. There are some options that could be used for a particular version of BINS. These options are as follows: 1. Disable recursion entirely. 2. Restrict the addresses that can make queries to the name server. 3. Restrict the addresses that can make recursive queries to the name server. 4. Disable the fetching of glue records. 1. Disable recursion entirely By disabling the name server that mean the name server will be in the passive mode. It will then not send queries on behalf to other name servers. A non-recursive name server is secure from cash poisoning and also DoS attack because a non-recursive name server will just respond to the queries that send to it directly and will not send queries so it does not cash any information or data. To disable recursion entirely in the BIND version 8 and 9 , you have to add this statement : options { recursion no; }; 2. Restrict the addresses that can make queries to the name server This option allows the system to specify known sites and zones that could make queries. The benefit of this method is that there are provided response and answers for each zone and provided recursive name resolution for Services to their internal systems. This action could enable recursive servers in their internal systems while it is totally disable from other name servers. That solution could suitable form an environment that required recursive queries and authoritative response. So, the recursive queries should come from internal address. For example, the internal network uses 192.168.2.0/24 address block and also needs to provide authoritative responses for the Albaheer.com zone. In this situation, there is a allow-query sub statement to restrict the recursive services to the internal address block while it is allows any address to make a request in the albaheer.com zone. To configure that in the name server, the first thing to configure this it have to define an access list that describe the internal network block: acl internal { 192.168.2.0/24; }; On the other hand, if the name server configures to be used by another internal name servers such as local cache, then the access list will configure to allow these internal name servers. This can be done in our example, if the internal name servers that allows are at 192.168.2.102 and 192.168.2.50 then the configuration of it will be like this: acl internal { 192.168.2.102/32; 192.168.2.50/32; }; After that, to make the default of just provide services to the internal network the configuration of it will be: options { ... allow-query { internal; }; ... }; Finally, to change the default to allow queries from anywhere just from records in the Albaheer.com zone, will be: zone "Albaheer.com" { type master; file "db.Albaheer.com"; allow-query { any; }; ... }; 3. Restrict the addresses that can make recursive queries to the name server. The administrators could also restrict the addresses that can make recursive queries to the name server. He or she would do this by defining views for the information that served by the name server. By using views effect clients and some other name servers and by seeing different answer and response that based in their IP addresses the administrator can restrict the addressed that can make recursive queries. In our example, the internalview view allows the recursion address that defined in the internal access list. On the other hand, the externalview view does not permit recursion. view "internalview" { match-clients { internal; }; recursion yes; }; view "externalview" { match-clients { any; }; recursion no; }; It also could be supported and defined by any zones such as Albaheer.com and it could be written as mentioned in the option 2. Both of the internalview and also externalview views could also see the same information and data for the Albaheer.com zone. 4. Disable the fetching of glue records. The glue fetching is the behaviour that is used in the most recent BIND version up until version 9, in which it comes by default. It then comes when a name server is responding and returning Name Server Record (NS) records but does not have corresponding record to include as additional data and information. It then may attempt to retrieve them. When a user disables the glue fetching it could prevent this lookup, thereby eliminating the possibility that the name server might cache bogus A records retrieved in this manner. To disable the glue fetching one can use the fetch-glue statement in BIND 8 and above: options { ... fetch-glue no; ... }; Secure a Bind/DNS server configuration The BIND is popular software that is used in many networks to provide name services. However, the BIND just like other software has some vulnerability. so there is miss configuration that could leads the system to be under the attacker control. So, in this section we will provide some secure configuration options for BIND in the hopes or making it more secure. First of all, the BIND uses IDS messages to identify each incoming response that comes from the result of outgoing squires. So, it could be that an attacker could predict the message ID of a query and try to spoof the query response. Therefore, it is recommended that the administrator's lets the BIND uses random message ID. With BING it can be done by using use-id-pool directive, so this will make the message ID harder and difficult to predict or spoof the replies. This option is written like this, although this is a good idea in the BIND version 8 and below but the version 9 is already randomized all their message IDS. options { ... use-id-pool yes; ... }; The second solution to secure configuration is to run the name server as a user other than to let it run the program as it were a root. This could protect the BIND and server from any vulnerability that could be discovered and then the BIND will be vulnerable. If the attacker gains access to the server he will not get the root access in the server. It is recommended to run the BIND in the user that has little privilege that could just be able to read BIND related files. The structure to run named with another user that root is as follows: 1. Create new user and group for the user that run named, for example: user=named & group=named. 2. Get the new user access read to the zone files*. 3. If the server using dynamic update then the administrator have to make sure about the new user has the write access to any zone files for what the dynamic updates are required. 4. The administrator have to make sure about that the new user has write access to named's PID file. The PID default file is that /var/run/named.pid, however, the /var/run/ is not writeable for non-root users. And also the default could be overridden with the pid-file option. in our example, if the /var/named/ is writeable by the new user then the PID file can be written like this: options { ... pid-file "/var/named/named.pid"; ... }; Finally, run the named command with the -u option so that command will change it to the new user. yaser@HacKeRBOX:$ named -u named The third and final solution to secure the name server configuration is tho run the name server in a chroot() "jail". This option is for getting the name server more secure against the attackers who could used BIND vulnerability. By using named in a chroot() "jail", this will be able to protect the entire filesystem if it is exposed. To do that it is required to make a change in the named at a chroot() which can be like this: 1. Create new directory for the named to run in it. For example /var/named/ . 2. Create the appropriate subdirectories for named. 3. Make sure to copy the necessary files to the new directory, and also copy the important files such as the named binary, the named.conf configuration file, and all zone files, the named-xfer binary and shared libraries. 4. Run the named command with the -t option to choose the chroot() directory. yaser@HacKeRBOX:$ named -u named -t /var/named The whole configuration for securing BIND configuration could be like which content the assignment example from the internal address to the domain zone. the first example describe the name server with a primary master for a zone and IP address authentication but does not support slaves and either does not use as forwarder. This configuration allows anyone to make queries at the name server but deal with all queries as non-recursive. acl slaves { 192.168.2.50; 192.168.2.102; }; options { directory "/var/named"; recursion no; fetch-glue no; // for BIND 8 only allow-query { any; }; }; zone "albaheer.com" { type master; file "db.albaheer.com"; allow-transfer { slaves; }; }; The second example is the same as the above but with supporting one or more than one resolves. acl internal { 192.168.2/24; }; acl slaves { 192.168.2.50; 192.168.2.102; }; options { directory "/var/named"; recursion yes; allow-query { internal; }; use-id-pool yes; // for BIND 8 only }; zone "albaheer.com" { type master; file "db.albaheer.com"; allow-transfer { slaves; }; allow-query { any; }; }; Log data transfers The BIND has the ability to log the data transfer for different reasons, such as monitoring and logging all activity to see how the world looks at yours name server. To log the data you can use the current system start-up scripts and only change the named file in /etc/named.conf. it is recommended to have a copy for the named file before making any change on it. The logging statement in the BIND is the way to define channels and categories as many as the administrator wants because the logging statement is used for just ones to multiple channels and categories such as: logging { category "default" { "debug"; }; category "client" { "debug"; }; }; It is recommended to add the logging statement as the first file, because it is applied here as soon as that statement is prevented. In addition, there are many different categories that help the administrator to choose whatever their system wants. These categories are defined in the BIND for example: update category which used for the Dynamic updates. those categories used for log the zone transfers are xfer-in which is us used to log the zone transfer in the server receiving, And also xfer-out category to log the zone transfers in the server sending, Conclusion The domain name server (DNS) is important to the internet world because of the benefit of translating the domain name from computer numbers to human words. On the other hand, there are plenty of vulnerabilities that could be very dangerous to the system via DNS services. According to an article in Info-Sec.com web site , http://www.info-sec.com/internet/99/internet_011199a_j.shtml (11/13/2000),"one in three organizations with an Internet presence is vulnerable to DNS Spoofing". Thus it is vital to use DNS software such as BIND to be up to date. Any attack could cause and effect you clients and customers when they tried to access the company website, and instead an attack redirected them to another website, and maybe even possibly redirected your emails to another server as well. Read More