Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem parsing Netscaler log #2594

Open
thrunter opened this issue Sep 20, 2024 · 1 comment
Open

Problem parsing Netscaler log #2594

thrunter opened this issue Sep 20, 2024 · 1 comment
Assignees

Comments

@thrunter
Copy link

What is the sc4s version ?

3.30.0

Which runtime (Docker, Podman, Docker Swarm, BYOE, MicroK8s) are you using for SC4S?

Podman

Last chance index/Fallback index?

Yes, fallback of APPFW from Netscaler

Is the issue related to local customization?

No

Do we have all the default indexes created?

Yes

Describe the bug
I've ingesting Netscaler logs sent to the SC4S. Everything works except for some of the Netscaler logs. There are a few log rows that has a newline charachters. See the log row below:

<134> 09/20/2024:12:37:48 GMT VPX1 0-PPE-3 : default APPFW Message 54353 0 : "IP-REP recorded IP as malicious. CS VSERVER NAME: domain | LB VSERVER NAME: domain | Date & Time: Fri, 20 Sep 2024 12:37:48 GMT | Client IP: 1.1.1.1 | Requst URL: 1.2.4.3 | Request Full Header: GET / HTTP/1.1
Host: 1.2.4.3
User-Agent: Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: [email protected]
Accept-Encoding: gzip

"

This makes the SC4S produce a fallback except the first row. So the last row only gets the " as ingested. Is there a solution to this problem?

@cwadhwani-splunk cwadhwani-splunk self-assigned this Sep 30, 2024
@cwadhwani-splunk
Copy link
Collaborator

Hi @thrunter
Multiline logs are currently not handled in Netscaler.
Also, the header is only added in the first line and not in the others, so writing an apt postfilter parser for this could be a bit tricky and unreliable.

Can we check in the PCAP and confirm the format, just wanted to confirm that the multiline logs are not having headers in all the lines. If this would be the case, I think this should be fixed from the vendor side.
We can take further steps after confirming this format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants