Suricata http event and alert event output seem not correct!

Help
1

Please include the following information with your help request:

  • Suricata version
  • Operating system and/or Linux distribution
  • How you installed Suricata (from source, packages, something else)

Hello, everyone, recently I met a quite strange problem about suricata json output, I used Suricata 7.0.0 on Ubuntu 20.04, and suricata installed from source.

Here is part of my eve.json output:

{
	"timestamp": "2023-09-15T14:10:47.112531+0800",
	"flow_id": 2166177628681236,
	"in_iface": "enp5s0",
	"event_type": "http",
	"vlan": [
		20
	],
	"src_ip": "192.168.30.208",
	"src_port": 39366,
	"dest_ip": "172.16.20.192",
	"dest_port": 9200,
	"proto": "TCP",
	"pkt_src": "wire/pcap",
	"community_id": "1:vPVqFh5IOJ4oDMQ/8zFw58pGNOg=",
	"tx_id": 0,
	"http": {
		"http_port": 0,
		"url": "\u0000\u0000\u0000\u0010?@\u0000\u0000\u0000\u0000\u0000\u0002sr\u0000:com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
		"http_content_type": "application/json",
		"http_method": "\\xac\\xed\u0000\u0005sr\u0000\u0017java.util.LinkedHashSet\\xd8l\\xd7Z\\x95\\xdd*\u001E\u0002\u0000\u0000xr\u0000\u0011java.util.HashSet\\xbaD\\x85\\x95\\x96\\xb8\\xb74\u0003\u0000\u0000xpw",
		"protocol": "WO\\xc1n\\xac\\xab3\u0003\u0000\u0006I\u0000\r_indentNumberI\u0000\u000E_transletIndex[\u0000",
		"status": 400,
		"length": 341,
		"request_headers": [
			{
				"name": "",
				"value": "_bytecodest"
			}
		],
		"response_headers": [
			{
				"name": "X-elastic-product",
				"value": "Elasticsearch"
			},
			{
				"name": "content-type",
				"value": "application/json; charset=UTF-8"
			},
			{
				"name": "content-length",
				"value": "341"
			}
		]
	}
}




{
	"timestamp": "2023-09-15T14:10:47.112642+0800",
	"flow_id": 2166177628681236,
	"in_iface": "enp5s0",
	"event_type": "alert",
	"vlan": [
		20
	],
	"src_ip": "192.168.30.208",
	"src_port": 39366,
	"dest_ip": "172.16.20.192",
	"dest_port": 9200,
	"proto": "TCP",
	"pkt_src": "wire/pcap",
	"metadata": {
		"flowbits": [
			"Elasticsearch_unauthorized"
		]
	},
	"community_id": "1:vPVqFh5IOJ4oDMQ/8zFw58pGNOg=",
	"alert": {
		"action": "allowed",
		"gid": 1,
		"signature_id": 46937,
		"rev": 6,
		"signature": "INDICATOR-SHELLCODE ysoserial Java object deserialization exploit attempt(CVE-2017-11284,CVE-2019-12630,CVE-2020-27131,CVE-2020-36239)",
		"category": "Executable code was detected",
		"severity": 1,
		"metadata": {
			"policy": [
				"security-ips drop",
				"max-detect-ips drop",
				"connectivity-ips drop",
				"balanced-ips drop"
			],
			"service": [
				"java_rmi"
			]
		}
	},
	"http": {
		"http_port": 0,
		"url": "\u0000\u0000\u0000\u0010?@\u0000\u0000\u0000\u0000\u0000\u0002sr\u0000:com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
		"http_content_type": "application/json",
		"http_method": "\\xac\\xed\u0000\u0005sr\u0000\u0017java.util.LinkedHashSet\\xd8l\\xd7Z\\x95\\xdd*\u001E\u0002\u0000\u0000xr\u0000\u0011java.util.HashSet\\xbaD\\x85\\x95\\x96\\xb8\\xb74\u0003\u0000\u0000xpw",
		"protocol": "WO\\xc1n\\xac\\xab3\u0003\u0000\u0006I\u0000\r_indentNumberI\u0000\u000E_transletIndex[\u0000",
		"status": 400,
		"length": 341,
		"http_response_body_printable": "{\"error\":{\"root_cause\":[{\"type\":\"illegal_argument_exception\",\"reason\":\"invalid version format: WO..N....3\\u0003\\u0000\\u0006I\\u0000\\r_INDENTNUMBERI\\u0000\\u000E_TRANSLETINDEX[\"}],\"type\":\"illegal_argument_exception\",\"reason\":\"invalid version format: WO..N....3\\u0003\\u0000\\u0006I\\u0000\\r_INDENTNUMBERI\\u0000\\u000E_TRANSLETINDEX[\"},\"status\":400}",
		"http_response_body": "eyJlcnJvciI6eyJyb290X2NhdXNlIjpbeyJ0eXBlIjoiaWxsZWdhbF9hcmd1bWVudF9leGNlcHRpb24iLCJyZWFzb24iOiJpbnZhbGlkIHZlcnNpb24gZm9ybWF0OiBXT8OBTsKswqszXHUwMDAzXHUwMDAwXHUwMDA2SVx1MDAwMFxyX0lOREVOVE5VTUJFUklcdTAwMDBcdTAwMEVfVFJBTlNMRVRJTkRFWFsifV0sInR5cGUiOiJpbGxlZ2FsX2FyZ3VtZW50X2V4Y2VwdGlvbiIsInJlYXNvbiI6ImludmFsaWQgdmVyc2lvbiBmb3JtYXQ6IFdPw4FOwqzCqzNcdTAwMDNcdTAwMDBcdTAwMDZJXHUwMDAwXHJfSU5ERU5UTlVNQkVSSVx1MDAwMFx1MDAwRV9UUkFOU0xFVElOREVYWyJ9LCJzdGF0dXMiOjQwMH0=",
		"request_headers": [
			{
				"name": "",
				"value": "_bytecodest"
			}
		],
		"response_headers": [
			{
				"name": "X-elastic-product",
				"value": "Elasticsearch"
			},
			{
				"name": "content-type",
				"value": "application/json; charset=UTF-8"
			},
			{
				"name": "content-length",
				"value": "341"
			}
		]
	},
	"app_proto": "http",
	"app_proto_ts": "failed",
	"direction": "to_server",
	"flow": {
		"pkts_toserver": 6,
		"pkts_toclient": 6,
		"bytes_toserver": 3375,
		"bytes_toclient": 899,
		"start": "2023-09-15T14:10:47.111136+0800",
		"src_ip": "192.168.30.208",
		"dest_ip": "172.16.20.192",
		"src_port": 39366,
		"dest_port": 9200
	},
	"payload": "rO0ABXNyABdqYXZhLnV0aWwuTGlua2VkSGFzaFNldNhs11qV3SoeAgAAeHIAEWphdmEudXRpbC5IYXNoU2V0ukSFlZa4tzQDAAB4cHcMAAAAED9AAAAAAAACc3IAOmNvbS5zdW4ub3JnLmFwYWNoZS54YWxhbi5pbnRlcm5hbC54c2x0Yy50cmF4LlRlbXBsYXRlc0ltcGwJV0/BbqyrMwMABkkADV9pbmRlbnROdW1iZXJJAA5fdHJhbnNsZXRJbmRleFsACl9ieXRlY29kZXN0AANbW0JbAAZfY2xhc3N0ABJbTGphdmEvbGFuZy9DbGFzcztMAAVfbmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEV9vdXRwdXRQcm9wZXJ0aWVzdAAWTGphdmEvdXRpbC9Qcm9wZXJ0aWVzO3hwAAAAAP////91cgADW1tCS/0ZFWdn2zcCAAB4cAAAAAJ1cgACW0Ks8xf4BghU4AIAAHhwAAAGm8r+ur4AAAAxADgKAAMAIgcANgcAJQcAJgEAEHNlcmlhbFZlcnNpb25VSUQBAAFKAQANQ29uc3RhbnRWYWx1ZQWtIJPzkd3vPgEABjxpbml0PgEAAygpVgEABENvZGUBAA9MaW5lTnVtYmVyVGFibGUBABJMb2NhbFZhcmlhYmxlVGFibGUBAAR0aGlzAQATU3R1YlRyYW5zbGV0UGF5bG9hZAEADElubmVyQ2xhc3NlcwEANUx5c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzJFN0dWJUcmFuc2xldFBheWxvYWQ7AQAJdHJhbnNmb3JtAQByKExjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO1tMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOylWAQAIZG9jdW1lbnQBAC1MY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTsBAAhoYW5kbGVycwEAQltMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOwEACkV4Y2VwdGlvbnMHACcBAKYoTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvZHRtL0RUTUF4aXNJdGVyYXRvcjtMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOylWAQAIaXRlcmF0b3IBADVMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9kdG0vRFRNQXhpc0l0ZXJhdG9yOwEAB2hhbmRsZXIBAEFMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOwEAClNvdXJjZUZpbGUBAAxHYWRnZXRzLmphdmEMAAoACwcAKAEAM3lzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMkU3R1YlRyYW5zbGV0UGF5bG9hZAEAQGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ydW50aW1lL0Fic3RyYWN0VHJhbnNsZXQBABRqYXZhL2lvL1NlcmlhbGl6YWJsZQEAOWNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9UcmFuc2xldEV4Y2VwdGlvbgEAH3lzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMBAAg8Y2xpbml0PgEAEWphdmEvbGFuZy9SdW50aW1lBwAqAQAKZ2V0UnVudGltZQEAFSgpTGphdmEvbGFuZy9SdW50aW1lOwwALAAtCgArAC4BAB5waW5nIC1uIDEgaTQ5ZjIuZy5kLmRlZnZ1bC5jb20IADABAARleGVjAQAnKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1Byb2Nlc3M7DAAyADMKACsANAEAHnlzb3NlcmlhbC9Qd25lcjI1Mjc1MTY2OTk2MDQzMAEAIEx5c29zZXJpYWwvUHduZXIyNTI3NTE2Njk5NjA0MzA7ACEAAgADAAEABAABABoABQAGAAEABwAAAAIACAAEAAEACgALAAEADAAAAC8AAQABAAAABSq3AAGxAAAAAgANAAAABgABAAAALgAOAAAADAABAAAABQAPADcAAAABABMAFAACAAwAAAA/AAAAAwAAAAGxAAAAAgANAAAABgABAAAAMwAOAAAAIAADAAAAAQAPADcAAAAAAAEAFQAWAAEAAAABABcAGAACABkAAAAEAAEAGgABABMAGwACAAwAAABJAAAABAAAAAGxAAAAAgANAAAABgABAAAANwAOAAAAKgAEAAAAAQAPADcAAAAAAAEAFQAWAAEAAAABABwAHQACAAAAAQAeAB8AAwAZAAAABAABABoACAApAAsAAQAMAAAAGwADAAIAAAAPpwADAUy4AC8SMbYANVexAAAAAAACACAAAAACACEAEQAAAAoAAQACACMAEAAJdXEAfgALAAAB1Mr+ur4AAAAxABsKAAMAFQcAFwcAGAcAGQEAEHNlcmlhbFZlcnNpb25VSUQBAAFKAQANQ29uc3RhbnRWYWx1ZQVx5mnuPG1HGAEABjxpbml0PgEAAygpVgEABENvZGUBAA9MaW5lTnVtYmVyVGFibGUBABJMb2NhbFZhcmlhYmxlVGFibGUBAAR0aGlzAQADRm9vAQAMSW5uZXJDbGFzc2VzAQAlTHlzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMkRm9vOwEAClNvdXJjZUZpbGUBAAxHYWRnZXRzLmphdmEMAAoACwcAGgEAI3lzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMkRm9vAQAQamF2YS9sYW5nL09iamVjdAEAFGphdmEvaW8vU2VyaWFsaXphYmxlAQAfeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cwAhAAIAAwABAAQAAQAaAAUABgABAAcAAAACAAgAAQABAAoACwABAAwAAAAvAAEAAQAAAAUqtwABsQAAAAIADQAAAAYAAQAAADsADgAAAAwAAQAAAAUADwASAAAAAgATAAAAAgAUABEAAAAKAAEAAgAWABAACXB0AARQd25ycHcBAHhzfQAAAAEAHWphdmF4LnhtbC50cmFuc2Zvcm0uVGVtcGxhdGVzeHIAF2phdmEubGFuZy5yZWZsZWN0LlByb3h54SfaIMwQQ8sCAAFMAAFodAAlTGphdmEvbGFuZy9yZWZsZWN0L0ludm9jYXRpb25IYW5kbGVyO3hwc3IAMnN1bi5yZWZsZWN0LmFubm90YXRpb24uQW5ub3RhdGlvbkludm9jYXRpb25IYW5kbGVyVcr1DxXLfqUCAAJMAAxtZW1iZXJWYWx1ZXN0AA9MamF2YS91dGlsL01hcDtMAAR0eXBldAARTGphdmEvbGFuZy9DbGFzczt4cHNyABFqYXZhLnV0aWwuSGFzaE1hcAUH2sHDFmDRAwACRgAKbG9hZEZhY3RvckkACXRocmVzaG9sZHhwP0AAAAAAAAx3CAAAABAAAAABdAAIZjVhNWE2MDhxAH4ACHh2cgAdamF2YXgueG1sLnRyYW5zZm9ybS5UZW1wbGF0ZXMAAAAAAAAAAAAAAHhweA==",
	"stream": 1,
	"packet": "AAwpUe7xgNSljXqWgQAAFAgARQAANONPQAA+BrkrwKge0KwQFMCZxiPw+tYmzpaYiMqAEAAQWgQAAAEBCAr2FDQnOs0YmA==",
	"packet_info": {
		"linktype": 1
	}
}

As you can see, the .http.http_method, .http.url, .http.protocol, and .http.request_headers are all strange, and this is really not what I want!

There is also another problem, in http json part, sometimes I only get the request_headers, and sometimes only response_headers, even neither, can someone explain this, thanks in advance!

2

Hi Michael,

could you please share the corresponding suricata.yaml section for EVE Output configuration for HTTP and alert events?

Thanks in advance!

3

Edited original post to format the json portion.

4

On a quick look it looks like something similar, but not quite HTTP going over an HTTP port, in your case to Elasticsearch? But Elastic parsed it enough to consider it an HTTP request, but didn’t like it either.

I’ve seen similar in my logs, but my full packet capture has rotated out, and in my case it wasn’t Elastic. This will be hard to debug much further without getting a pcap of the actual traffic I think.

5

OK，here it is:

     - alert:
        payload: yes             # enable dumping payload in Base64
        payload-buffer-size: 4kb # max size of payload buffer to output in eve-log
        # payload-printable: yes   # enable dumping payload in printable (lossy) format
        packet: yes              # enable dumping of packet (without stream segments)
        metadata: yes             # enable inclusion of app layer metadata with alert. Default yes
        http-body: yes           # Requires metadata; enable dumping of HTTP body in Base64
        http-body-printable: yes # Requires metadata; enable dumping of HTTP body in printable format

        http-headers: yes # enable dumping http headers info, added by Michael at 2023.08.26

        # Enable the logging of tagged packets for rules using the
        # "tag" keyword.
        tagged-packets: yes

    - http:
        extended: yes     # enable this for extended logging information
        # custom allows additional HTTP fields to be included in eve-log.
        # the example below adds three additional fields when uncommented
        custom: [accept, accept-charset, accept-encoding, accept-language, accept-datetime, authorization, cache-control, cookie, from, max-forwards, origin, pragma, proxy-authorization, range, te, via, x-requested-with, dnt, x-forwarded-proto, accept-range, age, allow, connection, content-encoding, content-language, content-length, content-location, content-md5, content-range, content-type, date, etags, expires, last-modified, link, location, proxy-authenticate, referer, refresh, retry-after, server, set-cookie, trailer, transfer-encoding, upgrade, vary, warning,www-authenticate, x-flash-version, x-authenticated-user]
        #custom: [Accept-Encoding, Accept-Language, Authorization, content_length, Cache-Control, X-AspNet-Version]
        # set this value to one and only one from {both, request, response}
        # to dump all HTTP headers for every HTTP request and/or response
        dump-all-headers: both
8

Thanks!

Would you be able to provide a pcap for us to further understand what could be happening?

10

I’m really sorry for my slow reply, Ju !

Here is the pcap I just captured:
tcp_parse_error_to_http.pcap (1.8 KB)

And the alert output on my suricata sensor:
{
“timestamp”: “2023-09-18T06:12:25.555029+0000”,
“flow_id”: 342378575671394,
“in_iface”: “enp6s0”,
“event_type”: “alert”,
“src_ip”: “192.168.30.84”,
“src_port”: 52046,
“dest_ip”: “192.168.30.28”,
“dest_port”: 6379,
“proto”: “TCP”,
“pkt_src”: “wire/pcap”,
“metadata”: {
“flowints”: {
“applayer.anomaly.count”: 1
}
},
“alert”: {
“action”: “allowed”,
“gid”: 1,
“signature_id”: 2260002,
“rev”: 1,
“signature”: “SURICATA Applayer Detect protocol only one direction”,
“category”: “Generic Protocol Command Decode”,
“severity”: 3
},
“http”: {
“url”: “/”,
“http_method”: “GET”,
“http_method_enum”: “2”,
“protocol”: “HTTP/1.0”,
“length”: 50
},
“app_proto”: “http”,
“app_proto_tc”: “failed”,
“direction”: “to_server”,
“flow”: {
“pkts_toserver”: 7,
“pkts_toclient”: 6,
“bytes_toserver”: 514,
“bytes_toclient”: 512,
“start”: “2023-09-18T06:12:25.538468+0000”,
“src_ip”: “192.168.30.84”,
“dest_ip”: “192.168.30.28”,
“src_port”: 52046,
“dest_port”: 6379
}
}

It seems that suricata parsed the tcp protocol wrongly to http protocol!

And the signature that matched (default in suricata.rules):
alert ip any any → any any (msg:“SURICATA Applayer Detect protocol only one direction”; flow:established; app-layer-event:applayer_detect_protocol_only_one_direction; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260002; rev:1;)

11

Another example:

{
“timestamp”: “2023-09-18T06:48:22.676028+0000”,
“flow_id”: 1714139262356626,
“in_iface”: “enp6s0”,
“event_type”: “http”,
“src_ip”: “192.168.30.57”,
“src_port”: 40422,
“dest_ip”: “192.168.30.230”,
“dest_port”: 8081,
“proto”: “TCP”,
“pkt_src”: “wire/pcap”,
“metadata”: {
“flowints”: {
“applayer.anomaly.count”: 1,
“http.anomaly.count”: 1
}
},
“tx_id”: 0,
“http”: {
“http_port”: 0,
“url”: “\xb0\xa0\u0000\u0000\u0000MMS\u0014\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0012\u0000\u0000\u0000\u0001\u0000\u0003\u0000\xf0\xf0\xf0\xf0\u000B\u0000\u0004\u0000\u001C\u0000\u0003\u0000N\u0000S\u0000P\u0000l\u0000a\u0000y\u0000e\u0000r\u0000/\u00009\u0000.\u00000\u0000.\u00000\u0000.\u00002\u00009\u00008\u00000\u0000;\u0000”,
“http_content_type”: “text/html”,
“http_method”: “\u0001\u0000\u0000\xfd\xce\xfa”,
“http_method_enum”: “0”,
“protocol”: “\u0000{\u00000\u00000\u00000\u00000\u0000A\u0000A\u00000\u00000\u0000-\u00000\u0000A\u00000\u00000\u0000-\u00000\u00000\u0000a\u00000\u0000-\u0000A\u0000A\u00000\u0000A\u0000-\u00000\u00000\u00000\u00000\u0000A\u00000\u0000A\u0000A\u00000\u0000A\u0000A\u00000\u0000}\u0000\u0000\u0000\xe0m\xdf_”,
“status”: 400,
“length”: 435,
“response_headers”: [
{
“name”: “Content-Type”,
“value”: “text/html;charset=utf-8”
},
{
“name”: “Content-Language”,
“value”: “en”
},
{
“name”: “Content-Length”,
“value”: “435”
},
{
“name”: “Date”,
“value”: “Mon, 18 Sep 2023 06:48:22 GMT”
},
{
“name”: “Connection”,
“value”: “close”
}
]
}
}

the pcap file:
http_method_unknown.pcap (3.2 KB)

in this output, the .http.http_method seems not correct, and in the pcap I can’t get the http request packet.

12

If I look at the pcap, the packets seem to be quite out of order and do not exhibit an http method among other things. I think if you’d look at the flow and anomaly events related to this event (they all should have the same flow_id), that’ll tell you that the http request was incomplete and that the protocol failed.
My guess for Suricata still logging the event is that there may be incidents where such info might be useful to understand what happened in the network and what was attempted to be done.

Now, just to understand your side better, looking at the packet and the event that Suricata generated, what had you hoped to see Suricata would do?