Integraciones

Cisco FTD (FMC) — Syslog Configuration Guide (1/2): destination

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: # Requirement Instructions to get it 1 Collector address (example used in this guide: 10.20.0.20 ) Printed by the install command at the end of Step 2 of the in-portal journey 2 Syslog port (example: 9002 ) Printed by the install command at the end of Step 2, right next to the address 3 An FMC account that can edit Platform Settings and Access Control policies Your firewall administrator / FMC admin grants it 4 Network reachability from the firewall to the collector on the syslog port Your network team confirms no firewall/ACL blocks TCP to the collector on that port 5 Two maintenance windows (or one long enough for two deployments) Schedule with your change-management process — FMC deploys twice in this guide 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 Device Management showing the registered FTD 1.2 Open Platform Settings Go to Devices → Platform Settings. The Devices menu with Platform Settings marked With no policy yet, the list is empty and offers three policy types. Click Threat Defense Settings Policy. Empty Platform Settings list 1.3 Name the policy and assign the device Enter a name, select your device under Available Devices, click Add to Policy, then Save. New Policy dialog with name, device and Save marked Confirm the device moved to Selected Devices before saving. Device listed under Selected Devices 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. Platform Settings policy editor with Syslog marked The Syslog section has seven tabs. You will use three: Logging Setup, Syslog Servers and Logging Destinations. The Syslog section and its tabs 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. Enable logging selected 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. Syslog Servers tab with the safety checkbox and Add marked 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. Empty Add Syslog Server dialog with the + button marked 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. New Network Object with name, host value and Save marked 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: Field Value IP Address Your collector object, selected from the dropdown list Protocol TCP Port The port printed at the end of Step 2 Reachable By See the note below Add Syslog Server dialog completed 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. Syslog server listed 2.5 Route messages to that server Adding a server sends nothing by itself. Open Logging Destinations and click Add. Add Logging Filter dialog with Logging Destination marked Set Logging Destination to Syslog Servers, Event Class to Filter on Severity, and severity to 6 - informational. Click OK. Logging filter set to Syslog Servers at informational severity 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. Logging destination listed Click Save. Platform Settings saved Continue with Part 2 of this guide: policy-wide logging, rule logging and deploy.

Cisco FTD (FMC) — Syslog Configuration Guide (2/2): logging & deploy

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. Access Control policy list Access control rules 3.2 Open the policy's Logging page Click More → Logging in the policy's breadcrumb bar. The More menu with Logging marked By default nothing is selected here, and an orange banner warns that at least one option is required. Default Syslog Settings before configuration 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. Default Syslog Settings configured 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. Access control policy logging saved 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. Rule editor 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. Rule logging settings with Syslog server unticked Tick Syslog server, then click Confirm and Apply. Syslog server ticked 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. Second rule's logging settings — shown BEFORE ticking Syslog Server; tick it just as you did on the first rule 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. Default action logging, nothing enabled 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.) Default action logging configured Click Save. Access control policy saved 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. Security Intelligence block lists 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. Deploy panel with the device ready 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: Validation warning about invalid Access Control Policy Logging "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. Deployment in progress Wait for Completed / 1 succeeded. Deployment completed 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 (9001 Palo Alto, 9002 Cisco 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.

Palo Alto NGFW (PAN-OS) — Syslog Configuration Guide

Journey Step 3 Visual Guide — Palo Alto Networks PAN-OS Syslog Configuration Audience: your organization's firewall administrator, managing a Palo Alto Networks firewall (VM-Series or hardware) running PAN-OS 10.2, 11.1, or 11.2. 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: # Requirement Instructions to get it 1 Collector address (example used in this guide: <collector-ip> ) Printed by the install command at the end of Step 2 of the in-portal journey 2 Syslog port (example: 9001 ) Printed by the install command at the end of Step 2, right next to the address 3 A PAN-OS account that can edit Device → Server Profiles, Objects → Log Forwarding, and Policies → Security Your firewall administrator grants it 4 Network reachability from the firewall to the collector on the syslog port Your network team confirms no firewall/ACL blocks TCP to the collector on that port 5 A Threat Prevention license, if you want Threat logs and not just Traffic logs Check under Device → Licenses 6 One maintenance window for the commit Schedule with your change-management process — PAN-OS commits once in this guide 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 firewall 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, with the Palo Alto Networks (panw) integration; 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 a PAN-OS firewall takes four legs, in this order: 1. Server Profile — where logs go: the syslog server's address, port, transport, and format. 2. Log Forwarding Profile — what gets sent: which log types (Traffic, Threat) forward to that server. 3. Attach the Log Forwarding profile to every Security rule whose traffic you want to see, including your Deny rules. 4. Commit — 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 -lntup | grep 9001 Output from anything other than the collector process means a conflict. Stop or reconfigure that service before continuing. Also confirm your firewall's time zone, at Device → Setup → Management → General Settings → Time Zone, before you configure anything — see the note below about why this matters. You also need: - A PAN-OS account that can edit Server Profiles, Log Forwarding profiles, and Security policy. - 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). - A Threat Prevention license if you want Threat logs. Without it you still get Traffic logs; no amount of policy tuning substitutes for the license. Part 1 — Create the Syslog Server Profile 1.1 Log in PAN-OS login screen 1.2 Confirm you are on the right device PAN-OS dashboard for the target firewall 1.3 Open Server Profiles → Syslog Select the Device tab in the top navigation bar. In the left-hand tree, expand Server Profiles and click Syslog. Device tab and the Server Profiles → Syslog entry in the left tree With no profile yet, the list is empty. Click Add at the bottom. The empty Syslog profile list — the Add button is at the bottom left 1.4 Name the profile and add a server row In the Syslog Server Profile dialog, type a profile Name — something recognizable for this collector. On the Servers tab, click the Add button inside the dialog, not the one on the page behind it. This adds one row to the servers grid. Empty dialog: the Name field and the inner Add button of the Servers grid 1.5 Fill the server row Click each cell to edit it: Column Value Notes Name e.g. collector Free-form label for this destination Syslog Server <collector-ip> IP or FQDN of the host running Elastic Agent Transport TCP Defaults to UDP — you must change it Port 9001 Defaults to 514 — you must change it Format IETF Defaults to BSD — you must change it Facility LOG_USER Default is fine Server row added, fields open for editing Click OK. Why IETF and not BSD. The collector's TCP input expects PAN-OS to send syslog messages using the IETF (RFC 5424) format, with RFC 6587 framing (octet counting) — the collector's TCP input enables this by default. BSD format over TCP will parse badly or not at all. 1.6 Confirm the profile Profile listed after saving Profile shown as created This is what a correct profile looks like — server address, TCP, your syslog port, IETF, LOG_USER: The finished profile: address · TCP · port · IETF · LOG_USER Part 2 — Create the Log Forwarding Profile Where: Objects → Log Forwarding The server profile only says where to send. This step says what to send. 1. Select the Objects tab, then Log Forwarding in the left tree. 2. Click Add. 3. Name the profile. 4. Add two match-list entries, one per log type: Entry name Log Type Filter Syslog destination traffic-all traffic All Logs your syslog server profile threat-all threat All Logs your syslog server profile For each: click Add in the match list, give it a name, pick the Log Type, leave the Filter as All Logs, then under Forward Method → Syslog click Add and select your server profile. 5. Click OK. Log forwarding profile list The log forwarding profile with both match-list entries Add only the log types you actually intend to consume. Every extra type is volume you pay to ship, store, and eventually filter back out. traffic alone is usually the highest-volume class on a real perimeter. Part 3 — Attach the profile to your Security rules Where: Policies → Security This is the step most often missed. A log forwarding profile that is not referenced by any rule forwards nothing, and the firewall reports no error whatsoever. 1. Select the Policies tab, then Security. 2. Click the name of a rule that carries the traffic you want to observe. Security rule list 3. Go to the Actions tab. 4. Under Log Setting: - Tick Log at Session End. - Leave Log at Session Start unticked. - Set Log Forwarding to your profile. 5. Click OK. 6. Repeat for every rule that covers traffic you care about — including any explicit Deny rules, which on a real perimeter are usually the single largest source of events. The Actions tab: Log at Session End ticked, Log Forwarding set to the profile Why not Log at Session Start. Enabling both emits two records per session — one at start and one at end — roughly doubling volume while adding no verdict. The session-end record is the one that carries bytes, duration, application, and action. Turn on session-start only when you are specifically debugging session establishment. Part 4 — Commit 1. Click Commit at the top right, then Commit again in the dialog. 2. Wait for the job to reach 100% and report Configuration committed successfully. Nothing you configured above is live until this finishes. A commit on a VM-Series takes roughly one to two minutes. A note on time zone PAN-OS stamps syslog messages using the firewall's configured local time zone, found at Device → Setup → Management → General Settings → Time Zone. If the firewall runs in a local zone while your collector and every other log source run in UTC, PAN-OS events land on the timeline offset by that many hours. Nothing errors. Dashboards populate. Correlation against other sources silently produces nothing, and every time-window query you write is wrong. Two valid resolutions — pick one deliberately: Option When to choose it Set the firewall to UTC Greenfield deployments, anywhere you control the device. Simplest and removes the class of bug entirely. Declare the offset to JawaSec The device's zone is not yours to change — tell your onboarding contact the firewall's time zone so it can be declared to the ingest pipeline. Whichever applies, tell your onboarding contact which one — it needs to be on record for anyone debugging a time-window query later. Important — the collector is not listening yet Committing finishes the firewall's half of the job, but that alone does not make the collector reachable. The collector's syslog listener on port 9001 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): ss -tn state established '( sport = :9001 )' Established connections from the firewall's IP mean the transport works. If you want to prove the firewall is trying even before the collector is ready, watch the packets directly: sudo tcpdump -ni any "port 9001 and src host <firewall-ip> and greater 100" -A -s0 -c 6 A well-formed message from a correctly configured firewall carries an RFC 6587 octet-count prefix followed by the RFC 5424 header and the log body — for example 812 <14>1 2026-08-28T13:42:35-07:00 .... If you see that on the wire, the firewall is doing its job and any remaining problem is downstream. If you don't, the problem is profile or policy configuration (Parts 1-3). 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. # Cause How to confirm Fix 1 Something else owns the collector's port ss -lntup | grep 9001 shows a process that is not the collector agent Stop it / remove its listener 2 Log forwarding profile not attached to any rule Rule's Actions tab shows Log Forwarding: None Attach it (Part 3) — repeat per rule 3 Changes never committed Commit button still shows pending changes Commit (Part 4) 4 Format left at BSD over TCP Server profile shows Format: BSD Change to IETF (Part 1) 5 Transport left at UDP / port left at 514 Server profile shows UDP or 514 Change to TCP and the collector's port 6 No Threat Prevention license Device → Licenses has no Threat Prevention entry Traffic logs still work; THREAT requires the license 7 Traffic never reaches this firewall Confirm the traffic you generated actually routes through this device Route the test host through the intended firewall 8 Firewall cannot reach the collector From the firewall, test the syslog port Open routing / security groups on your side; confirm Step 4 completed on ours 9 Step 4 not actually submitted Go back to /client/settings/data-sources and confirm the card shows the intake step as done Submit the intake form 10 Time zone mismatch Data is present but not where you're looking See "A note on time zone" — search a wider window before concluding it's missing 11 TCP framing mismatch (internal, collector-side) Packets are visibly arriving ( tcpdump shows the firewall sending) but zero documents are indexed This is not a firewall-side setting — it means the collector's input is not expecting RFC 6587 octet-counting framing. Report it to your JawaSec onboarding contact; nothing on the firewall needs to change Notes - The Syslog Server field in the Server Profile dialog is a plain text field — enter your collector's address or FQDN directly. - Multiple syslog servers are supported within one profile. 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. - One collector machine can receive both a Palo Alto and a Cisco FTD integration at once, one per port (9001 Palo Alto, 9002 Cisco by convention) — each keeps its own state in the portal. - A "Welcome to PAN-OS!" modal can appear on first login and blocks every click behind it, including the top navigation. Close it first. - The Add button appears twice when a dialog is open — once inside the dialog, once on the page behind it. Clicking the wrong one silently does nothing useful. Questions Direct any questions about this guide or the firewall change to your JawaSec onboarding contact.