Security testing gets treated as a once-a-year audit or something that only matters for enterprises. In practice, most infrastructure has exploitable gaps that a developer with an afternoon and Kali Linux could find themselves — before an attacker does.
I’ve been running periodic self-audits on my own servers and home network using Kali for a couple of years. The point isn’t to become a penetration tester. The point is to see your infrastructure the way an outsider would. What follows are ten concrete things you can do, right now, to learn where you’re exposed.
Important caveat: Only test infrastructure you own or have explicit written permission to test. Running these tools against systems you don’t control is illegal in most jurisdictions, regardless of intent.
1. Scan your network to see what’s actually exposed
Before anything else, you need a map. nmap is the standard tool for this, and it ships with Kali.
nmap -sV -sC -p- 192.168.1.0/24-sVdetects service versions-sCruns default scripts (banner grabbing, common checks)-p-scans all 65535 ports, not just the common ones
What this reveals: open ports you forgot about, services still running on non-standard ports, old versions of software listening on the network. Most people find something surprising here — a development server still running, an admin interface accessible on a public IP, a printer with a web UI.
For a public-facing server, scan it from a VPS or home connection to simulate an external attacker’s view:
nmap -sV -sC your.server.ip2. Check for default credentials
A staggering number of network devices, admin panels, and internal services ship with default credentials that never get changed.
hydra can brute-force login forms using wordlists, but start with something simpler: just try the defaults manually.
For the automated approach on SSH:
hydra -L /usr/share/wordlists/metasploit/unix_users.txt \
-P /usr/share/wordlists/metasploit/unix_passwords.txt \
ssh://192.168.1.1Kali includes the SecLists wordlist collection which has default credential pairs for hundreds of devices. For web admin panels, hydra supports HTTP-POST form authentication too.
If you have any device that shipped with a default password — a router, NAS, IP camera, managed switch — test this against it. The result is usually sobering.
3. Audit your SSL/TLS configuration
Weak TLS configuration is invisible until it’s exploited. testssl.sh is included in Kali and does a thorough analysis of any TLS endpoint.
testssl.sh your.domain.comIt checks for:
- Support for deprecated protocol versions (SSL 3, TLS 1.0, TLS 1.1)
- Weak cipher suites (RC4, 3DES, export-grade ciphers)
- Certificate validity, chain issues, and expiry
- HSTS, HPKP, and security header presence
- Vulnerability to known attacks: POODLE, BEAST, HEARTBLEED, ROBOT
This takes about two minutes to run and gives you a clear picture of your TLS hygiene. Pay attention to anything marked in red — those are active risks, not theoretical ones.
4. Test for open DNS resolvers and zone transfer
DNS misconfigurations are common and can leak substantial information about your infrastructure.
Check if your DNS server will perform a zone transfer (which would expose all your DNS records to anyone who asks):
dig axfr @your-nameserver your.domain.comA properly configured server rejects this. If it succeeds, you’ve just handed an attacker a full map of your hostnames, internal services, and mail configuration.
Also check whether your resolver responds to queries from arbitrary sources:
dig @your-nameserver google.comIf this returns a result from an external IP, your server is an open resolver — potentially usable in DNS amplification attacks.
5. Run a vulnerability scan with OpenVAS
Manual reconnaissance is useful, but OpenVAS (part of the Greenbone Vulnerability Management suite) automates a systematic check across thousands of known CVEs.
# Start the service
sudo gvm-start
# Access the web UI
xdg-open https://127.0.0.1:9392Set up a scan target with your server’s IP, run a full scan, and review the report. OpenVAS categorizes findings by severity and links each one to the relevant CVE. This is particularly useful for catching unpatched services — things like outdated OpenSSH versions, old Apache or Nginx builds, or misconfigured services that match known vulnerability signatures.
Run this quarterly at minimum, or after any significant infrastructure change.
6. Inspect what your web apps are leaking in HTTP headers
Web servers often disclose unnecessary information in response headers — the server software, version, framework, and sometimes internal details. This narrows an attacker’s research.
curl -I https://your.domain.comLook for:
Server: Apache/2.4.51 (Ubuntu)— version disclosureX-Powered-By: PHP/8.1.0— framework disclosure- Missing
X-Content-Type-Options,X-Frame-Options,Content-Security-Policy
Nikto automates a broader check:
nikto -h https://your.domain.comIt tests for hundreds of common misconfigurations: exposed .git directories, admin paths, outdated software signatures, dangerous HTTP methods enabled (like PUT or DELETE), and more. It’s noisy and will show up in your logs, so run it against your own servers only.
7. Check for credential exposure in web app flows
Many web vulnerabilities aren’t about the server at all — they’re about how the application handles authentication. Burp Suite Community Edition is included in Kali and lets you intercept and inspect HTTP traffic.
Set your browser to proxy through 127.0.0.1:8080, start Burp, and walk through your app’s login and session flows. Look for:
- Passwords or tokens transmitted in query strings (which end up in server logs)
- Session cookies missing the
HttpOnlyorSecureflags - Session tokens that don’t change after login (session fixation)
- Predictable or sequential IDs in API responses
These are issues that don’t show up in port scans or CVE databases. They require looking at the actual application behavior.
8. Test your firewall rules with a port knocking/bypass attempt
Firewalls give a false sense of security if the rules aren’t regularly validated. nmap has several techniques for identifying misconfigurations:
# FIN scan — bypasses some stateless packet filters
nmap -sF your.server.ip
# Scan with decoys to test if your IDS/IPS alerts
nmap -D RND:10 your.server.ip
# Test if UDP ports are incorrectly exposed
nmap -sU --top-ports 100 your.server.ipUDP scanning is particularly worth doing. TCP services tend to get locked down; UDP often doesn’t. DNS (53), SNMP (161), NTP (123), and TFTP (69) are common culprits for unintentional exposure.
9. Analyze your wireless network security
If your infrastructure includes a wireless network, aircrack-ng and kismet (both in Kali) let you audit it properly.
Start with a passive survey:
sudo airmon-ng start wlan0
sudo airodump-ng wlan0monThis shows every access point in range with its BSSID, channel, encryption type, and connected clients. Immediately obvious issues: WEP encryption (broken since 2007), open networks, WPS enabled (vulnerable to Pixie Dust attacks).
For WPA2 handshake capture and offline dictionary attack testing:
sudo airodump-ng -c [channel] --bssid [AP MAC] -w capture wlan0monIf a captured handshake can be cracked with rockyou.txt, your passphrase isn’t strong enough. This is a useful reality check for whether your “random” Wi-Fi password actually is.
10. Test your incident detection and response
This last one is different from the others. Instead of finding vulnerabilities, you’re testing whether you’d even know if someone was inside.
Run some of the scans above against your own servers and then check:
- Did your IDS/IPS (if you have one) fire any alerts?
- Are the scan attempts showing up in your server logs?
- If they are in the logs, is anyone looking at those logs?
# On the target server, after running a scan
grep "nmap" /var/log/auth.log
grep "syn" /var/log/syslog | tail -50Most small infrastructure setups have no active monitoring whatsoever. An attacker could do a full port scan, probe for vulnerabilities, and enumerate services without triggering a single alert. Knowing this is true of your setup is the first step toward fixing it.
Tools worth setting up after this exercise: fail2ban for automated IP blocking on repeated failures, ossec or wazuh for host-based intrusion detection, and centralized logging with something like Loki or a simple ELK stack.
Where to go from here
Running these checks on your own infrastructure once gives you a snapshot. Running them regularly gives you a baseline — so you notice when something changes.
The goal isn’t to find zero issues. Most infrastructure has issues. The goal is to know what they are and make informed decisions about which to fix first. That’s exactly what a real attacker does when they start looking at your systems. Get there before they do.