Security testing often gets treated as a once-a-year audit, or something that only matters to enterprises. In practice most infrastructure has gaps that a developer with an afternoon and Kali Linux could find before anyone else 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; it’s to see your infrastructure the way an outsider would. Here are ten concrete things you can do 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
This reveals open ports you forgot about, services still running on non-standard ports, and old software versions listening on the network. Most people find something surprising, like a development server still running, an admin interface reachable on a public IP, or 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, or managed switch), test 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
It takes about two minutes and gives you a clear picture of your TLS hygiene. Pay attention to anything marked in red, since those are active risks rather than 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, which can be abused for DNS amplification.
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 especially useful for catching unpatched services such as 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. That narrows an outsider’s research.
curl -I https://your.domain.comLook for:
Server: Apache/2.4.51 (Ubuntu)(version disclosure)X-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 issues don’t show up in port scans or CVE databases. You have to look at the actual application behaviour.
8. Test your firewall rules with a port knocking/bypass attempt
Firewalls give a false sense of security when the rules aren’t checked regularly. nmap has a few techniques for finding 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 worth doing. TCP services tend to get locked down, and 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. The obvious problems stand out: WEP encryption (broken since 2007), open networks, and 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 cracks with rockyou.txt, your passphrase isn’t strong enough. It’s a useful reality check on whether your “random” Wi-Fi password really is random.
10. Test your incident detection and response
This one is different from the rest. Instead of finding vulnerabilities, you’re checking 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 setups have no active monitoring at all. Someone could run a full port scan, probe for vulnerabilities, and list your services without a single alert firing. Knowing that about your own setup is the first step to 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 once gives you a snapshot. Running them regularly gives you a baseline, so you notice when something changes.
The goal isn’t zero issues, because most infrastructure has some. The goal is to know what they are and decide which to fix first. That’s what someone probing your systems from outside would be doing, so it helps to get there first.