Journey Step 3 Visual Guide — Cisco FTD (FMC) Syslog Configuration (2/2)
This is the second half of the guide. Part 1 covered the Platform Settings policy and the syslog destination.
Part 3 — Set the policy-wide syslog default
Do not skip this. Access control rules that send to syslog do so through the policy's default syslog configuration. Until that default exists, the rules point at nothing and deployment fails validation.
3.1 Open the access control policy
Go to Policies → Access Control and open the policy assigned to your device.
3.2 Open the policy's Logging page
Click More → Logging in the policy's breadcrumb bar.
By default nothing is selected here, and an orange banner warns that at least one option is required.
3.3 Point it at the Platform Settings server
Tick Use the syslog settings configured in the FTD Platform Settings policy
deployed on the device, then set Syslog Severity to INFO.
While you are here, tick Send Syslog messages for IPS events and Send Syslog messages for File and Malware events. Without these, intrusion and file/malware events stay in the Management Center and never reach your collector.
Leave "Send using specific syslog alert" unticked. It is the alternative to what you just selected: it points at a Syslog Alert object defined in the FMC with its own address and port. Since the destination already lives in Platform Settings, ticking both would define two competing destinations. Unticked here is deliberate, not an oversight.
Click Save.
Part 3b — Check the file policy before you rely on malware events
Part 3.3 above makes the Management Center send file and malware events to syslog. It does not make the Management Center generate them in the first place. Whether a malware download produces any event at all depends entirely on the separate File Policy object attached to your access control rule — a policy built to cover only a narrow slice of traffic will silently miss the rest, with no error and no event, exactly like an unconfigured syslog destination.
We have seen this in testing: a firewall with intrusion prevention fully
enabled let a malware-carrying .zip through with no event of any kind,
purely because of how its file policy was scoped.
Go to Policies → Access Control → Malware & File, open the policy whose name appears on your access control rule (Rule editor → File Policy field), and check the settings below. If that field says None, no file inspection is happening at all — create a file policy first, or tell us in the Step 4 intake form and we will confirm what your license covers.
Four settings gate this independently; any one wrong produces the same silence:
| # | Setting | What happens if it is wrong |
|---|---|---|
| 1 | File type categories — the policy's rule(s) must cover Archive (.zip, .rar, .7z, …), Executables, and Office Documents and PDF files |
A rule scoped to "Executables" only never looks inside a .zip — the file inside is invisible to the engine even though the container passed through |
| 2 | Inspect Archives — this checkbox (with a depth of at least 1) must be ON | With it off, an archive is never opened at all, regardless of what categories are selected in #1 |
| 3 | Log Files — on the access control rule that carries the file policy (Rule editor → Logging tab), tick Log Files. This is separate from, and additional to, the policy-wide "Send Syslog messages for File and Malware events" you ticked in Part 3.3 | With it off, the file policy can match perfectly and still produce no syslog record |
| 4 | Rule action — set to Malware Cloud Lookup or Block Malware (not just "Detect Files") | "Detect Files" alone identifies the file type but never produces a malware verdict |
Two of these control whether the firewall inspects the file, two control whether it tells anyone — you need all four.
If the download happens over HTTPS, file inspection also depends on your SSL decryption policy being active for that traffic — without decryption, the firewall cannot see inside the encrypted file to inspect it at all.
How to verify it is working. Tell us before you run this test. Write to your JawaSec contact (or add a note in the Step 4 intake form) so we mark the test window — otherwise it is handled as a real malware detection and you may get an out-of-hours call. Use the official EICAR test file from https://www.eicar.org/download-anti-malware-testfile/ — it is harmless by design, but your antivirus will quarantine it, which is expected. Do it from one designated test machine, inside a maintenance window.
Download the EICAR test file packaged inside a .zip through the protected
path. In FMC go to Analysis → Files → Malware Events and confirm a row
for the test file with a Disposition of Malware. Once your syslog
forwarding is complete, the same event reaches the JawaSec portal (it arrives
as Cisco message ID 430005).
If nothing appears, re-check the four settings above before assuming the download itself failed. Still nothing after that — contact JawaSec.
Part 4 — Enable syslog on the rules
Part 3 defined the destination. This part decides what actually gets sent.
4.1 Edit each rule
Click a rule name to open it, then click Logging in the rule header.
Under Send Connection Events to:, Syslog server is unticked by
default — even on rules that already show Logging ON, because those are
logging to the Management Center only.
Tick Syslog server, then click Confirm and Apply.
Also confirm at least one of Log at beginning of connection or Log at end of connection is ticked. If neither is, the rule produces no connection events at all.
If this rule carries a file policy (see Part 3b), also tick Log Files on this same Logging tab — without it, malware events from this rule never reach syslog even if everything in Part 3b is otherwise correct.
Repeat for every rule whose traffic you want to see.
You may see a warning that a rule could shadow rules below it, or that it has no source or destination network objects. That describes the rule's existing scope, not anything this procedure changed.
4.2 Do not forget the default action
This is the most commonly missed setting in the whole procedure. The default action at the bottom of the policy handles every packet that matches no rule — usually blocking it — and by default it logs nothing at all, not even to the Management Center. Denied traffic is exactly what a SOC most wants to see.
Click the gear icon beside Default Action.
Tick Log at beginning of connection and Syslog server, then Apply. (Block actions cannot log at end of connection, so that option stays greyed out.)
Click Save.
4.3 Security Intelligence (only if you use it)
Security Intelligence blocklists have their own logging toggles — the small icons beside Networks and URLs in the Block List column.
Hover each icon to see how many objects the list contains. If your block lists are empty, there is nothing to log and you can skip this. Enable it if you later populate those lists.
Part 5 — Deploy
Nothing configured above reaches the firewall until it is deployed.
Click Deploy in the top navigation, select your device, and click Deploy All.
Plan this step. Deployment pushes configuration to a live firewall and can briefly interrupt traffic. Run it in a maintenance window.
If you see a validation warning
Skipping Part 3 produces exactly this:
"Access Control Policy Logging configuration is invalid. Access Control rules have syslog configured to use Access Control policy's logging configuration. Configure a valid syslog destination to avoid syslogs not being sent."
Do not tick Ignore warnings. Go back and complete Part 3 — deploying past this warning produces a firewall that looks configured and sends nothing.
Watch it through
Deployment takes several minutes and reports its stage as it goes.
Wait for Completed / 1 succeeded.
Important — the collector is not listening yet
FMC deployment finishes the firewall's half of the job, but that alone does not make the collector reachable. The collector's syslog listener on port 9002 does not open when your machine enrolls in Step 2 — it opens when Step 4 (the intake form) is submitted and JawaSec's activation completes. Enrollment only registers the machine with our Fleet management; the syslog input itself is a separate configuration that is attached to your machine automatically once both your enrollment and your Step-4 submission are in.
Practically: if you test connectivity from the firewall to the collector's port before you finish Step 4, the connection will fail — by design, not because something is wrong on your side. Complete Steps 1-4 in order, including saving the intake form, before drawing any conclusion from a failed connectivity test.
You also never need to re-run the Step-2 install command after this guide. The syslog listener is delivered to your already-enrolled machine as a policy update pushed by Fleet — the same mechanism Step 2's agent already checks in through — not by reinstalling anything.
Verification
On the collector machine, confirm the firewall is connecting (only meaningful after Step 4 has completed and activation has run — see the box above):
sudo ss -tnp | grep :9002
You should see an established connection whose peer is the firewall's interface address.
If you want to prove the firewall is trying even before the collector is ready, watch the packets directly:
sudo tcpdump -nn -i any 'tcp port 9002' -c 20
A firewall that is correctly configured but talking to a collector whose
listener has not opened yet (i.e., you have not finished Step 4) looks like
this — repeated [S] from the firewall, [R.] back:
10.20.0.11.14222 > 10.20.0.20.9002: Flags [S], ...
10.20.0.20.9002 > 10.20.0.11.14222: Flags [R.], ...
That output means the firewall side is finished and the only thing missing is finishing Step 4 in the portal.
In the JawaSec portal, the Step-3 card flips to done once you tick the confirmation checkbox and the Step-4 intake form is submitted; the source itself goes Active once JawaSec's automatic activation detects the first real events arriving from your collector — this does not happen instantly at Save.
If nothing arrives after Step 4
Each of these produces the same symptom — no data — so check them all before concluding the firewall is at fault.
| Check | How |
|---|---|
| Step 4 not actually submitted | Go back to /client/settings/data-sources and confirm the card shows the intake step as done |
| Something else holds the port on the collector | sudo ss -lntp | grep :9002 — anything other than the collector process is a conflict |
| Network path blocked | Confirm the port is reachable from the firewall's network; check security groups, cloud firewalls and host firewalls |
| Wrong "Reachable By" | Section 2.4 — management interface versus data interface |
| No logging filter | Section 2.5 — a syslog server with no logging destination sends nothing |
| Severity too strict | Sections 2.5 and 3.3 — anything stricter than informational drops connection events |
| No policy-wide syslog default | Part 3 — rules pointing at a default that does not exist |
| Rules not sending to syslog | Section 4.1 — Logging ON alone is not enough |
| Denied traffic missing | Section 4.2 — the default action logs nothing until you enable it |
| Configuration never deployed | Part 5 — saved is not the same as deployed |
Notes
- The IP Address field in the Add Syslog Server dialog accepts only a selection from its dropdown. Typing a name that matches an existing object is not enough; the field stays flagged invalid until an entry is chosen from the list.
- A network object created through the + button inside that dialog does not appear in the dropdown until the dialog is closed and reopened, which reloads the object list.
- Multiple syslog servers are supported. To keep a raw local copy of the logs alongside the collector, add a second syslog server entry on a different port of the same host and have a local syslog daemon write that port to a file.
- Changing rule logging requires a deployment; so does the default action. Batch your changes and deploy once rather than deploying after each edit.
- One collector machine can receive both a Palo Alto and a Cisco FTD
integration at once, one per port (
9001Palo Alto,9002Cisco by convention) — each keeps its own state in the portal.
Questions
Direct any questions about this guide or the firewall change to your JawaSec onboarding contact.