Project

General

Profile

Actions
Copy link

Bug #1711

closed
DT

eve: Ethernet Header Missing From Packet Field

Bug #1711: eve: Ethernet Header Missing From Packet Field

Added by D T about 10 years ago. Updated over 4 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

DT Updated by D T about 10 years ago Actions
Copy link
 #1

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

VJ Updated by Victor Julien about 10 years ago Actions
Copy link
 #2

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

AH Updated by Andreas Herz over 9 years ago Actions
Copy link
 #3

  • Assignee set to OISF Dev
  • Target version set to TBD

AG Updated by Alexander Gozman over 9 years ago Actions
Copy link
 #4

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?

VJ Updated by Victor Julien over 9 years ago Actions
Copy link
 #5

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

AG Updated by Alexander Gozman over 9 years ago Actions
Copy link
 #6

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.

AG Updated by Alexander Gozman over 9 years ago Actions
Copy link
 #7

Or we shouldn't try to throw anything away?

VJ Updated by Victor Julien over 9 years ago Actions
Copy link
 #8

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.

AH Updated by Andreas Herz almost 7 years ago Actions
Copy link
 #9

What should we do with that issue?

VJ Updated by Victor Julien over 6 years ago Actions
Copy link
 #10

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

VJ Updated by Victor Julien over 6 years ago Actions
Copy link
 #11

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

VJ Updated by Victor Julien over 4 years ago Actions
Copy link
 #12

  • Subject changed from Ethernet Header Missing From JSON Packet Field to eve: Ethernet Header Missing From Packet Field

VJ Updated by Victor Julien over 4 years ago Actions
Copy link
 #13

  • 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: PDF Atom