28 — The Open-Source Security Arsenal
Level: Intermediate · Time: ~18 min · Prerequisites: Lesson 27 — Vulnerability Management
Why this matters
Security work is mostly asking precise questions and reading the answers. "What is listening on this network?" "Is this endpoint's configuration what we agreed it should be?" "What did this host send out at 02:14?" "Does this file contain what it claims?" For almost every one of those questions there is a free, open-source tool that answers it well, and the reason beginners struggle is not a lack of tools — it is an overabundance of them with no map. People install twelve things, configure none, and conclude that open source does not work.
This lesson is the map. It groups the toolkit by the job it does, names the established open-source tool for each job, and points at the lesson where each is covered properly. After it, the rest of this module should read as detail rather than surprise. The second half is the part that matters more: how to choose two tools you will actually operate instead of twelve you will not, and where it is legitimate to run them.
The map, by job family
| Job | Tools | What it is for | Goes deeper |
|---|---|---|---|
| Reconnaissance and OSINT | Amass, Subfinder, theHarvester, SpiderFoot, Recon-ng | enumerate your organisation's public footprint from public sources | Lesson 29 |
| Port and service scanning | Nmap, Masscan, ZMap, Naabu | find what is listening, where, and which version | Lesson 29 |
| Vulnerability scanning | Greenbone Community Edition (OpenVAS), Nuclei, Nikto, Trivy | match known weaknesses against a known inventory | Lesson 30 |
| Exploitation and validation frameworks | Metasploit Framework, searchsploit, BeEF | prove that a suspected flaw is genuinely exploitable | Lesson 30 |
| Web proxies and web scanners | OWASP ZAP, mitmproxy, Wapiti, Nikto | see, modify and test requests against a web application you own | Lesson 30 |
| Packet capture and traffic analysis | tcpdump, tshark, Wireshark, Zeek, ntopng | see what is on the wire, and understand what it means | Lesson 31 |
| Network intrusion detection and rich network logging | Suricata, Snort, Zeek, Security Onion | detect and record network behaviour across the estate | Lesson 31 |
| Full packet capture and traffic search | Arkime, Stenographer, tcpdump with ring files | keep the packets so you can search them months later | Lesson 31 |
| Host hardening audit and compliance | OpenSCAP, Lynis, Wazuh (security configuration assessment), InSpec | measure a host against a written baseline and prove it | Lesson 32 |
| File integrity monitoring | AIDE, Wazuh FIM, Samhain | know when a file that should not change has changed | Lesson 32 |
| Rootkit and malware scanning | ClamAV, chkrootkit, rkhunter, YARA, Linux Malware Detect | find known-bad files, signatures and rootkit indicators | Lesson 32 |
| Endpoint visibility and inventory queries | osquery, Velociraptor, Wazuh | ask "which hosts have this installed or running" and get an answer | Lesson 32 |
| Endpoint triage at scale | Velociraptor, GRR, Fleet with osquery | collect artefacts from thousands of endpoints in minutes, repeatably | Lesson 32, then Lesson 36 |
| Log collection, search and SIEM | Wazuh, OpenSearch, Grafana Loki, Graylog, Security Onion | collect, normalise, retain and search logs | Lesson 22 for the data, Lesson 23 for the platform |
| Dashboards and metrics | Grafana, OpenSearch Dashboards | turn stored data into a view somebody looks at every morning | Lesson 23 |
| Firewall and routing platforms | nftables and iptables, pfSense CE, OPNsense, OpenWrt, VyOS | decide which traffic may move, and in which direction | Lesson 18 for the concepts, Lesson 34 for the platforms |
| VPN | WireGuard, OpenVPN, strongSwan | extend a private network over an untrusted one | Lesson 18 |
| DNS filtering and resolution | Pi-hole, AdGuard Home, Unbound, BIND 9, dnsmasq | control name resolution and keep the query log that detects abuse | Lesson 34, and Lesson 41 for the home network |
| Automated blocking and abuse mitigation | Fail2ban, CrowdSec, nftables with ipset, Suricata in IPS mode | turn a detection into a block without a human in the loop | Lesson 34 |
| Honeypots and deception | Cowrie, OpenCanary, Dionaea, T-Pot | learn what is being tried against you, early and cheaply | Lesson 34 |
| Password strength testing and hash analysis | Hashcat, John the Ripper, Hydra, zxcvbn, libpwquality | test whether your password policy survives a realistic cracking model | Lesson 13, then Lesson 33 |
| Cryptography and certificate tooling | OpenSSL, GnuPG, age, certbot, testssl.sh, sslyze, cfssl | inspect, issue and test keys, certificates and TLS configuration | Lesson 4, then Lesson 33 |
| Secrets management | OpenBao, SOPS, Gitleaks, TruffleHog, KeePassXC | keep credentials out of code, tickets and inventories | Lesson 33 |
| Disk and memory forensics | dc3dd, ddrescue, Guymager, The Sleuth Kit, Autopsy, Volatility 3, LiME, AVML, bulk_extractor | acquire and examine a disk or a memory image without altering it | Lesson 25, then Lesson 36 |
| Timeline and artefact analysis | plaso (log2timeline), Timesketch, mactime, Hayabusa | turn artefacts from many sources into one order of events | Lesson 25, then Lesson 36 |
| Threat intelligence platforms | MISP, OpenCTI, TheHive with Cortex | store, share and act on indicators and reports | later in this module |
| Case management and automation | TheHive, DFIR-IRIS, Shuffle, StackStorm | record what happened and automate the repetitive parts of response | Lesson 24 and later in this module |
| Cloud posture auditing | Prowler, ScoutSuite, Cloud Custodian, Steampipe | find misconfiguration and exposed services in a cloud account | later in this module |
| Container and Kubernetes security | Trivy, Grype, Syft, Falco, kube-bench, Kubescape, Kyverno | scan images and dependencies, watch runtime behaviour, audit cluster configuration | later in this module |
| Wireless assessment | Kismet, Aircrack-ng, hcxtools, Bettercap | survey and test the wireless network you are responsible for | Lesson 15, and Lesson 41 |
| Network discovery and monitoring | Nmap, arp-scan, NetBox, LibreNMS, Zabbix, Nagios Core | know what is on the network, what it is, and whether it is up | later in this module |
| Phishing and email analysis | SpamAssassin, python-oletools, ClamAV, munpack and ripmime, Zeek | take a suspicious email apart and decide what it was trying to do | Lesson 12, then later in this module |
Read the table as a set of questions rather than a shopping list. Two tools in a row you can operate beat six you installed on a Sunday and never tuned.
How to choose a tool instead of hoarding them
Start from a question you can phrase in one sentence. "I need to know which of my endpoints still run a version of the web server with this flaw" is a question; "I should look at vulnerability management tools" is a category. The question tells you whether you need an agent, a network scanner or a query tool — and it usually tells you that you need one, not five.
Then run every candidate through the same five checks:
| Check | What to look for | Why it matters |
|---|---|---|
| Licence | permissive (MIT, Apache-2.0, BSD) versus copyleft (GPL, AGPL) | permissive lets you embed and redistribute freely; copyleft obligations follow you into products. If you resell anything, read the licence before you build on it |
| Maintenance | recent releases, responsive issue tracker, a changelog, a published support window | an abandoned security tool accumulates its own vulnerabilities and nobody fixes them |
| Security policy | a SECURITY.md, a vulnerability disclosure process, past advisories handled well |
a security tool is itself a supply chain dependency. How the project handles its own vulnerabilities predicts how it will handle yours |
| Operability | can you install, configure, back up and upgrade it — and who does that when you are on holiday | the most capable tool you cannot maintain is worse than the modest tool you can |
| Data and dependencies | what it needs to run, where it stores data, what it phones home to | a tool that needs 32 GB of RAM and a database cluster is a project, not a tool |
Two licence caveats worth knowing before you standardise on anything:
- "Source-available" is not "open source". Several widely used platforms have moved from OSI-approved open-source licences to source-available ones — the SSPL and the BUSL are the common examples — which restrict what you may offer as a service. Read the licence, not the marketing page.
- Some free tools are freeware, not open source. They are still worth using — this course focuses on open source because it can be inspected, audited and run without a licence bill — but be honest about which is which in your documentation, because the difference becomes legal if you redistribute.
# A security tool is itself a supply chain: verify what you install
sha256sum -c tool-1.2.3.tar.gz.sha256 # the published checksum matches
gpg --verify tool-1.2.3.tar.gz.asc tool-1.2.3.tar.gz # and the signature belongs to the maintainer
# And know what you are already carrying, before adding anything new
dpkg-query -W -f='${Package} ${Version}\n' nmap wireshark osquery
[!TIP] The single best test of whether a tool belongs in your estate is whether you can name the person who will upgrade it, and on what schedule. If the answer is "nobody", you are not adopting a tool, you are accumulating technical debt with a CVE feed attached.
Where to run them, and where never to
The rule is not negotiable: run these tools only against systems you own or have written permission to test. In your own lab that permission is yours to give, which is exactly why Lesson 37 exists — a small isolated network with a handful of deliberately vulnerable targets, a copy of the same software you run in production, and no route to anything real. Everything offensive in this module is meant to be learned there.
Never point a scanning or exploitation tool at a third party — not a supplier's website, not a competitor, not "just the login page", not "only a ping". In France, as in most jurisdictions, accessing or maintaining access to a computer system without authorisation is a criminal offence regardless of intent, and a scan is treated as an attempt. Open source does not mean unowned: the licence covers the software you run, not the systems you point it at.
Once the lab exists, the tools pay for themselves in the opposite direction too. The same scanner that finds your lab's weaknesses will tell you what your own external footprint looks like, and the same traffic tools that record an attack in the lab will record what reaches your real network.
Your first five tools
If you install nothing else this month, install these five, in this order, and learn each one properly before adding the next.
| Tool | The question it answers | Read next |
|---|---|---|
| Nmap | what is exposed on my own network, and what is running there | Lesson 29 |
| Wireshark (and tshark) | what is actually happening on the wire right now | Lesson 31 |
| Greenbone Community Edition | which known weaknesses exist on the assets I have inventoried | Lesson 30 |
| Wazuh | what happened on my hosts, and is their configuration still what I agreed | Lesson 23 |
| osquery | what is this endpoint running, right now, across the whole fleet | Lesson 32 |
Five tools, five questions, and a defensible answer to each is a genuinely capable small-environment toolkit. Everything else on the map above is detail you can add once these five are tuned, backed up and understood.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Mass scanning for exposed services | an off-the-shelf scanner sweeps your address space looking for anything answering | close what you cannot justify, keep an inventory, and alert on scans aimed at you rather than the background noise |
| Weaponised exploitation of an unpatched service | a public framework turns a known vulnerability into a one-command compromise | patching cadence (Lesson 27), authenticated scanning, and validating your own findings before an attacker does |
| Credential attacks using open-source cracking tools | stolen hashes are cracked offline, or logins are guessed against a live service | long unique passphrases, MFA everywhere, account lockout with rate limiting, and no unsalted fast hashes in storage |
| Command and control hidden in an allowed protocol | an implant uses HTTPS or DNS so nothing unusual appears on the wire | egress allowlists, DNS logging with client attribution, traffic analysis (Lesson 31) |
| Abuse of legitimate administration tooling | remote management agents, scripting and forensic collection tools are turned against the estate | inventory the approved agents, restrict who may deploy them, alert on new ones |
| Attacking the security tool itself | the scanner holds credentials for everything and is a high-value target | least-privilege read-only scanning accounts, management-network placement, patching the tool |
| Supply-chain compromise of a security tool | an update to a widely trusted tool ships malicious code | pin versions, review updates before rollout, and prefer projects with a real security policy |
| Breaking the rules of engagement | a tool is pointed at a system outside the authorised scope | written authorisation naming hosts and dates, a stop condition, a named contact (Lesson 30) |
| Honeypot fingerprinting | an attacker identifies and avoids your deception environment, or uses it as a foothold | keep deception isolated, unprivileged, and monitored in both directions |
| Reading your public footprint first | an attacker knows more about your exposure than you do | run your own reconnaissance before someone else does (Lesson 29) |
Key takeaways
- Every tool on the map answers a question. Learn the question, not the tool list — the map is stable, the tool names change.
- Two well-tuned tools beat twelve unconfigured ones. Adoption is a maintenance commitment, not a download.
- A security tool is a supply chain. Check the licence, check whether it is maintained, and check how the project handles its own vulnerabilities.
- Source-available is not open source, and freeware is not either. Know which you are deploying and why.
- Authorisation is the boundary between practice and offence. Your own lab is where these tools are learned; anything else needs written scope.
Check yourself
- You need to know which servers still run a vulnerable library version. Which job family answers that, and which single question must you resolve first?
- Give two reasons a maintained project matters more than a feature-rich abandoned one for a security tool specifically.
- What is the difference between a permissive and a copyleft licence, and when does that difference become your problem?
- You have an afternoon free. Name the five tools from the beginner list and the question each one answers.
- A colleague suggests running a scanner against a supplier's website "just to see". What is wrong with that, legally and professionally?