old notes

cname

#networking #dns #nslookup #dig #cname #aircrackng #UofTBootcamp

Follow-Up Questions from Homework9

Q2 – does it matter that we are getting non-authoritative answers from a recursive resolver (8.8.8.8) vs getting an authoritative one? – what is the difference between using this: nslookup -type=cname www.theforce.net And getting: Non-authoritative answer: www.theforce.net canonical name = theforce.net.

VS.

nslookup -type=cname theforce.net and getting: Non-authoritative answer: *** Can't find theforce.net: No answer

Authoritative answers can be found from: theforce.net origin = WebPublish_Othe mail addr = hostmaster serial = 2017110901 refresh = 900 retry = 600 expire = 86400 minimum = 3600

https://stackoverflow.com/questions/66014432/how-to-find-the-canonical-name-with-nslookup

Q3: – what does NX DOMAIN tell us for sure? https://bluecatnetworks.com/blog/what-you-can-learn-from-an-nxdomain-response/ – follow-up on conclusion


Networking Fundamentals: Homework 9

Your task is a crucial one: Restore the Resistance's core DNS infrastructure and verify that traffic is routing as expected.

Mission 1:

Network Issue:

The Resistence has taken down their primary DNS and email servers in order to a build and deply a new DNS and mail server but they are not currently receiving emails because they have no configured MX Records for the new email servers.

DNS record type found:

We want to check the MX records (mail exchanger records) which specify which mail servers can accept email that's sent to our domain with: starwars.com: nslookup -type=mx starwars.com

DNS records that can explain the reasons for existing network issue:

According to our nslookup results, the new mail servers are not listed. The primary mail server for starwars.com should be asltx.l.google.com and the secondary email should be asltx.2.google.com.

`Server: 192.168.2.1 Address: 192.168.2.1#53

Non-authoritative answer: starwars.com mail exchanger = 5 alt2.aspmx.l.google.com. starwars.com mail exchanger = 1 aspmx.l.google.com. starwars.com mail exchanger = 10 aspmx2.googlemail.com. starwars.com mail exchanger = 10 aspmx3.googlemail.com. starwars.com mail exchanger = 5 alt1.aspx.l.google.com.`

Instead, the primary server (indicated by the numeric value of 1 before the server address) is: aspmx.l.google.com. The secondary server is either: aspmx.l.google.com. or alt1.aspx.l.google.com. as both addresses have the next priority value of 5.

It's likely that these are the old servers and someone has forgotten to change the MX record configuration to the new servers at: asltx.l.google.com and asltx.2.google.com.

Recommended fixes to save the Galaxy!

The corrected MX record should be:

starwars.com mail exchanger = 1 asltx.l.google.com starwars.com mail exhanger = 2 asltx.2.google.com

Mission 2:

Network Issue:

Official emails are going into spam or being blocked because the SPF record has not been updated to reflect the new IP address of their mail server. Since the SPF record is used to indicate which mail servers are allowed to send emails on behalf of a domain, emails from the IP address of the new mail server (missing from the current SPF record) is likely to be filtered out as spam.

DNS record type found:

Looking up the SPF (Sender Policy Framework) record using nslookup -type=txt theforce.net | grep spf to find the following SPF record::

theforce.net text = "v=spf1 a mx mx:smtp.secureserver.net include:aspmx.googlemail.com ip4:104.156.250.80 ip4:45.63.15.159 ip4:45.63.4.215"

Alternatively, we can also use the dig DNS lookup utility: dig theforce.net txt | grep spf which confirms the same SPF record:

theforce.net. 3498 IN TXT "v=spf1 a mx mx:smtp.secureserver.net include:aspmx.googlemail.com ip4:104.156.250.80 ip4:45.63.15.159 ip4:45.63.4.215"

DNS records that can explain the reasons for existing network issues:

The servers currently configured to be allowed to send emails for the domain are from the following IPv4 hosts: 104.156.250.80, 45.63.15.159, and 45.63.4.215. The new one (45.23.176.21) has not beed added. It is likely that similar to Mission 1, someone has forgotten to update changes made while the network was down.

Recommended fixes to save the Galaxy!

We have not been given data regarding the other mail server IP addresses — if we assume that those are still correct and do not need to removed, we only need to add the missing IP so that the corrected record should be:

theforce.net. 3498 IN TXT "v=spf1 a mx mx:smtp.secureserver.net include:aspmx.googlemail.com ip4:104.156.250.80 ip4:45.63.15.159 ip4:45.63.4.215 ip4:45.23.176.21

Mission 3:

Network Issue:

DNS record type found:

We need to check the CNAME record of the resistance.theforce.net domain in order to see why it is not redirecting to theforce.net. A CNAME record is used to point one domain to another so if we want the resistance.theforce.net subdomain to point to theforce.net, we need to have the CNAME configured to do so.

DNS records that can explain the reasons for existing network issues:

Looking up the CNAME (Canonical Name) of www.theforce.net with nslookup in interactive mode in order to examine a correct CNAME configuration where www.theforce.net will be redirected to theforce.net:

nslookup to enter into interactive mode

> set query=CNAME to set the query type to CNAME > www.theforce.net to set the domain to query

This gives the following (relevant) output:

www.theforce.net canonical name = theforce.net.

Alternatively, we can also use single line command nslookup -type=CNAME www.theforce.net or dig www.theforce.net | grep CNAME if we like to confirm things in multiple ways before moving forward:

www.theforce.net. 2321 IN CNAME theforce.net. is the output from dig indicating the correct configuration.

Looking up why our resistance.theforce.net is not redirecting to theforce.net:

Using nslookup -type=CNAME resistance.theforce.net we get:** server can't find resistance.theforce.net: NXDOMAIN which is an error message indicating the DNS query failed because the domain name queried (resistance.theforce.net does not exist or that the query could not “know” that it exists.

This could mean (if we assume we have not made a user error in our query, i.e. mistyping the address): – the domain is currently offline or is having server issues – a security control blocking the domain – domain could be compromised or that malware exists

To follow-up, we can first check if the domain is offline using https://isitup.org/resistance.theforce.net which indicates that the domain is down. This makes sense because we are supposed to be redirecting resistance.theforce.net to the CNAME domain theforce.net so the subdomain should not exist on its own.

Recommended fixes to save the Galaxy!

To fix this, we need to correct the CNAME record configuration to have this line:

resistance.theforce.net canonical name = theforce.net.

Mission 4

Network Issue: DNS record type found: DNS records that can explain the reasons for existing network issues: Recommended fixes to save the Galaxy!

Mission 5:

Network Issue:

Slow network traffic from the planet of Batuu to Jedha due to an attack on Planet N.

The routing protocol in use is OSPF Open Shortest Path First.

Recommended fixes to save the Galaxy!

The new path to use is:

Mission 6:

Your Mission:

  • Figure out the Dark Side's secret wireless key by using Aircrack-ng.

Results from running Aircrack-ng with the password list downloaded from: https://github.com/danielmiessler/SecLists/blob/master/Passwords/WiFi-WPA/probable-v2-wpa-top4800.txt

`[00:00:00] 3432/4800 keys tested (10349.88 k/s)

Time left: 0 seconds 71.67%

KEY FOUND! [ dictionary ]

Master Key : B3 52 50 D0 9F 8E AB BD 0D 9E 3D D3 A3 62 12 82 9E FA 89 FC 19 1D A4 4A 3E 7A 40 9C D4 DF 68 DC

Transient Key : DF 26 D4 B0 47 58 E5 AB 33 66 35 14 87 70 7E 46 9E 93 3F 48 3A AE BE F5 0A 58 81 82 B1 59 56 A4 05 C4 04 F4 F0 E2 27 45 49 3D 51 9C A0 E0 AA 83 5F 63 D5 35 A5 56 52 24 35 70 31 08 BE 99 F6 15

EAPOL HMAC : 3E B9 D6 B8 63 69 A7 8B 83 EA 2A 3A 71 ED CF 59`

The password is: dictionary. We use this password to decrypt the WPA traffic via Wireshark.

  • Once you have decrypted the traffic, figure out the following Dark Side information:

    • Host IP Addresses and MAC Addresses by looking at the decrypted ARP traffic.

Host: Sender MAC address: IntelCor_55:98:ef (00:13:ce:55:98:ef) Sender IP address: 172.16.0.101 (172.16.0.101)

Looking for: Sender MAC address: Cisco-Li_e3:e4:01 (00:0f:66:e3:e4:01) Sender IP address: 172.16.0.1 (172.16.0.1)

Mission 7:

Viewing the DNS record from Mission #4, specifically looking for a hidden message in the TXT record:

nslookup -type=txt princessleia.site to find this message:

princessleia.site text = "Run the following in a command line: telnet towel.blinkenlights.nl or as a backup access in a browser: www.asciimation.co.nz"

Take a screen shot of the results:

Note: This was the coolest last homework question ever! And thank you for reading.