Reverse shells and bind shells should only be used in authorized security testing environments. Using them without authorization is illegal.
curl is the standard command-line HTTP client. It supports every HTTP feature, multiple protocols (HTTP, HTTPS, FTP, SCP, SFTP), and extensive configuration options.
# Verbose output (show headers, request/response)
curl -v https://example.com
# Show only response headers
curl -I https://example.com
curl -L https://example.com
# Silent mode (no progress bar, no errors)
curl -s https://example.com
# Show response with status code
curl -s -o /dev/null -w " %{http_code} " https://example.com
curl -X POST -H " Content-Type: application/json " \
-d ' {"name":"Alice","email":"alice@example.com"} ' \
https://api.example.com/users
curl -X PUT -H " Content-Type: application/json " \
-d ' {"name":"Alice Updated"} ' \
https://api.example.com/users/1
curl -X PATCH -H " Content-Type: application/json " \
-d ' {"email":"newalice@example.com"} ' \
https://api.example.com/users/1
curl -X DELETE https://api.example.com/users/1
curl -X POST -d " username=alice&password=secret " https://example.com/login
curl -X POST -F " file=@document.pdf " https://example.com/upload
curl -H " Authorization: Bearer token123 " https://api.example.com/data
curl -H " X-Custom-Header: value " https://example.com
curl -H " Authorization: Bearer token123 " \
-H " Accept: application/json " \
-H " X-Request-ID: abc-123 " \
https://api.example.com/data
curl -i https://example.com
curl -D - https://example.com
curl -w " DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n " \
-o /dev/null -s https://example.com
# Use specific TLS version
curl --tlsv1.2 https://example.com
curl --tlsv1.3 https://example.com
curl -v https://example.com 2>&1 | grep -E " SSL|subject|issuer|expire "
curl --cacert /path/to/ca.pem https://example.com
# Skip certificate verification (insecure, for testing only)
curl -k https://example.com
curl --cert client.pem --key client.key https://example.com
# Show supported cipher suites
curl -v --ciphers ' ALL ' https://example.com 2>&1 | grep " SSL connection "
# Set connection timeout and max time
curl --connect-timeout 5 --max-time 30 https://example.com
# Retry on failure (curl 7.66.0+)
curl --retry 3 --retry-delay 2 --retry-all-errors https://example.com
curl --retry 5 --retry-delay 2 --retry-max-time 60 https://example.com
dig (Domain Information Groper) is the standard DNS query tool. It provides detailed DNS Information and is more flexible than nslookup.
# Query specific record type
# Query from a specific DNS server
# Short output (IP address only)
dig +noall +answer example.com
# Query with specific class
dig -x 2606:2800:220:1:248:1893:25c8:1946
# Trace DNS resolution from root
# Trace showing each step
dig +trace example.com @8.8.8.8
dig example.com DNSKEY +dnssec
dig example.com RRSIG +dnssec
# Query with EDNS0 (Extension Mechanisms)
# Query with specific EDNS buffer size
dig +bufsize= 4096 example.com
# Query TXT records for SPF/DKIM/DMARC
dig _dmarc.example.com TXT
dig example.com CAA +short
# Check zone transfer (AXFR) -- usually blocked
dig axfr example.com @ns1.example.com
# Query with specific port
dig -p 5353 example.com @127.0.0.1
dig example.com A AAAA MX +noall +answer
# Show all sections of the response
# Show only the answer section
dig +noall +answer example.com
# Show only the authority section
dig +noall +authority example.com
# Show only the additional section
dig +noall +additional example.com
dig +time= 2 +tries= 1 example.com
# Check for DNSSEC validation
nslookup is a simpler DNS query tool. It is less flexible than dig but is available on more Systems (including Windows).
nslookup -type=MX example.com
nslookup -type=NS example.com
nslookup -type=TXT example.com
nslookup example.com 8.8.8.8
ss replaces the older netstat command for examining network sockets. It is faster and provides More detailed information.
# Show all TCP connections
# Show all listening TCP sockets
# Show all sockets (TCP, UDP, UNIX)
# Show socket memory usage
ss -tan state established
# Show sockets for a specific process
# Show sockets for a specific user
# Show sockets for a specific address
ss -tan dst 192.168.1.100
# Show sockets for a specific port
# Show timer information (keepalive, retransmission)
# Extended information (uid, ino, sk, etc.)
# State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
# ESTAB 0 0 192.168.1.10:54321 93.184.216.34:443 users:(("curl",pid=12345,fd=3))
Recv-Q: For ESTABLISHED sockets, bytes in the receive buffer not yet read by the application. For LISTEN sockets, the backlog (pending connections in the SYN queue).Send-Q: For ESTABLISHED sockets, bytes in the send buffer not yet acknowledged by the peer. For LISTEN sockets, the accept queue size (configured backlog).Process: The process name, PID, and file descriptor that owns the socket.# Check for TIME_WAIT accumulation
ss -tan state time-wait | wc -l
# Check for CLOSE_WAIT (application not closing sockets)
# Check for high Recv-Q (application not reading fast enough)
ss -tan | awk ' $2 > 1000 '
# Show socket buffer sizes
# Show TCP info (congestion window, RTT, retransmissions)
ss -ti dst 93.184.216.34:443
nmap is a network scanning tool for port scanning, service detection, and OS fingerprinting.
nmap -p 22,80,443 192.168.1.100
nmap -p 1-1000 192.168.1.100
# TCP SYN scan (stealth scan, faster than connect scan)
# UDP scan (slow, requires root)
# Fast scan (top 100 ports)
# Scan with service version detection
# Aggressive scan (version, script, OS)
# Scan without DNS resolution (faster)
# Scan with output formats
nmap -oN scan.txt 192.168.1.100 # Normal output
nmap -oX scan.xml 192.168.1.100 # XML output
nmap -oG scan.gnmap 192.168.1.100 # Grepable output
# Default scripts (vulnerability detection)
nmap --script http-headers 192.168.1.100
nmap --script ssl-heartbleed 192.168.1.100
nmap --script vuln 192.168.1.100
nmap --script ssl-enum-ciphers -p 443 192.168.1.100
iperf3 measures network throughput (bandwidth) between two hosts. One host runs as a server, the Other as a client.
# On the client (default: TCP, 10 seconds)
iperf3 -c 192.168.1.100 -t 30
iperf3 -c 192.168.1.100 -u -b 1G
# Parallel streams (test multi-connection throughput)
iperf3 -c 192.168.1.100 -P 8
# Reverse direction (server sends to client)
iperf3 -c 192.168.1.100 -R
iperf3 -c 192.168.1.100 -p 5201
# JSON output (for scripting)
iperf3 -c 192.168.1.100 -J
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec
[ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec
- - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-4.00 sec 449 MBytes 942 Mbits/sec sender
[ 5] 0.00-4.00 sec 449 MBytes 942 Mbits/sec receiver
Bitrate < expected: Check for duplex mismatches, cable issues, NIC speed negotiation, or congestion on the path.Significant retransmissions: Packet loss on the path. Check with ping and mtr.High jitter (UDP): Variable latency. Common on wireless links and congested networks.mtr combines ping and traceroute into a single tool. It sends packets to every hop Simultaneously and continuously updates the display, showing loss and latency at each hop.
# Report mode (non-interactive, N cycles)
mtr --report --report-cycles 10 example.com
# TCP mode (can traverse firewalls that block ICMP)
mtr --tcp -P 443 example.com
# With specific packet size
mtr --psize 1400 example.com
Start: 2024-01-01T00:00:00+0000 HOST: example.com Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 10 0.3 0.3 0.3 0.4 0.0
2.|-- 10.0.0.1 0.0% 10 1.2 1.1 1.0 1.3 0.1
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 203.0.113.1 0.0% 10 12.3 12.1 11.2 13.5 0.7
5.|-- 198.51.100.1 0.0% 10 14.5 14.3 13.4 15.7 0.8
6.|-- 93.184.216.34 0.0% 10 15.6 15.4 14.5 16.8 0.9
Loss%: Packet loss at that hop. Loss at intermediate hops that does not propagate to subsequent hops is rate limiting of ICMP responses, not real packet loss.Last/Avg/Best/Worst: Latency measurements. Look for sudden increases between hops.StDev: Standard deviation of latency. High values indicate variable latency (jitter).??? : The hop is not responding. This is common and does not indicate a problem.Capturing on the wrong interface. On systems with multiple interfaces, tcpdump -i any captures on all interfaces but may not show VLAN tags. Capture on the specific interface (tcpdump -i eth0) for accurate results.
tcpdump dropping packets. tcpdump may drop packets on high-throughput links because the kernel buffer fills faster than userspace reads. Increase the buffer size with -B (buffer size in bytes): tcpdump -i eth0 -B 32768. Use -c to limit the number of captured packets.
Confusing ss Recv-Q for established vs listening sockets. For ESTABLISHED sockets, Recv-Q is unread data. For LISTEN sockets, Recv-Q is the SYN backlog (pending connections). High Recv-Q on LISTEN means the server is not accepting connections fast enough.
nmap timing and IDS. Default nmap scans can be slow. Use -T4 or -T5 for faster scans in trusted environments. Aggressive scanning can trigger IDS/IPS alerts.
iperf3 single-stream vs multi-stream. A single TCP stream is limited by congestion control. Multi-stream tests (-P 8) can saturate higher-bandwidth links but do not represent real application behavior. Use the appropriate number of streams for your workload.
Forgetting to check MTU. MTU mismatches cause fragmented packets and “path MTU black holes” when ICMP Fragmentation Needed messages are filtered. Test with: ping -c 3 -M do -s 1472 example.com (1472 + 28 bytes IP+ICMP header = 1500 bytes). If this fails, reduce the size until it succeeds to find the actual path MTU.
DNS caching interfering with diagnostics. When troubleshooting DNS, flush the resolver cache to ensure you are testing against the authoritative server:
# Linux (systemd-resolved)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Use +trace in dig to bypass caches
Trusting tool output blindly. Always verify with multiple tools. If ping fails but curl succeeds, ICMP is filtered. If dig returns an IP but curl fails, there may be a firewall blocking TCP. Cross-reference symptoms across tools and layers to isolate the root cause.This topic covers the essential concepts and techniques related to network tools, including key principles and practical applications.
Key concepts include:
core concepts and definitions key principles and frameworks practical applications common techniques and methods evaluation and critical analysis A thorough understanding of these concepts, combined with regular practice and review, is essential for mastery of this topic.
Worked examples demonstrating the application of key concepts are covered in the detailed sub-pages linked above.