Project

General

Profile

Actions
Copy link

Bug #1711

closed

eve: Ethernet Header Missing From Packet Field

Added by D T about 8 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

Hello,

I am seeing an issue where the Ethernet headers are not present in the JSON packet field. I am seeing this issue across two different platforms using two different traffic acquisition methods.

FreeBSD:
10.2-RELEASE-p12
NIC: Intel(R) PRO/1000 Network Connection 7.4.2
Suricata 3.0_1 from ports
Suricata is bound to the external VLAN interface:
/usr/local/bin/suricata -D -i vlan30 --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml

Ubuntu:
12.04
Suricata 3.0
af-packet
Suricata is acquiring data via an in-line TAP.

Sample:
00000000 45 00 00 28 00 00 00 00 40 06 c7 ae ae 6d a5 ce |E..(....@....m..|
00000010 c6 33 98 b2 f6 22 00 50 ca 47 11 f0 4e 1b dc e6 |.3...".P.G..N...|
00000020 50 10 0a 00 f5 05 00 00 |P.......|
00000028

{"timestamp":"2016-02-05T20:50:44.006188-0500","flow_id":2264548352,"event_type":"alert","src_ip":"174.109.165.206","src_port":63010,"dest_ip":"198.51.152.178","dest_port":80,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2260001,"rev":1,"signature":"SURICATA Applayer Wrong direction first Data","category":"Generic Protocol Command Decode","severity":3},"stream":0,"packet":"RQAAKAAAAABABseurm2lzsYzmLL2IgBQykcR8E4b3OZQEAoA9QUAAA=="}

This issue does not seem to be associated with any particular protocol as I have observed the same behavior with SMTP, HTTP, LDAP, HTTPS, etc.

Related issues 1 (0 open — 1 closed)

Related to Suricata - Feature #962: Can I log the mac address of the source?ClosedSascha SteinbissActions
Actions
Copy link
 #1

Updated by D T about 8 years ago

Clarification: this does not happen with ALL packets, but some.

Actions
Copy link
 #2

Updated by Victor Julien about 8 years ago

Most likely this would be the logging of fake 'pseudo' packets that we use to handle flow timeouts and a couple of other conditions.

Actions
Copy link
 #3

Updated by Andreas Herz over 7 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions
Copy link
 #4

Updated by Alexander Gozman over 7 years ago

Victor Julien wrote:

Most likely this would be the logging of fake 'pseudo' packets that we use to handle flow timeouts and a couple of other conditions.

Does it mean that PKT_IS_PSEUDOPKT macro call is missing when logging alerts?

Actions
Copy link
 #5

Updated by Victor Julien over 7 years ago

What would that do? I think the issue simply is that the pseudo packets don't have an ethernet layer.

Actions
Copy link
 #6

Updated by Alexander Gozman over 7 years ago

Victor Julien wrote:

What would that do? I think the issue simply is that the pseudo packets don't have an ethernet layer.

Is there a way to filter it out? Maybe check ethh field in the Packet structure... We also see such packets in logs sometimes and I suppose that there's no need to log them.

Actions
Copy link
 #7

Updated by Alexander Gozman over 7 years ago

Or we shouldn't try to throw anything away?

Actions
Copy link
 #8

Updated by Victor Julien over 7 years ago

We'd loose the alert record, I don't think that is acceptable. Maybe we can not add the 'packet' at all, but I'm not convinced that is the solution either. I haven't checked, but in recent code we should add a datalink type as well. It should be set to 'raw' for pseudo packets, even if the capture method's data link is ethernet. Not sure if that is functional currently.

Actions
Copy link
 #9

Updated by Andreas Herz almost 5 years ago

What should we do with that issue?

Actions
Copy link
 #10

Updated by Victor Julien almost 5 years ago

  • Related to Feature #962: Can I log the mac address of the source? added
Actions
Copy link
 #11

Updated by Victor Julien almost 5 years ago

I think if we implement https://redmine.openinfosecfoundation.org/issues/962#note-8 we will have enough information to also construct a Ethernet layer in the packet field

Actions
Copy link
 #12

Updated by Victor Julien over 2 years ago

  • Subject changed from Ethernet Header Missing From JSON Packet Field to eve: Ethernet Header Missing From Packet Field
Actions
Copy link
 #13

Updated by Victor Julien over 2 years ago

  • Status changed from New to Closed
  • Assignee deleted (OISF Dev)
  • Target version deleted (TBD)

We've added a linktype field to indicate the link type. For pseudo packets this will be RAW, while for real ethernet packets it will be ETHERNET. This way a consuming tool can know that in the RAW case the data starts with an IP header. I think this is enough to close this ticket.

I'm still unsure about crafting a Ethernet header with a pseudo packet, as we can have 1-N MAC addresses in a flow per direction, so it would add some complexity around which MAC address to choose.

Actions
Copy link

Also available in: Atom PDF