Open GitSweendog opened 6 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Any thoughts on this Elastic folks? Would rather not have this issue auto-closed because of a lack of response
I second that.
Pinging @elastic/security-external-integrations (Team:Security-External Integrations)
This would be super useful. Having this in telecom networks sending SIP off to elastic would be pretty great.
Any updates on this issue. I've got a similar problem where I have raw data being sent to elastic over a GRE tunnel, but have no way of getting the data processed in Elastic. Would standing up a server in between running Packetbeat resovle this issue?
watching
Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform)
We've used Packetbeat for many purposes, and appreciate the ability to generate JSON data directly off the wire. Normally, we can place a network sniffer running beats right on a system connected to a span or tap to get the data we need, but in some cases, we want to use a remote sensor.
Several switch, router, and network aggregation and monitoring equipment (Gigamon, Cisco, Aruba etc.) can transmit locally monitored traffic over a layer 2 transport GRE tunnel. Essentially, a GRE connection is nailed up between the local system (Sniffer, Gigamon, etc.) and all traffic seen on the monitor port is encapsulated in GRE and sent up to the remote host.
The entire layer two (Ethernet) packets are included in the tunnel, so all that should need be done is to strip or ignore the first 37 bytes of data, which will expose a full frame. Then Packetbeat could work as normal when reassembling flows and decoding the protocol traffic.
Below is a screenshot of a Wireshark dissection of a sample DNS query encapsulated in GRE.