Find the source of DNS request on windows client

 To tracks the DNS request back to a PC you can use cisco umbrella or watching the DNS debug logs on the DNS server. That will tell you the IP of the machine the DNS requests are coming from but you may want to know what process its coming from.

There are a few tools you can use

Microsoft Sysmon (sysinternals)

1 - Download sysmon

https://technet.microsoft.com/en-us/sysinternals/sysmon

2 - Download swift security profile

https://github.com/SwiftOnSecurity/sysmon-config

3 - Install sysmon with the swift security profile

Sysmon.exe -accepteula -i .\sysmonconfig-export.xml

4 - Open event viewer and check the sysmon logs

Eventvwr.msc

Applications and services logs -> Microsoft -> Windows -> Sysmon

Right click -> find  search for URL

You will see the process under image name.

Wireshark

Won't show you the process it came from but you should see when requests are happening

Useful capture filters

Show all dns traffic:

dns

Show DNS requests to the URL and also any connections to its IP, URL = x1.c.lencr.org, nslooked up to 23.72.154.199

(ip.dst == 23.72.154.199) or ((dns.qry.name == x1.c.lencr.org))

Look for all DNS requests coming from my PC 192.168.1.10

(dns.flags.response == 0) and (ip.src == 192.168.1.10) and (dns.qry.name == x1.c.lencr.org)

tcpview

Someuser report success using TCP view. Nslookup the URL -> IP then watch TCPview for connections to that IP. Usually a connection to the IP will happen straight after a DNS request

Uncheck TCPv6 etc if this is not your traffic. A good place to start is IPv4 only and then search for the IP, we should see a module/process

Windows transfer speed slow in one direction over VPN

Copy files A -> B was fine

but B-> A was slow

Checked all the devices, VPN all looking good. It sended up being a simple duplex issue. The link from the switch to the firewall on side B was auto'd to half-100. I hard coded it to 1000 full and all was good.

Steps to follow

Check the full network path from side A<->B is speed/duplex correct on switchports.

RAM+CPU good on each device that is moving the data

Run speed test to make sure internet connetions are ok

Run some ping -t to watchout for packet loss

smokeping or pingplotter several places local, across vpn, internet (1.1.1.1,8.8.8.8,4.2.2.2) for packet loss + latency

Check if Server is VM and check vmware for datastore for any issues

Check for arp issues, is there arp poisoning or static arp entry somewhere, is the mac address hopping around for one of the source/destination IP

Quickly generate dummy files for testing file copies on windows

 https://tweaks.com/windows/62755/quickly-generate-large-test-files-in-windows/

fsutil file createnew 1gb.test 1073741824

The key is to input the size of the file in bytes so here are some common file sizes to save you from math:

1 MB = 1048576 bytes

100 MB = 104857600 bytes

1 GB = 1073741824 bytes

10 GB = 10737418240 bytes

100 GB =107374182400 bytes

1 TB = 1099511627776 bytes

10 TB =10995116277760 bytes

test policy on palo alto similar to packet tracer

 I haven't had much luck with this, it doesn't seem to work as well as packet tracer. It's often returning that the traffic is blocked when in fact it is allowed.

Anyway you can give it a go, its down the bottom in the GUI "Test policy match"

On CLI:

test security-policy-match source 192.168.0.1 destination 8.8.8.8 destination-port 53 protocol 17

test security-policy-match source 192.168.0.1 destination 8.8.8.8 destination-port 443 protocol 6

Protocol 17 = udp

Protocol 6 = tcp

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-cli-quick-start/use-the-cli/test-the-configuration/test-policy-matches

NAT on palo alto firewall

 I find switching from ASA to palo alto NAT confusing because they work in a different way and I've worked on ASA for so long.

nat rule (to nat traffic)

outside -> outside

Destination address is customer public IP: 100.200.200.114

Destination translations address is inside IP of the server: 192.168.0.1

policy rule (to allow traffic)

outside -> inside

Source IP is outside source public 8.8.8.8

inside destination IP is the public IP: 100.200.200.114

The main thing there is a public IP NAT is outside to outside on palo. On ASA its outside to inside for a public IP NAT.

• Source zone: outside
• Destination zone: outside
• Destination interface: eth1/1 (outside)
• Source add: any
• Destination address: 100.100.100.50 (public IP of server)
• Service: port 443
• Source translation: "none"
• Destination Translation:
• destination-translation (translation type "static IP")
• address: 192.168.100.50 (inside IP)
• port: 443

check when a S2S VPN established

 show vpn-sessiondb l2l filter ipaddress x.x.x.x

Connection   : x.x.x.x

Index        : 69987                  IP Addr      : x.x.x.x

Protocol     : IKEv1 IPsec

Encryption   : IKEv1: (1)AES256  IPsec: (2)AES256

Hashing      : IKEv1: (1)SHA1  IPsec: (2)SHA1

Bytes Tx     : 6629603                Bytes Rx     : 9801553

Login Time   : 07:20:46 UTC Wed Jul 13 2022

Duration     : 4h:12m:59s

Tunnel Zone  : 0

Some useful items we can see the login time (time of last rekey)

Duration, how long the VPN has been up since then.

You can check 

sh crypto isakmp sa detail | b x.x.x.x

IKE Peer: x.x.x.x

Type    : L2L             Role    : initiator

Rekey   : no              State   : MM_ACTIVE

Encrypt : aes-256         Hash    : SHA

Auth    : preshared       Lifetime: 86400

Lifetime Remaining: 70716

Here you can see the lifetime and lifetime4 remaining. You can use these values to work out when next rekey should be.

86400 / 60 /60 = 24 (hours)

70716 /60 /60 = 19.6 (hours

That matches up to the 4 hour duration so everything looks good there. If you keep checking in on it or are able to monitor the VPN you might spot that is rekeying randomly and that needs to be investigated.

how to look at office macros without running them

 olevba is a good linux tool to look at the macro code without opening the file in MS office tc.