Find out what's really happening on your firewall
20 hands-on investigation tasks using your live simulator workspace. Each task uses real data — the same security policies, NAT rules, traffic logs, and threats you'll see in your PAN-OS workspace.
🧭
New to PAN-OS? Start with the guided walkthrough
Step-by-step "where to click" tutorial with side-by-side screenshots. First lab: Create an Interface.
0 / 20 completed
1
Reconnaissance
Read-only exploration. No changes — just find the answers using the GUI and CLI.
1. Identify the firewall
What is the firewall's model, serial number, and software version? Find this three different ways: (a) the Dashboard widget, (b) a CLI command, (c) the Device → Configuration Snapshot.
Hint
(a) Dashboard → Overview → "General Information" widget.
(b) Open CLI tab and run
(c) Device → Configuration Snapshot — look near the top for
(b) Open CLI tab and run
show system info.(c) Device → Configuration Snapshot — look near the top for
<hostname>, but model/serial come from the system info widget.
2. Map the network edge
List every interface that is up. For each one, write down: name, IP/mask, security zone, and whether it's facing the LAN or the internet. Which interface is the firewall using to reach the default gateway?
Hint
Network → Interfaces (GUI), or
show interface all + show routing route (CLI). Default route 0.0.0.0/0 tells you the egress interface.
3. Count the rules
How many security rules are configured? What's the last rule's action — and why is it important that it sits at the bottom?
Hint
Policies → Security. Rules are evaluated top-down, first-match wins. PAN-OS has an implicit deny too — but an explicit deny at the bottom lets you LOG denies you'd otherwise miss.
4. Find a NAT rule
What NAT rule is letting the LAN talk to the internet? What kind of NAT is it doing — and which interface's IP address does the firewall use as the public-facing source?
Hint
Policies → NAT. Look for the "Translation" column — it'll say "dynamic-ip-and-port" (i.e. PAT/overload) plus the egress interface. CLI equivalent:
show running nat-policy.
5. Session table snapshot
Right now, how many active sessions is the firewall handling? What's the throughput (Mbps) and connections-per-second (CPS)? Find this two ways: the Dashboard widget AND the CLI.
Hint
Dashboard → Overview → "Live Traffic" widget. CLI:
show session info.
2
Investigation
Use the Monitor query bar (Phase 3 feature) to filter logs like a real SOC analyst.
6. SSL but blocked
In Monitor → Traffic, build a filter that shows only sessions where the application is "ssl" AND the action is "deny". How many entries match? What rule denied them?
Hint
Click "+ Add Filter" → attribute
app → operator eq → value ssl → Add. Then again with action eq deny. Or type it directly: ( app eq ssl ) and ( action eq deny ) and press Enter.
7. Find the critical threats
Go to Monitor → Threat. Filter for severity = critical. List every critical threat name you find and what action the firewall took (reset-both, alert, etc.). Are any of them well-known CVEs?
Hint
Filter:
( severity eq critical ). Watch for the Log4j CVE — it's the famous CVE-2021-44228 ("Log4Shell").
8. Phishing in URL filtering
In Monitor → URL Filtering, filter by category = phishing. Which URLs were attempted, what was the action, and which user (source IP) tried to visit them?
Hint
Filter:
( category eq phishing ). Action should be block-url for malicious categories.
9. Traffic from a single subnet
Find every traffic log where the source IP is in 10.10.10.0/24. Use the
in operator. What's the top application by appearance?
Hint
Filter:
( src in 10.10.10.0/24 ). The in operator does proper CIDR math — try a more specific /28 to see fewer matches.
10. Big files only
In Traffic logs, filter for sessions with bytes ≥ 500000 (half-megabyte or larger). Which apps tend to drive these big flows? Streaming? Cloud sync?
Hint
Filter:
( bytes geq 500000 ). The geq operator works on numbers. Try leq for "smaller than" too.
11. Combined filter — internal SSH
Build this filter on Traffic: source in
10.10.10.0/24 and app contains ssh. Result? Is SSH internal-only or going out to the internet?
Hint
Type directly:
( src in 10.10.10.0/24 ) and ( app contains ssh ). Press Enter / click the ▶ arrow.
12. ACC summary
Open the ACC tab → Network Activity. What are the top 3 applications by sessions? Top source IP? Now click "Threat Activity" — which severity bucket has the most hits?
3
Build configuration
Create real policies and commit them. Your changes persist in your workspace.
13. Block social media
CFO says: nobody on the LAN can use TikTok or Instagram during work hours. Create a security rule named
block-social-media from trust to untrust, applications tiktok-base, instagram-base, facebook-base, action deny. Place it above the existing allow rule. Commit, then verify with the Monitor → Traffic log that these apps now hit block-social-media.
Hint
Policies → Security → + Add. Application field accepts comma-separated values. After commit, refresh the Traffic log and filter
( rule eq block-social-media ). Rule order matters — newly-added rules go to the top of the list by default in this simulator.
14. Stand up a DMZ
Add a new zone called
dmz (layer3). Bring ethernet1/3 up by assigning IP 10.20.0.1/24, set its zone to dmz. Then write a rule that allows dmz → trust for service service-https only. Commit.
Hint
Network → Zones → + Add (name
dmz, type layer3, no interfaces yet). Then Network → Interfaces → ✎ on ethernet1/3 → set zone to dmz, IP to 10.20.0.1/24, state to up. Then Policies → Security → +Add with appropriate fields.
15. Address group for known-bad C2
Add 3 Address Objects:
cnc-1 = 192.0.2.66/32, cnc-2 = 198.51.100.13/32, cnc-3 = 203.0.113.99/32. Then create an Address Group known-bad-c2 with those 3 members. Write a security rule at the top of your list: from any to any, destination known-bad-c2, action drop. Commit.
Hint
Objects → Addresses → + Add (×3). Then Objects → Address Groups → + Add with the comma-separated members. The new rule must use the group name in the Destination field. Use
drop (silent) rather than deny if you want to avoid TCP resets giving away the firewall's presence.
16. Custom HTTPS service for an internal app
An internal app uses TCP port
8443. Create a new service object called service-https-alt for tcp/8443. Try doing this from the CLI, not the GUI: configure → set service service-https-alt protocol tcp port 8443 → commit. Verify with show running-config.
Hint
CLI tab → type
configure → prompt changes to #. Then set service service-https-alt protocol tcp port 8443. Then commit. Switch back to GUI Objects → Services to see your new entry.
4
Troubleshooting
Real diagnostic scenarios. Use CLI test commands and logs to find the answer.
17. Which rule will match?
A user at
10.10.10.21 wants to reach 8.8.8.8 on TCP. Use the CLI test security-policy-match to find out which rule they'd hit. Then verify by filtering the Traffic log for that source IP — does it match what you predicted?
Hint
CLI:
test security-policy-match from trust to untrust source 10.10.10.21 destination 8.8.8.8 protocol 6. Then go to Monitor → Traffic, filter ( src eq 10.10.10.21 ), look at the "Rule" column.
18. The paypal-secure-login mystery
A user complains they can't reach
paypal-secure-login.support. Investigate using the URL filtering log — is the firewall blocking it? Should it be? Write a 2-sentence justification you'd send to the user.
Hint
Filter URL log
( url contains paypal-secure-login ). Look at the category. Real PayPal lives at paypal.com, not *.support — this is a phishing domain. The firewall is doing exactly the right thing.
19. SSH brute force from a single source
You spot Brute-Force-SSH alerts in the Threat log. Pick the most-repeated source IP from those alerts. Create an Address Object
brute-force-attacker for that IP and add a top-of-list deny rule that drops traffic from that address to any zone. Commit. Bonus: how would you verify it worked in production?
Hint
Monitor → Threat → filter
( threat contains Brute-Force ). Note the source IP. Create the address object → create a rule at top: from any to any, source = that address object, action = drop. In real production you'd validate by tailing the traffic log and seeing the source disappear AND by trying to reach a service through the firewall from that IP.
5
Reporting & operations
The kind of work a real L1/L2 security analyst does daily.
20. The 15-minute shift report
Open Monitor → Traffic, Threat, URL, System in turn. Write a 5-bullet summary a manager could read in 60 seconds:
- Top 3 applications by traffic count
- Number of critical + high threats, and the worst CVE name
- Number of URLs blocked by category (phishing, malware, C2)
- Any system log entry with severity ≥ medium
- One recommendation: a new rule or address-group worth adding
Bonus: export the Traffic CSV using the ⤓ Export button so you can paste numbers into your report.
Done? Compare answers with a partner — different workspaces generate different data, so your traffic log will differ. The investigation skills are identical.