This was a hard article to figure out the title for! Put simply, your mac book has a route table and if you want to move a specific IP address or dns from one interface to another, then follow the steps below:
First find the IP address of the website that you want to re-route the traffic for:
We want to re-route traffic the traffic from: 102.132.99.60 to the default interface. So first lets find out which interface this traffic is currently being routed to?
So this is currently going to a tunnelled interface called utun0 on gateway 100.64.0.1.
Ok, so I want to move if off this tunnelled interface. So lets first display the kernel routing table. The -n option forces netstat to print the IP addresses. Without this option, netstat attempts to display the host names.
$ netstat - rn | head -n 5
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 126 100.64.0.1.64770 136.226.216.14.https ESTABLISHED
tcp4 0 0 100.64.0.1.64768 whatsapp-cdn-shv.https ESTABLISHED
tcp4 0 0 100.64.0.1.64766 52.178.17.3.https ESTABLISHED
Now we want to re-route whatsapp to the default interface. So lets get the IP address of the default interface.
We can see that our en0 interface is on IP address: 192.168.8.1. So lets re-route the traffic from Whatsapp’s ip address to this interace’s IP address:
Each day that I wake up I try and figure out if I can do less work than yesterday. With this in mind I was playing around to see if there is a way to save me typing my password each time I SUDO. It turns out this is quite a simple change…
Open Terminal and run the following to edit sudos behaviour:
sudo nano /etc/pam.d/sudo
Next add the following to the top of the file:
auth sufficient pam_tid.so
The only issue with this is that /etc/pam.d/sudo is overwritten on every macOS update (major, minor or patch – it is always overwritten and reset back to its default state).
Touch ID can be allowed for sudo with a configuration that persists across software updates using /etc/pam.d/sudo_local. See /etc/pam.d/sudo_local.template for details.
So lets create a template file in /etc/pam.d/sudo_local.template:
sudo nano /etc/pam.d/sudo_local.template
Next uncomment the auth line, as per:
# sudo_local: local config file which survives system update and is included fo$
# uncomment following line to enable Touch ID for sudo
auth sufficient pam_tid.so
This should mean that Touch ID now survive system updates!
Quick tests:
sudo ls
# exit sudo
sudo -k
sudo ls
To enable Touch ID access on Iterm2. You need to do the following. Go to Prefs -> Advanced -> Allow sessions to survive logging out and back in and set value to no . Restart Iterm2 and touch ID authentication will work on Iterm2.
There are a few things that I tweak when I get a new Macbook, one of which is the screenshot format (mainly because it doesnt natively render in Whatsapp). So I thought I would share the code snippet that you can run in Terminal to alter the default image type of your screenshots:
If you have multiple connections on your device (and maybe you have a zero trust client installed); how do you find out which network interface on your device will be used to route the traffic?
Below is a route get request for googles DNS service:
If you have multiple interfaces enabled, then the first item in the Service Order will be used. If you want to see the default interface for your device:
$ route -n get 0.0.0.0 | grep interface
interface: en0
Lets go an see whats going on in my default interface:
$ netstat utun3 | grep ESTABLISHED
tcp4 0 0 100.64.0.1.65271 jnb02s11-in-f4.1.https ESTABLISHED
tcp4 0 0 100.64.0.1.65269 jnb02s02-in-f14..https ESTABLISHED
tcp4 0 0 100.64.0.1.65262 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65261 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65260 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65259 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65258 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65257 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65256 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65255 192.0.73.2.https ESTABLISHED
tcp4 0 0 100.64.0.1.65254 192.0.78.23.https ESTABLISHED
tcp4 0 0 100.64.0.1.65253 192.0.76.3.https ESTABLISHED
tcp4 0 0 100.64.0.1.65252 192.0.78.23.https ESTABLISHED
tcp4 0 0 100.64.0.1.65251 192.0.76.3.https ESTABLISHED
tcp4 0 0 100.64.0.1.65250 192.0.78.23.https ESTABLISHED
tcp4 0 0 100.64.0.1.65249 192.0.76.3.https ESTABLISHED
tcp4 0 0 100.64.0.1.65248 ec2-13-244-140-3.https ESTABLISHED
tcp4 0 0 100.64.0.1.65247 192.0.73.2.https ESTABLISHED
If you have just changed ISPs or moved house and your internet suddenly starts misbehaving the likelihood is your Maximum Transmission Unit (MTU) is set too high for your ISP. The default internet facing MTU is 1500 bytes, BUT depending on your setup, this often needs to be set much lower.
Step 1:
First check your current MTU across all your ipv4 interfaces using netsh:
netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 0 Loopback Pseudo-Interface 1
1492 1 675 523 Local Area Connection
As you can see, the Local Area Connection interface is set to a 1492 bytes MTU. So how do we find out what it should be? We are going to send a fixed size Echo packet out, and tell the network not to fragment this packet. If somewhere along the line this packet is too big then this request will fail.
Next enter (if it fails then you know your MTU is too high):
ping 8.8.8.8 -f -l 1492
Procedure to find optimal MTU:
For PPPoE, your Max MTU should be no more than 1492 to allow space for the 8 byte PPPoE “wrapper”. 1492 + 8 = 1500. The ping test we will be doing does not include the IP/ICMP header of 28 bytes. 1500 – 28 = 1472. Include the 8 byte PPPoE wrapper if your ISP uses PPPoE and you get 1500 – 28 – 8 = 1464.
The best value for MTU is that value just before your packets get fragmented. Add 28 to the largest packet size that does not result in fragmenting the packets (since the ping command specifies the ping packet size, not including the IP/ICMP header of 28 bytes), and this is your Max MTU setting.
The below is an automated ping sweep, that tests various packet sizes until it fails (increasing in 10 bytes per iteration):
C:\Windows\system32>for /l %i in (1360,10,1500) do @ping -n 1 -w 8.8.8.8 -l %i -f
Pinging 8.8.8.8. with 1400 bytes of data:
Reply from 8.8.8.8: bytes=1400 time=6ms TTL=64
Ping statistics for 8.8.8.8:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 6ms, Average = 6ms
Pinging 8.8.8.8 with 1401 bytes of data:
Reply from 8.8.8.8: bytes=1401 time<1ms TTL=64
Ping statistics for 8.8.8.8:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Pinging 8.8.8.8 with 1402 bytes of data:
Reply from 8.8.8.8: bytes=1402 time<1ms TTL=64
Ping statistics for 8.8.8.8:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Pinging 8.8.8.8 with 1403 bytes of data:
Reply from 8.8.8.8: bytes=1403 time<1ms TTL=64
Ping statistics for 8.8.8.8:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Once you find the MTU, you can set it as per below:
set subinterface “Local Area Connection” mtu=1360 store=persistent
If you have just changed ISPs or moved house and your internet suddenly starts misbehaving the likelihood is your Maximum Transmission Unit (MTU) is set too high for your ISP. The default internet facing MTU is 1500 bytes, BUT depending on your setup, this often needs to be set much lower.
Step 1:
First check your current MTU.
$ networksetup -getMTU en0
Active MTU: 1500 (Current Setting: 1500)
As you can see, the Mac is set to 1500 bytes MTU. So how do we find out what it should be? We are going to send a fixed size Echo packet out, and tell the network not to fragment this packet. If somewhere along the line this packet is too big then this request will fail.
Next enter:
$ ping -D -s 1500 www.google.com
PING www.google.com (172.217.170.100): 1500 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
Request timeout for icmp_seq 0
ping: sendto: Message too long
Request timeout for icmp_seq 1
ping: sendto: Message too long
Ok, so our MTU is too high.
Procedure to find optimal MTU:
Hint: For PPPoE, your Max MTU should be no more than 1492 to allow space for the 8 byte PPPoE “wrapper”. 1492 + 8 = 1500. The ping test we will be doing does not include the IP/ICMP header of 28 bytes. 1500 – 28 = 1472. Include the 8 byte PPPoE wrapper if your ISP uses PPPoE and you get 1500 – 28 – 8 = 1464.
The best value for MTU is that value just before your packets get fragmented. Add 28 to the largest packet size that does not result in fragmenting the packets (since the ping command specifies the ping packet size, not including the IP/ICMP header of 28 bytes), and this is your Max MTU setting.
The below is an automated ping sweep, that tests various packet sizes until it fails (increasing in 10 bytes per iteration):
$ ping -g 1300 -G 1600 -h 10 -D www.google.com
PING www.google.com (172.217.170.100): (1300 ... 1600) data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
ping: sendto: Message too long
Request timeout for icmp_seq 7
As you can see it failed on the 7th attempt (giving you a 1300 + 60 MTU).
Once you find the MTU, you can set it as per below:
$ ping -D -s 1360 www.google.com
PING www.google.com (172.217.170.100): 1370 data bytes
Request timeout for icmp_seq 0
I frequently forget this command shortcut, so this post is simply because I am lazy. To clear your history in iTerm press Command + K. Control + L only clears the screen, so as soon as you run the next command you will see the scroll back again.
If you want to view your command history (for terminal) type:
$ ls -a ~ | grep hist
.zsh_history
$ cat .zsh_history
There are three basic ways to secure email, these are: Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), Domain-based Message Authentication, Reporting & Conformance (DMARC) definitions. Lets quickly discuss these before we talk about how to check if they have been setup:
SPF helps prevent spoofing by verifying the sender’s IP address
SPF (Sender Policy Framework) is a DNS record containing information about servers allowed to send emails from a specific domain (eg which servers can send emails from andrewbaker.ninja).
With it, you can verify that messages coming from your domain are sent by mail servers and IP addresses authorized by you. This might be your email servers or servers of another company you use for your email sending. If SPF isn’t set, scammers can take advantage of it and send fake messages that look like they come from you.
It’s important to remember that there can be only one SPF record for one domain. Within one SPF record, however, there can be several servers and IP addresses mentioned (for instance, if emails are sent from several mailing platforms).
DKIM shows that the email hasn’t been tampered with
DKIM (DomainKeys Identified Mail) adds a digital signature to the header of your email message, which the receiving email servers then check to ensure that the email content hasn’t changed. Like SPF, a DKIM record exists in the DNS.
DMARC provides reporting visibility on the prior controls
DMARC (Domain-based Message Authentication, Reporting & Conformance) defines how the recipient’s mail server should process incoming emails if they don’t pass the authentication check (either SPF, DKIM, or both).
Basically, if there’s a DKIM signature, and the sending server is found in the SPF records, the email is sent to the recipient’s inbox.
If the message fails authentication, it’s processed according to the selected DMARC policy: none, reject, or quarantine.
Under the “none” policy, the receiving server doesn’t take any action if your emails fail authentication. It doesn’t impact your deliverability. But it also doesn’t protect you from scammers, so we don’t recommend setting it. Only by introducing stricter policies can you block them in the very beginning and let the world know you care about your customers and brand.
Here, messages that come from your domain but don’t pass the DMARC check go to “quarantine.” In such a case, the provider is advised to send your email to the spam folder.
Under the “reject” policy, the receiving server rejects all messages that don’t pass email authentication. This means such emails won’t reach an addressee and will result in a bounce.
The “reject” option is the most effective, but it’s better to choose it only if you are sure that everything is configured correctly.
Now that we’ve clarified all the terms, let’s see how you can check if you have an existing SPF record, DKIM record, and DMARC policy set in place.
The “v=spf1” part shows that the record is of SPF type (version 1).
The “include” part lists servers allowed to send emails for the domain.
The “~all” part indicates that if any part of the sent message doesn’t match the record, the recipient server will likely decline it.
2. Next Lets Check if DKIM is setup
What is a DKIM record?
A DKIM record stores the DKIM public key — a randomized string of characters that is used to verify anything signed with the private key. Email servers query the domain’s DNS records to see the DKIM record and view the public key.
A DKIM record is really a DNS TXT (“text”) record. TXT records can be used to store any text that a domain administrator wants to associate with their domain. DKIM is one of many uses for this type of DNS record. (In some cases, domains have stored their DKIM records as CNAME records that point to the key instead; however, the official RFC requires these records to be TXT.)
Unlike most DNS TXT records, DKIM records are stored under a specialized name, not just the name of the domain. DKIM record names follow this format:
[selector]._domainkey.[domain]
The selector is a specialized value issued by the email service provider used by the domain. It is included in the DKIM header to enable an email server to perform the required DKIM lookup in the DNS. The domain is the email domain name. ._domainkey. is included in all DKIM record names.
If you want to find the value of the selector, you can view this by selecting “Show Original” when you have the email open in gmail:
Once you are able to view the original email, perform a text search for “DKIM-Signature”. This DKIM-Signature contains an attribute ‘s=’, this is the DKIM selector being used for this domain. In the example below (an amazon email), we can see the DKIM selector is “jvxsykglqiaiibkijmhy37vqxh4mzqr6”.
To look up the DKIM record, email servers use the DKIM selector provided by the email service provider, not just the domain name. Suppose example.com uses Big Email as their email service provider, and suppose Big Email uses the DKIM selector big-email. Most of example.com’s DNS records would be named example.com, but their DKIM DNS record would be under the name big-email._domainkey.example.com, which is listed in the example above.
Content
This is the part of the DKIM DNS record that lists the public key. In the example above, v=DKIM1 indicates that this TXT record should be interpreted as DKIM, and the public key is everything after p=.
Below we query the linuxincluded.com domain using the “dkim” selector.
A DMARC record stores a domain’s DMARC policy. DMARC records are stored in the Domain Name System (DNS) as DNS TXT records. A DNS TXT record can contain almost any text a domain administrator wants to associate with their domain. One of the ways DNS TXT records are used is to store DMARC policies.
(Note that a DMARC record is a DNS TXT record that contains a DMARC policy, not a specialized type of DNS record.)
To find the IP address for a particular domain, simply pass the target domain name as an argument after the host command.
$ host andrewbaker.ninja
andrewbaker.ninja has address 13.244.140.33
For a comprehensive lookup using the verbose mode, use -a or -v flag option.
$ host -a andrewbaker.ninja
Trying "andrewbaker.ninja"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45489
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;andrewbaker.ninja. IN ANY
;; ANSWER SECTION:
andrewbaker.ninja. 300 IN A 13.244.140.33
andrewbaker.ninja. 21600 IN NS ns-1254.awsdns-28.org.
andrewbaker.ninja. 21600 IN NS ns-1514.awsdns-61.org.
andrewbaker.ninja. 21600 IN NS ns-1728.awsdns-24.co.uk.
andrewbaker.ninja. 21600 IN NS ns-1875.awsdns-42.co.uk.
andrewbaker.ninja. 21600 IN NS ns-491.awsdns-61.com.
andrewbaker.ninja. 21600 IN NS ns-496.awsdns-62.com.
andrewbaker.ninja. 21600 IN NS ns-533.awsdns-02.net.
andrewbaker.ninja. 21600 IN NS ns-931.awsdns-52.net.
andrewbaker.ninja. 900 IN SOA ns-1363.awsdns-42.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
Received 396 bytes from 100.64.0.1#53 in 262 ms
The -a option is used to find all Domain records and Zone information. You can also notice the local DNS server address utilised for the lookup.
$ host 13.244.140.33
33.140.244.13.in-addr.arpa domain name pointer ec2-13-244-140-33.af-south-1.compute.amazonaws.com.
3. To find Domain Name servers
Use the -t option to get the domain name servers. It’s used to specify the query type. Below we pass the -t argument to find nameservers of a specific domain. NS record specifies the authoritative nameservers.
$ host -t ns andrewbaker.ninja
andrewbaker.ninja name server ns-1254.awsdns-28.org.
andrewbaker.ninja name server ns-1514.awsdns-61.org.
andrewbaker.ninja name server ns-1728.awsdns-24.co.uk.
andrewbaker.ninja name server ns-1875.awsdns-42.co.uk.
andrewbaker.ninja name server ns-491.awsdns-61.com.
andrewbaker.ninja name server ns-496.awsdns-62.com.
andrewbaker.ninja name server ns-533.awsdns-02.net.
andrewbaker.ninja name server ns-931.awsdns-52.net.
4. To query certain nameserver for a specific domain
To query details about a specific authoritative domain name server, use the below command.
$ host google.com olga.ns.cloudflare.com
Using domain server:
Name: olga.ns.cloudflare.com
Address: 173.245.58.137#53
Aliases:
google.com has address 172.217.170.14
google.com has IPv6 address 2c0f:fb50:4002:804::200e
google.com mail is handled by 10 smtp.google.com.
5. To find domain MX records
To get a list of a domain’s MX ( Mail Exchanger ) records.
$ host -t MX google.com
google.com mail is handled by 10 smtp.google.com.
6. To find domain TXT records
To get a list of a domain’s TXT ( human-readable information about a domain server ) record.
$ host -t txt google.com
google.com descriptive text "docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"
google.com descriptive text "v=spf1 include:_spf.google.com ~all"
google.com descriptive text "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com descriptive text "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com descriptive text "atlassian-domain-verification=5YjTmWmjI92ewqkx2oXmBaD60Td9zWon9r6eakvHX6B77zzkFQto8PQ9QsKnbf4I"
google.com descriptive text "onetrust-domain-verification=de01ed21f2fa4d8781cbc3ffb89cf4ef"
google.com descriptive text "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
google.com descriptive text "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
google.com descriptive text "apple-domain-verification=30afIBcvSuDV2PLX"
google.com descriptive text "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
google.com descriptive text "webexdomainverification.8YX6G=6e6922db-e3e6-4a36-904e-a805c28087fa"
google.com descriptive text "MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
7. To find domain SOA record
To get a list of a domain’s Start of Authority record
$ host -t soa google.com
google.com has SOA record ns1.google.com. dns-admin.google.com. 505465897 900 900 1800 60
Use the command below to compare the SOA records from all authoritative nameservers for a particular zone (the specific portion of the DNS namespace).
$ host -C google.com
Nameserver 216.239.36.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 505465897 900 900 1800 60
Nameserver 216.239.38.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 505465897 900 900 1800 60
Nameserver 216.239.32.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 505465897 900 900 1800 60
Nameserver 216.239.34.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 505465897 900 900 1800 60
8. To find domain CNAME records
CNAME stands for canonical name record. This DNS record is responsible for redirecting one domain to another, which means it maps the original domain name to an alias.
To find out the domain CNAME DNS records, use the below command.
$ host -t cname www.yahoo.com
www.yahoo.com is an alias for new-fp-shed.wg1.b.yahoo.com.
$ dig www.yahoo.com
]
; <<>> DiG 9.10.6 <<>> www.yahoo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45503
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.yahoo.com. IN A
;; ANSWER SECTION:
www.yahoo.com. 12 IN CNAME new-fp-shed.wg1.b.yahoo.com.
new-fp-shed.wg1.b.yahoo.com. 38 IN A 87.248.100.215
new-fp-shed.wg1.b.yahoo.com. 38 IN A 87.248.100.216
;; Query time: 128 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 30 17:07:55 SAST 2023
;; MSG SIZE rcvd: 106
In the above shown example CNAME entry, if you want to reach “www.yahoo.com”, your computer’s DNS resolver will first fire an address lookup for “www.yahoo.com“. Your resolver then sees that it was returned a CNAME record of “new-fp-shed.wg1.b.yahoo.com“, and in response it will now fire another lookup for “new-fp-shed.wg1.b.yahoo.com“. It will then be returned the A record. So its important to note here is that there are two separate and independent DNS lookups performed by the resolver in order to convert a CNAME into a usable A record.
9. To find domain TTL information
TTL Stands for Time to live. It is a part of the Domain Name Server. It is automatically set by an authoritative nameserver for each DNS record.
In simple words, TTL refers to how long a DNS server caches a record before refreshing the data. Use the below command to see the TTL information of a domain name (in the example below its 300 seconds/5 minutes).
$ host -v -t a andrewbaker.ninja
Trying "andrewbaker.ninja"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27738
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;andrewbaker.ninja. IN A
;; ANSWER SECTION:
andrewbaker.ninja. 300 IN A 13.244.140.33
Received 51 bytes from 8.8.8.8#53 in 253 ms
If you see the error “The capture session could not be initiated on the device “en0″ (You don’t have permission to capture on that device)” when trying to start a pcap on wireshare you can try installing ChmodBPF; but I suspect you will need to follow the steps below:
$ whoami
superman
$ cd /dev
/dev $ sudo chown superman:admin bp*
Password:
$ ls -la | grep bp
crw------- 1 cp363412 admin 0x17000000 Jan 13 21:48 bpf0
crw------- 1 cp363412 admin 0x17000001 Jan 14 09:56 bpf1
crw------- 1 cp363412 admin 0x17000002 Jan 13 20:57 bpf2
crw------- 1 cp363412 admin 0x17000003 Jan 13 20:57 bpf3
crw------- 1 cp363412 admin 0x17000004 Jan 13 20:57 bpf4
/dev $
