Journey Step 3 Visual Guide — Cisco FTD (FMC) Syslog Configuration

Audience: your organization's firewall administrator, managing Cisco Secure Firewall Management Center (FMC) 7.4.x for an FTD device.

When you need this guide. You are on Step 3 of the 4-step collector setup you are running from /client/settings/data-sources in the JawaSec portal:

1. Prepare the collector machine — a small Linux host on your network.
2. Run the command on that machine — the portal detects this automatically.
3. Tell the firewall where to send its logs — this guide.
4. Tell us how it went and save — the intake form back in the portal.

Everything this guide needs, and where to get it:

Substitute your own values wherever the examples appear.

Wherever a screenshot involves something to click or verify, a red box marks it. Screenshots without a box show a state to compare against.

---

How it works

Your FTD sends its logs via syslog (TCP) to the Linux machine you provisioned in Step 1. That machine runs the Elastic Agent the Step-2 command installed; the agent forwards parsed events on to the JawaSec platform over an outbound HTTPS connection. Nothing on your network accepts inbound connections from the internet.

---

What you are about to configure

Getting logs out of an FTD takes settings in four places in FMC. Miss any one of them and no data arrives, with no error to tell you which one you missed. Doing them in this order means you never hit a validation failure:

1. Platform Settings — where logs go: the syslog server and the routing filter.
2. Access Control policy → Logging — the policy-wide default that tells rules which syslog destination to use.
3. Access Control rules and default action — what gets logged.
4. Deploy — nothing above reaches the firewall until this runs.

---

Before you start

Confirm the syslog port is free on the collector machine. The collector listens on that port itself once it is activated (see the note at the end of this guide about when that listener actually starts). If another service already holds the port — a pre-existing rsyslog or syslog-ng listener is the usual culprit — the collector cannot bind to it later and no data will ever arrive.

Run this on the collector machine:

sudo ss -lntp | grep :9002

Output from anything other than the collector process means a conflict. Stop or reconfigure that service before continuing.

You also need:

• An FMC account that can edit Platform Settings and Access Control policies.
• Network reachability from the firewall to the collector on the syslog port (the connection itself will not succeed until Step 4 is complete — see below).
• Two maintenance windows, or one long enough for two deployments.

---

Part 1 — Create a Platform Settings policy

If your FMC already has a Threat Defense Settings policy assigned to the device, skip to Part 2 and edit that policy instead of creating a new one.

1.1 Confirm the device is registered

1.2 Open Platform Settings

Go to Devices → Platform Settings.

With no policy yet, the list is empty and offers three policy types. Click Threat Defense Settings Policy.

1.3 Name the policy and assign the device

Enter a name, select your device under Available Devices, click Add to Policy, then Save.

Confirm the device moved to Selected Devices before saving.

A Platform Settings policy that is not assigned to a device has no effect. The Policy Assignments counter in the top right must show at least 1.

---

Part 2 — Configure the syslog destination

The policy editor opens with a section list down the left. Select Syslog.

The Syslog section has seven tabs. You will use three: Logging Setup, Syslog Servers and Logging Destinations.

2.1 Turn logging on

On Logging Setup, tick Enable logging. This is the master switch, it is off by default, and everything else in this guide depends on it.

2.2 Check the TCP failure behavior

Open the Syslog Servers tab and confirm Allow user traffic to pass when TCP syslog server is down (Recommended) is selected. FMC 7.4 enables it by default. Then click Add.

Why this matters. With TCP syslog, the firewall's inherited default is to stop passing user traffic when the syslog server is unreachable. This checkbox disables that behavior. Leave it selected unless your organization requires traffic to halt when logging fails — this also matters directly here, because the collector's listener is not open until Step 4 of the portal journey completes (see below).

2.3 Create a network object for the collector

IP Address is an object picker, not a text field — you cannot type an address into it. Click the + beside it.

Fill in the object and click Save:

• Name — something recognizable (the example screenshots use JAW-2890-CaptureVM, our lab's name for the collector).
• Network — leave Host selected.
• Value — the collector address printed at the end of Step 2.

2.4 Complete the syslog server entry

Close and reopen the Add Syslog Server dialog now. The dropdown loaded its object list before your new object existed, so the object will not appear until the dialog is reopened.

Set every field, then click OK:

Choosing "Reachable By" correctly. Select Device Management Interface when the collector is on the same network as the firewall's management interface. Select Security Zones or Named Interface when it sits behind a data interface, then pick the zone that reaches it. Getting this wrong is the most common reason logs never arrive despite a correct address and port.

The server now appears in the table.

2.5 Route messages to that server

Adding a server sends nothing by itself. Open Logging Destinations and click Add.

Set Logging Destination to Syslog Servers, Event Class to Filter on Severity, and severity to 6 - informational. Click OK.

Why severity 6. Connection events — sessions being built and torn down, the bulk of what security analytics consumes — are emitted at informational severity. Anything stricter, such as 3 - errors, silently drops them. 7 - debugging adds volume with little analytical value; use it only while troubleshooting.

The filter appears in the table.

Click Save.

---

---

Continue with Part 2 of this guide: policy-wide logging, rule logging and deploy.