I Think I Got Spoofed! How to Defend Against MiTM Attacks
What are we doing?
This labs consists of three exercises that teaches us how to utilize a controlled ARP and DNS spoof attack and how to defend against such MiTM attacks. We then create a new host domain and explore DNS server vulnerabilities before diving into the significance of phishing attacks and how to protect ourselves from such social engineering tactics.
Why would we want to do this?
It’s always best to test the security of our existing infrastructure in order to stay proactive with any vulnerabilities within our network. Simulating an ARP and DNS spoofing attack on our network helps us imitate a real-life cyber attack, but under a controlled environment where we can conduct a deep analysis of our network security, and still ensure the safety of our users and information.
Continuing to educate ourselves on protective measures against cyber attacks helps ensure our network security is met with success.
Who would use this?
Exercises 1 and 2 has a tendency to feel somewhat technical, and users who manage their own SOHO, as well as IT Professionals would find greater use with this material.
Exercise 3, on-the-other-hand, should be utilized by anybody using the internet, regardless the network and their skillset.
Thoughts?
Originally, this lab felt lacking when it came to preventive measures, even though one of the learning objectives was “defend against a man in the middle attack.”
So, I went ahead and added a Bonus section just after Exercise 1 that guides us through defending against MiTM attacks like ARP and DNS poisoning/spoofing. I hope people find it a useful and helpful add-on to this lab.
Note: Help us out and comment about anything else our readers might find helpful, when it comes to topics in this lab!
Vendor
Lab
1.8 — Common Network Vulnerabilities
Lab Learning Outcomes
- Exercise 1 — Spoofing a DNS Server
- Exercise 2 — Exploring DNS Server Vulnerabilities
- Exercise 3 — Safeguarding Against Phishing
After completing this lab, we will be able to:
- Perform ARP Poisoning using Ettercap
- Spoof a DNS Server using Ettercap
- Defend against a Man in the Middle Attack (MiTM) using Arpwatch, Wireshark, BIND, and CheckmyHTTPS
- Identify DNS server vulnerabilities by creating a new host domain and transferring the DNS zone using AXFR
- Use available tools to mitigate phishing such as SmartScreen Filter
CompTIA Network+ N10–007 Exam Objectives
N10–007 4.4 — Summarize common networking attacks — DoS:
- Phishing
- DNS poisoning
- Spoofing
- Man-in-the-middle
N10–007 5.2 — Given a scenario, use the appropriate tool (Command line, dig)
Exercise 1
Spoofing a DNS Server
In this exercise, we’ll be setting up a Windows server for IIS and conduct two MiTM cyber attacks: ARP poisoning, and DNS spoofing. We’ll use Ettercap as our penetration tool.
ARP poisoning is a man-in-the-middle (MiTM) attack that focuses on manipulating MAC addresses in order to penetrate networks, whereas DNS spoofing focuses on manipulating IP addresses.
Learning Objective
Utilize IIS and Apache as our web servers and use Ettercap as a penetration-testing-tool on our network to monitor and analyze a controlled DNS attack.
After completing this exercise, we’ll be able to:
- Setup a dedicated web server on our network using either IIS or Apache2
- Perform ARP Poisoning
- Spoof a DNS Server
Task 1 — Add IIS on a Device
First thing we need to do is set up our network to have a dedicated web server located within our LAN so that we can use it as our target when we conduct our DNS attack.
We have three servers to choose from:
- member server PLABDM01
- member server PLABSA01
- and our domain controller server PLABDC01
Since PLABDC01 is already our domain controller and administers the security policies within our network, we’re going to go ahead and elect PLABDC01 to be our dedicated web server so that we can later attack it.
In this task, we’ll enable the Windows web server service called IIS on our PLABDC01 device.
Internet Information Services server (IIS server) is a Windows Server-based web application used to deliver website content over the internet to an end user. IIS is an installable server role, and it’s bundled with all Microsoft Server products.²
There are two commonly used web server applications available:
- Apache
- IIS (Internet Information Services)
Apache is an open source installable application commonly used on open system platforms such as Linux, whereas IIS is a server role configured on top of a licensed copy of Windows Server. We’ll be using both applications for our exercise, but for now, we’ll focus on IIS.
Step 1: Connect to our PLABDC01 device.
The Server Manager Dashboard is displayed.
Click the Add roles and features link.
On the Before you begin page, click Next.
On the Select installation type page, click Next.
On the Select destination server page, click Next.
Step 2: On the Select server roles page, find the Web Server (IIS) option and click the checkbox.
On the Add features that are required for Web Server (IIS)? popup, click the Add Features button.
On the Select server roles page, click Next.
On the Select features page, click Next.
On the Web Server Role (IIS) page, click Next.
On the Select role services page, click Next.
Step 3: On the Confirm installation selections page, click Install.
Wait until the installation is complete and then click Close.
Task 1 Complete!
Now we know how to set up one of our Windows devices as a dedicated web server. Also, we now officially have a target for our controlled DNS attack!
Task 2 — Verify Name Resolution on the Network
With the IIS service active on our PLABDC01 device, the device now is a working web server.
In this task, we’ll verify that hostnames are resolvable (that our DNS server is working fine) and network connectivity between PLABDC01 and PLABWIN10 is functional.
We’re basically making sure our setup from Task 1 is working in our LAN
Step 1: Connect to our PLABWIN10 device and launch Internet Explorer from the taskbar.
We’re presented with the Tools and resource web page.
Step 2: Browse to http://plabdc01/
Make sure to use http and not https for this lab
Confirm that the default IIS page appears.
This verifies that domain names are being resolved and that PLABWIN10 is using PLABDC01 as our dedicated web server.
Close Internet Explorer.
Task 2 Complete!
Task 3 — Send Continuous Pings
In this task, we’ll determine the MAC address of our PLABDC01 device, and we’ll initiate a continuous ping to the device. This will be needed later in order for us to demonstrate ARP spoofing.
We’ll be spoofing the dedicated web server we set up and tested in Tasks 1 and 2 so that our weapon (our attacking device) can pretend to be that same web server. That way, when any device sends information to PLABDC01, they are in fact sending the information over to our weapon (attacking device) instead.
Step 1: On the PLABWIN10 device, open the Command Prompt Terminal, and input:
ping plabdc01 -t
A continuous ping to our PLABDC01 device is initiated.
Let the pinging continue uninterrupted.
Step 2: Right-click the Command Prompt icon on the taskbar.
Select the Command prompt option to open a second Command Prompt window on our PLABWIN10 device.
Step 3: On the second Command Prompt window, input the following:
arp -a
This displays the ARP cache for each interface on the device.
Look at the section with IP address 192.168.0.5 and find the entry for the 192.168.0.2 IP .
That’s our dedicated web server we setup in Task 1 — PLABDC01!
Write down the physical address displayed as we’ll reference it later on in this lab.
Close the second Command Prompt window, and keep the other prompt open (you can minimize it if you feel compelled)
Note: our values for the Physical Address may be different. The Physical Address is the MAC address of the device with specified IP address, which in this case is PLABDC01.
Task 3 Complete!
Perfect! We’ve setup our domain controller (PLABDC01) to also be our dedicated web server running IIS, confirmed other devices on the LAN can use our dedicated web server, and logged the physical (MAC) address to utilize later.
Now that our target is all primed and ready, let’s move on and setup our attacking device (our weapon). For this, let’s use one of our Linux devices and have it mimic our PLABDC01 Windows-based web server by spoofing the MAC address.
Task 4 — Verify Apache Server is running on the PLABRTR01 device
Our PLABRTR01 device is a server running Ubuntu, a version of Linux. Its primary function is to perform routing between networks, but in this lab, we’re going to use it as our weapon (our attacking device).
In this task, we’re going to verify that the Apache web server service is currently running on our PLABRTR01 device.
Note: Ubuntu comes with Apache already installed so there shouldn’t be any need to download the application.
Apache is an open-source and free web server software that acts as an alternative to Windows’s IIS and is primarily used on Linux devices. The official name is Apache HTTP Server, and it’s maintained and developed by the Apache Software Foundation.³ It allows website owners to serve content on the web — hence the name “web server.”
Although it isn’t too pertinent to the lab, I think it’s interesting to note that it’s also one of the oldest and most reliable web servers, going back since 1995⁴… pretty cool.
Step 1: On our PLABWIN10 device, open Internet Explorer
The Tools and Resources page appears.
Browse to http://plabrtr01/
Confirm that the Apache2 Ubuntu Default Page appears in the web browser.
Task 4 Complete!
We’ve verified that the PLABRTR01 device is reachable via a domain name and that the Apache web server is currently running. Perfect, now we know we can use PLABRTR01 (our weapon) to mimic PLABDC01 (our target)!
For another resource on setting up an Apache web server, follow along with NetworkChuck in this video (it’s DEFINITELY worth checking out and I already have it saved at the Apache section of the video):
EVERYONE needs to learn Linux⁵
Task 5 — Install Ettercap on the Attacking Device
In this task, we’ll install Ettercap⁶ to launch ARP poisoning on our network.
Ettercap is an extremely useful tool used for Man-In-The-Middle attacks and features services like sniffing live connections and immediate content filtering. Ettercap supports active and passive dissection of many protocols and includes many features for network and host analysis.⁶
To learn a little more about Ettercap’s features, take a look at this useful list:
Step 1: Connect to our PLABRTR01 device.
Note: In case the device does not startup or does not display the desktop, reset the device from the PracticeLabs app interface.
Click the Terminal icon at the left.
The Terminal window appears.
Step 2: In the Terminal window, input the following command:
sudo apt-get updateWhen prompted for a password, input the following and press Enter:
Passw0rdThis command searches and installs Linux updates on our system
Step 3: Wait until the installation is complete.
Once the command prompt returns, input the following command to install Ettercap:
sudo apt-get install ettercap-graphical
When asked if you want to continue, type y and press Enter.
Wait until the installation is complete. Once the command prompt returns, close the Terminal window.
Task 5 Complete!
Now we have Ettercap installed on our weapon (our attacking device) we’ll soon use on our target (PLABDC01)!
Task 6 — Manage ARP Poisoning using Ettercap
In this task, we’ll use our newly installed application, Ettercap, to launch ARP poisoning (ARP spoofing) on our network.
ARP Poisoning is a technique where an attacker sends spoofed Address Resolution Protocol (ARP) messages onto a local area network. Generally, the objective is to associate the attacker’s MAC address with the IP address of another host, such as the default gateway (router), causing any traffic meant for that IP address to be sent to the attacker’s computer instead.³
Remember, ARP poisoning may allow an attacker to intercept data frames on a network, modify the traffic, or stop all traffic. To really get a better understanding of ARP poisoning, watch NetworkChuck’s video:
how Hackers SNiFF (capture) network traffic // MiTM attack⁵
Watch the whole thing, seriously. It’s good, and we learn so much from it
Step 1: On our PLABDC01 device, click on the Show Applications icon at the bottom left.
A list of applications installed on our device appears.
Find the Ettercap icon and click it.
Note: Alternatively, we can search for Ettercap in the search field at the top.
When prompted type the following password and press Enter:
Passw0rd
Step 2: The Ettercap window appears. Click the Options menu and choose Set netmask.
The Netmask window appears.
In the Netmask field, type 255.255.255.0 and click OK.
Step 3: Click the Sniff menu and choose Unified Sniffing…
Verify that the interface “eth0 “ is selected and click OK.
We can see the sniffing operation begin and the packets sniffed will be listed at the bottom of the window.
Step 4: Click the Hosts menu and choose Scan for hosts.
The Ettercap dialog box briefly appears, scanning for hosts, just before closing.
Step 5: Once the scan is completed click Hosts menu and choose Hosts list
The Host List tab will show you a list of discovered hosts.
- 192.168.0.2 is the IP address of PLABDC01 (our target)
- 192.168.0.5 is the IP address of PLABWIN10
- 192.168.0.250 is the default gateway being used in this lab so we can access these Practice Labs devices.
Note: we may also see several IPv6 hosts as well. These are characterized by an IPv6 address beginning with fe80::
It is suggested that for the purposes of this lab, we remove them from the Host List by clicking each one and choosing Delete Host. Be careful not to delete any IPv4 hosts.
If we do, we must Scan for Hosts again
Step 6: On the Host List tab, select 192.168.0.2 and click Add to Target 1.
Observe the details pane below. It indicates that Host 192.168.0.2 added to TARGET1.
Step 7: Select 192.168.0.5 and click Add to Target 2.
Once again, observe the details pane and verify that host 192.168.0.5 has been added to TARGET2.
Step 8: Click the Mitm menu and select ARP poisoning.
On the MiTM Attack: ARP Poisoning dialog box, select Sniff remote connections checkbox then click OK to the displayed message.
Notice the lower pane of the Ettercap window. ARP Poisoning victims indicate the hosts that are being victimized.
Boom! We are officially conducting the first MiTM attack (ARP poisoning) on our target (PLABDC01)
But let’s not take my word for it. Let’s prove it too:
Step 9: Return to our PLABWIN10 device so we can take a look at our weapon hitting our target. Open the Command Prompt Terminal as Administrator
On the User Account Control dialog box, click Yes to continue.
Step 10: Open a new Command Prompt window and clear the DNS cache by typing the following:
ipconfig /flushdns
Step 11: On the next prompt, test connectivity to PLABRTR01:
ping 192.168.0.1
Perfect, zero packet loss; connection is good
Step 12: On next prompt, test connectivity to PLABDC01:
ping 192.168.0.2
Awesome! Zero packet loss — both connections look good.
This let us know that the device we’re currently using (PLABWIN10) to see our attacking device (PLABRTR01 — our weapon) mimic our target (PLABDC01) will indeed be able to see the two devices on its ARP table.
To verify the ARP cache, input at the next prompt:
arp -a
Take a look at PLABDC01’s Physical/MAC address (Internet Address 192.168.0.2).
Now, look back at the MAC address for PLABDC01 we wrote down from earlier:
Notice that the MAC address changed:
Before
After
Also, notice the Physical Address for 192.168.0.1 (PLABRTR01 — our attacking device) and 192.168.0.2 (PLABDC01 — our target) are now the same.
That means any packets that are supposed to go to PLABDC01 (like say requesting a webpage) will now be redirected to our attacking device, PLABRTR01, and our user requesting the webpage wouldn’t know any wiser.
This is the result of the on-going MiTM attack we generated using Ettercap from earlier.
For this lab, we’ll now go ahead and stop the attack since we’ve already confirmed our spoofed connection:
Step 13: Return to our PLABRTR01 device. The Ettercap window should be open.
Click on the Mitm menu and choose Stop mitm attack(s).
Please wait while the MiTM attack is being stopped.
Click OK when the MiTM attack(s) stopped message box appears.
Now that we’ve officially stopped our attack, let’s verify our ARP table isn’t spoofed and our PLABWIN10 device can still communicate with our dedicated web server PLABDC01:
Step 14: Switch to our PLABWIN10 device and on the Command Prompt window, input:
arp -aIn the Interface: 192.168.0.5 section, locate Internet Address 192.168.0.1 and 192.168.0.2.
Compare their Physical Addresses once again and notice they are no longer the same.
This confirms that we’ve officially stopped our MiTM attack (ARP poisoning).
Step 15: Finally, let’s verify PLABWIN10 can still connect to PLABDC01:
ping 192.168.0.2Notice that we get the usual four standard replies from PLABDC01, which indicates we can properly communicate with our web server.
Leave all devices powered on in their current state and proceed to the next task
Task 6 Complete!
Task 7 — Edit Ettercap Name Resolution Files
In this task, we’ll edit two text files, ettercap.conf and ettercap.dns, on our Ubuntu device (our weapon) to get started with our second MiTM attack — DNS spoofing. These two files are looked up by our attacking device to perform name resolution.
Step 1: Return to our PLABRTR01 device and click on the Terminal icon on the left. The Terminal window appears.
Type the following command to navigate to the /etc/ettercap folder and press Enter:
cd /etc/ettercap
Step 2: Type the following command to open the ettercap.conf file in the nano text editor and press Enter:
sudo nano etter.conf
When prompted type the following password:
Passw0rd
The file opens in the nano editor.
We navigate within the nano editor using the arrow keys on our keyboard in order to move the cursor. Text can be deleted using backspace and added simply by typing. For more information about how to use the nano text editor, check out Yatri Trivedi’s article:
The Beginner’s Guide to Nano, the Linux Command-Line Text Editor⁷
Step 3: Change the numerical values of ec_uid and ec_gid from 65534 to 0.
Step 4: Type Ctrl-X to exit.
We’re prompted to save changes. Type Y to save changes.
We’re prompted for the file name to write to.
Press Enter to accept the file name.
The nano text editor closes.
Step 5: We’re back on the command prompt.
In this step, we’ll edit another text file.
To do so, type the following command and press Enter:
sudo nano etter.dns
The etter.dns file is now open.
Step 6: Scroll down and access the #microsoft sucks section. Change the IP addresses matching to microsoft.com to:
173.194.34.147See the screenshot for our reference.
Step 7: Add #this is www.google.com comment in the first entry for microsoft.com.
Important: If we’re unable to type the # key, we’ll need to switch the language input settings on this device. On an Ubuntu device like this one, click the Applications icon in the lower left, then choose Language Support. On the popup, click Remind Me Later. Once on the Language Support page, we can drag the English (United States) option above the English (United Kingdom) option. Click Apply System Wide, then enter Passw0rd into the authentication prompt. Then return to the previous step to complete it.
Step 8: Type Ctrl-X to exit. We’re prompted to save changes. Type Y to save changes.
We’re prompted for the file name to write to.
Press Enter to accept the file name.
The nano text editor closes, and we’re navigated back to our command prompt.
Task 7 Complete!
So what we just did was have our attacking device spoof the microsoft.com DNS request to actually send users to google.com, instead. We basically hard-coded microsoft.com’s IP address to being google.com’s IP address (when someone wants to go onto micorsoft.com, they’ll be instead directed to google.com).
Task 8 — Activate DNS Spoofing Plug-in
Now let’s find out how to use Ettercap’s DNS spoofing plug-in and actually do a DNS attack on our network.
Step 1: Maximize the Ettercap window on our PLABRTR01 device.
Click the Plugins menu then choose Manage the plugins…
Double click on the dns_spoof plugin.
This will activate the dns_spoof plugin… Notice the star * added to the dns_spoof plugin and the indication of the activation of the plugin in the bottom pane.
Step 2: Switch to PLABWIN10. Right-click on the network icon in the system tray and choose Open Network & Internet settings.
Click the Network and Sharing Center link at the bottom.
On the Network and Sharing Center window, click the Internet Options link in the lower-left corner.
Internet Properties dialog box is displayed.
Step 3: On the General tab, click in Home page text box and type:
about:blank
Click OK.
Step 4: Close all the open windows.
Open Internet Explorer and browse to http://microsoft.com
Note: the webpage may open slowly or it may not open at all.
Note: Since the devices in this lab are working behind a proxy server and routers with security rules, we’re not going to see the actual DNS spoofing in action. Sad face :(
Ideally, in this lab, www.microsoft.com should be redirected to www.google.com.
Technically we just did a DNS spoof where we tricked users on our LAN to be redirected to google.com when they try to get onto microsoft.com. Cool Stuff!
Note:
If you’re still wondering why someone would want to conduct what seems to be a pretty harmless cyber-attack, then consider this scenario.
Instead of redirecting users to google.com when trying to get onto microsoft.com, imagine creating an exact replica of microsoft.com’s home page and have users be redirected to the replica site instead of the legitimate site.
They wont notice any difference and will go about trying to log onto there microsoft.com account, but instead of their credentials directing them onto their account, the username and password is now recorded and sent to the attacker without any notification of this happening. While the unbeknownst user continues to try and log on, the attacker can now go onto the legitimate microsoft.com web page and log onto that user’s account and do what ever they feel compelled to do.
Yeah, not such a harmless attack after all…
Close Internet Explorer.
Step 6: Return to our PLABRTR01 device.
On the Ettercap window displayed, double-click on a dns_spoof item to deactivate it.
We’re informed in the pane below that dns_spoof is being deactivated.
Step 7: Click Mitm on the top menu and choose Stop mitm attack(s).
Click OK when Mitm attack(s) is stopped.
Close the Ettercap and the Terminal windows.
Leave all devices powered on in their current state and proceed to the next exercise.
Exercise 1 Complete!
Bonus
Note: This goes beyond the Network+ Exam and will discuss topics catered more for Security+ and CEH, but I feel having a baseline knowledge of these prevention techniques will only cement the utility of what we’ve learned in this lab so far. This bonus section should also provide us with a more real-world application if one were to be on the defensive end of an attack.
So we learned how to set up a web server; we learned how to conduct ARP poisoning; we learned how to conduct DNS spoofing, but we never went into prevention methods when it comes to protecting ourselves to these (and other) MiTM attacks. That’s what this bonus section is for:
Note: most MiTM attacks will share the same preventative methods
Detecting and Preventing ARP poisoning
So here’s the thing with ARP poisoning/spoofing. Since it’s exclusive to OSI Layer 2 (Data-link), ARP poisoning can only happen within our network. Our attacker would not be able to utilize ARP poisoning if they were outside our local network.⁸ So the only way for someone to conduct ARP poisoning is to physically implant themselves into our systems (such injected software or hardware like a hiding laptop, raspberry pi, or USB-stick) — our attacker could not sniff packets unless they’ve done so.
Because of this, prevention methods will rely more on physically securing our devices and further educating ourselves on social engineering methods like phishing attacks.
First thing to do when monitoring our network and checking for any irregularities is to perform the command line prompt:
arp -aExamine each MAC address listed on the network. If any MAC address is listed twice on the table, ARP poisoning is most likely occurring on the network (there should never be duplicate MAC addresses — think of them like fingerprints)
We can also utilize Wireshark and check for any irregular packet requests. Zaid Sabih has a great example on how to do this:
How to Detect Suspicious Activity using Wireshark
Another way to detect ARP spoofing would be to automate an alert system that notifies us when a MAC address has been changed. This is usually the best method when it comes to ethernet connections and larger networks that need to take scaling into consideration.
Best way to go about doing this is using a Linux device and installing Arpwatch. Techmint has a quick and easy guide on how to setup Arpwatch and have it email us when an IP is trying to change its MAC address:
Arpwatch Tool to Monitor Ethernet Activity
Okay cool, we now know how to detect ARP poisoning. Now, how do we stop it?
Well, it depends.
Are we a small business or home with less than 12 devices like a SOHO network, or are we a larger business that utilizes hardware switches like Cisco Catalysts?
If our network is relatively small and has no intention of scaling (to increase in size), then assigning static ARP entries to each of our devices would most likely be the best defense against any ARP poisoning. Using static entries allows our system to ignore any IP information and prevents our ARP table from dynamically changing and utilizing duplicate MAC addresses. Here’s the code format we would use to assign each device a static ARP entry:
Linux: arp -s [ip-address] [mac-address]
Windows: arp /s [ip-address] [mac-address]
Note: Using static entries unfortunately only protect us from simple attacks, so it can’t be considered a full solution, since MAC Spoofing can still occur
For larger networks that need to take scaling into consideration, creating static ARP entries wouldn’t make much sense, though.
For larger networks, we would be best off using software that specializes in detecting ARP poisoning/spoofing such as Xarp, Arp monitor, or Arpwatch.
Note: If we need to use public WiFi, it is best to utilize a VPN to protect ourselves from broadcasting pertinent information on the network (Spoof attacks happen often on public WiFi)
Detecting and Preventing DNS spoofing/poisoning
When it comes to detecting DNS poisoning, detecting it usually means something bad has already happened and we’re just trying to put out the fire before it consumes too much. Because of this, detecting a DNS spoof could be rather complex. Instead, let’s focus on preventative measures:
First thing to do when securing our network from DNS attacks is to prevent our DNS server from answering on port 53. Port 53 is used for internet DNS queries and exposes our DNS server to the outside world. Another step would be to regularly clear the DNS cache and its users by entering certain commands in a Command Prompt:
For Windows
ipconfig /flshdns
#Enteripconfig /registerdns
#Enteripconfig /release
#Enteripconfig /renew
#Enternetsh winsock reset
#Enter
Note: We might even get away with only using the “ipconfig /flshdns” command
This alone won’t prevent a DNS attack, though, and many more things need to be done in order to ensure safety from a DNS attack. Take a look at this DNS prevention list provided by Jeff Thompson:
- Set up and maintain our own DNS servers. It’s really not that hard. even for a small network. BIND can be configured (securely and properly) in less than 30minutes. It’s MUCH better than the option of “hosted” DNS.
- Don’t answer DNS requests over the WAN on port 53 (or any other port for that matter)
- If we MUST answer on port 53, use RNDC keys. Revolve them often.
- Set our TTL’s to a low value. I like 15 minutes. Something that doesn’t sacrifice our network performance. This way, if a cache poison DOES hit us, it’s only going to be a “problem” for a short duration of time
- DISABLE ‘HOSTS’ FILE RESOLUTION ON OUR CLIENTS AND SERVERS!!!
- Create and properly maintain our PTR zones. Even for local domains It’s tedious, and boring, but VERY important. Especially for SMTP traffic.
- Consider using STUB zones for commonly accessed domains, or domains that could easily be compromised.
- Use DNS forwarders ONLY to verified DNS servers. Too many people simply forward to the ‘Root Servers’ and this is not ideal. Many of them don’t answer, and with a localized routing table attack, we can end up creating our own poisoned cache. Just don’t do it. Talk to our ISP and use their servers. Also, spot-check them frequently using ‘dig’.
- Block DHCP on our firewall except from our one and only DHCP server on our network. If a “rogue” DHCP server is allowed to permeate on our network, we lose *all* control of our DNS and DHCP security. Not to mention, tracking down a “rogue” DHCP server is time consuming and frustrating.
- Continue to learn how DNS works. Once we do, we can see how some of the inherit flaws can be ‘stopped’ within our own network structure.
- Cluster our DNS resources. Shorter TTL’s will increase our database I/O but not so much that many of our users will notice. We should do our own testing. We’ll likely be a bit surprised that having more ‘close to real-time’ results doesn’t really impact our latency or I/O on our DNS infrastructure.⁹
Other methods to use when preventing MiTM attacks:
- We should patch our system and use renowned anti-malware software.
- Don’t use public networks and/or hotspots for any sensitive activities.
- When connecting to our WiFi, check if we’re connecting to a network with a name similar to our actual WiFi (We might accidentally try to connect to “Lynksys373353-Fa” instead of “Lynksys353373-Fa”).
- Don’t forget to check the browser address bar and make sure we’re using a secure connection.
- Click the lock symbol next to the address bar to get more information about the certificate.
- Install add-ons that help us detect SSL hijacking, for example, CheckMyHTTPS.
- Never send any sensitive information via email and do not trust any emails with sensitive information.
- Set up two-factor authentication wherever we can. Even if an attacker intercepts our data, they will have a hard time getting control of our Android or iPhone as well.¹⁰
Bonus Complete!
Now we know how to detect, and possibly even prevent and stop a MiTM attack from happening on our network!
Exercise 2 — Exploring DNS Server Vulnerabilities
DNS (Domain Name System) is like a translator for us users. When we want to go on a website, we input what’s called a human-readable hostname, like “medium.com.” Our DNS will then translate “medium.com” to a machine-readable hostname (its IP address) “162.159.153.4” so that our computer can actually understand where we want to go.
DNS servers host zones. A DNS zone is a portion of the domain name space that is served by a DNS server. For example, medium.com with all its subdomains may be a zone. However, mail.medium.com may also be a separate zone.¹¹ DNS zone transfers are needed because if our zones are large, they may need to frequently change, and doing this manually severely increases the risk of making mistakes and would quite frankly be time-consuming.
We can use different mechanisms for DNS zone transfer but the simplest one is AXFR. It’s a client-initiated request, therefore, we can edit information on the primary DNS server and then use AXFR from the secondary DNS server to download the entire zone.¹¹
In this exercise, we’ll add some records to the PLABDC01 DNS in order to test how zone transfer works.
We’ll use a Linux tool called dig to initiate a zone transfer with a Windows DNS server. The Linux command dig is useful if we would like to determine the domain name of a specific IP address that exists on the internet without using a web browser.
Learning Objective:
To understand why we need more than one DNS Server and why it can cause our network to be vulnerable
After completing this exercise, we’ll be able to:
- Create a new host on an existing domain and set that new host on our DNS server to request mail records.
- Transfer the new host/zone to another device using AXFR and use safer modes of transfer using BIND
Task 1 — Add DNS Resource Records
In this task, we’ll add some DNS resource records and perform a zone transfer from our PLABRTR01 Linux device to PLABDC01.
Step 1: Connect to our PLABDC01 device and open the Windows Administrative Tools folder.
Select DNS.
The DNS Manager is displayed.
Step 2: On the navigation pane at the left, expand PLABDC01 > Forward Lookup Zones > PRACTICELABS.COM.
To add a host record, right-click in the details pane and select New Host (A or AAAA).
The New Host dialog box is displayed.
Step 3: In the “Name” box, type:
mailIn the “IP address” box, type
192.168.0.5Click Add Host.
DNS dialog box is displayed confirming successful creation of the host record.
Click OK.
Step 4: Back on the New Host dialogue box, click Done.
To add another host record, right-click in the details pane window and select New Mail Exchanger (MX)
New Resource Record dialog box is displayed.
Step 5: In the Fully qualified domain name text box, type
mail.practicelabs.comclick OK.
Keep the DNS Manager open.
Step 6: Switch to our PLABRTR01 device.
Open a Terminal window and input the following command:
dig @192.168.0.2 practicelabs.com mx
This sets the name server to the DNS server running on PLABDC01 and requests mail records for the practicelabs.com domain. The server should respond to the query with the requested information.
Perfect! Now that we’ve created a new host on practicelabs.com called mail.practicelabs.com and set the new host on our DNS server to request mail records for practicelabs.com let’s now transfer our new host to a different zone
Step 7: Execute the following command, which attempts to perform a full zone transfer from PLABDC01 to PLABRTR01.
dig @192.168.0.2 practicelabs.com axfrNote: AXFR means full zone transfer.
Note: This query will fail, as zone transfers are not permitted by default by the PLABDC01 server.
Step 8: Return to our PLABDC01 device.
Go to the DNS Manager, right-click the PRACTICELABS.COM zone and select Properties.
PRACTICELABS.COM Properties dialog box is displayed.
Step 9: Access the Zone Transfers tab. Select the Allow zone transfers box and click OK.
Step 10: Return to PLABRTR01 device and repeat the zone transfer command. Input:
dig @192.168.0.2 practicelabs.com axfrThe transfer should be successful this time. Notice the screen output generated by the full zone transfer.
Step 11: Return to our PLABDC01 device again, click the Type here to search icon and begin typing Event Viewer. Once the Event Viewer app appears, click it.
On the Event Viewer console displayed, navigate to Event Viewer (Local) > Applications and Services Logs and click on DNS Server.
The DNS Server events are listed on the middle pane.
Right-click Event ID 6001 and select Event Properties.
Note that the zone transfer has been logged.
This verifies that our new host record mail.practicelabs.com has been fully transferred to our new device PLABRTR01.
Click Close.
Close the Event Viewer and the DNS Manager.
So…
Here’s the thing about what we just did. AXFR has zero encryption and zero authentication, so any client can ask a DNS server for information on the entire zone — they would basically have a list of every host on that domain, giving them information they can easily utilize for an attack.
And although in Step 7 of this exercise we mention under one of the notes that our Windows server by default does not allow zone transfers, we oftentimes need to allow zone transfers in order to have more than one DNS server and not have a SPOF (single point of failure) within our network.
So, how do we keep zone transfers more secure? One way is to ensure that the DNS server only uses trusted IP addresses and to use Transaction Signatures (TSIG) for zone transfers using BIND. Here’s a handy guide on installing and utilizing BIND for safer DNS zone transfers:
Secure Zone transfer in BIND using TSIG(Transaction Signatures)
Exercise 2 Complete!
Now we know how to create a DNS record, allow access to DNS zone transfers, transfer a DNS zone to another device, and know how to keep our DNS zone transfers more secure!
Keep all devices powered on in their current state and proceed to the next exercise.
Exercise 3 — Safeguarding Against Phishing
Phishing attacks are a very common form of social engineering. In a Phishing attack, the attacker impersonates a trusted unit, and thereby is able to fool a user to divulge personal information including passwords, credit card details, or even bank details.¹
Like we mentioned before, social engineering methods, like phishing, are very effective methods at penetrating a local network. Remember, in order for an attacker to perform most MiTM attacks, he/she would need to physically implant themselves onto the local network either through software or hardware. Since it can be rather difficult to inject hardware onto a local network, attackers utilize phishing methods in order to remotely access the network and inject software needed to keep them connected.
Because of the very nature of social engineering, safeguarding against phishing can be rather difficult for larger organizations since it’s almost entirely dependent on the users’ common knowledge and experience of such attacks. Often times, phishing occurs through communication, whether it be an email, a phone call, or a text message.
Consider the FTC’s guide on avoiding phishing scams as an excellent resource for us fellow coworkers:
How to Recognize and Avoid Phishing Scams¹²
In this exercise, we’ll learn to configure Internet Explorer’s built-in anti-phishing function called SmartScreen Filter. Other options for anti-phishing software platforms are listed here:
Top 9 anti-phishing tools and services
But remember, no software or defense system can protect our network from a user accidentally giving away important information (like their username and password).
Learning Objective:
After completing this exercise, we’ll be able to:
- Turn on SmartScreen Filter on Internet Explorer
- Expand our knowledge on phishing attack methods being used by attackers
Task 1 — Turn on the SmartScreen Filter
A SmartScreen Filter warns us if the website we’re visiting is a potential phishing threat to our system. You can turn on the SmartScreen Filter for a browser by accessing a browser configuration. In this task, we’ll turn on the SmartScreen Filter on the Internet Explorer browser on the PLABWIN10 device.
Step 1: Connect to our PLABWIN10 device and open Internet Explorer
Step 2: On the browser window, access the menu bar at the top.
Click the Configuration icon, select the Safety > Turn on Windows Defender SmartScreen…
The Microsoft Windows Defender SmartScreen dialog box appears.
Read what this feature was designed to do and verify that it is turned on.
Click OK.
Task 1 Complete!
Now we know how to turn on the SmartScreen Filter on Internet Explorer! Let’s see if it works in Task 2.
Task 2 — Verify the Phishing Filter is Working
Once the SmartScreen Filter is activated, it should block any potential phishing websites that the browser might try to access. In this task, we’ll try to access one such website listed on http://www.phishtank.com and watch the browser response on our PLABWIN10 device.
Note: Various databases are available that list of websites that indulge in phishing. Examples of such databases include http://www.phishtank.com, http://www.phishbank.com, and many more.
Let’s find out if the phishing filter activated on the browser is working:
Step 1: Connect to PLABWIN10 and access http://www.phishtank.com
Highlight any of the listed websites, right-click and select Copy.
Note: This website is dynamically updated and will have different results than what’s pictured
Step 2: Open a new tab on the web browser.
Paste the copied website name in the address bar and press Enter.
Note the message from the activated filter flagging the website as a potential threat.
We might also sometimes get a message that the webpage is blocked.
It is important to understand that the maintenance of an updated list of dangerous and malicious sites is a dynamic process. There may be sites that have been identified as phishing sites by databases such as www.phishtank.com.
However, these sites might not be classified as potential threats by Microsoft’s listing, yet. For this reason, we may find that some or even many of the sites we test will not be blocked by the filter. In order to get the results shown here, we may need to test several sites.
We may find that some of the sites in the phishing list may be blocked by the proxy server of the Practice Labs topology and we may get an error message stating something like “Web Page Blocked.” Try several different sites in the list until we get a result similar to that in the screenshot.
Exercise 3 Complete!
Phishing attacks can come out of nowhere and even fool some of the brightest IT Professionals, so it’s always important to update our knowledge on how attackers are using these phishing methods and how to defend ourselves against them. Take a look at this handy article to expand our knowledge on this subject:
[1]: Lab 1.8 Common Network Vulnerabilities
[2]: What is an IIS Server?
[3]: Apache Software Foundation
[4]: What is Apache? An In-Depth Overview of Apache Web Server
[5]: NetworkChuck
[6]: Ettercap
[7]: The Beginner’s Guide to Nano
[8]: Use Wireshark to Detect ARP Spoofing
[9]: How to prevent DNS poisoning and DNS spoofing
[10]: Man in The Middle Attacks
[11]: DNS zone transfers
[12]: How to Recognize and Avoid Phishing Scams
