[
https://issues.apache.org/jira/browse/METRON-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983190#comment-15983190
]
ASF GitHub Bot commented on METRON-854:
---------------------------------------
Github user simonellistonball commented on the issue:
https://github.com/apache/incubator-metron/pull/531
As an alternative method for getting DHCP data out of pcap, you might
consider the existing Bro sensor, which essentially does what dhcpdump does,
but for a wider range of protocols, in a more sophisticated way. We also
already have a built in parser.
That said it would great to have this parser too for people not looking for
the full range of bro.
The multi-line aspect may not be an issue. The boundary for Metron is the
Kafka message, not really the line, so if you can split the log into multi-line
chunks prior to kafka, potentially with something like NiFi based on a
delimiter. The way to do this is to use nifi to insert a true delimiter (not
end of line) and then use the SplitContent to send individual log entries via
kafka. It's a little heavy, but solves the multi-line problem as long as you're
not going to crazy levels of throughput e.g. hundreds of thousands of EPS.
> Create DHCPDump Parser
> ----------------------
>
> Key: METRON-854
> URL: https://issues.apache.org/jira/browse/METRON-854
> Project: Metron
> Issue Type: New Feature
> Reporter: Bas van de Lustgraaf
> Priority: Minor
> Labels: parser
>
> Create a DHCPDump parser. This information can be used during enrichment to
> link ip-addresses to hostnames.
> {noformat}
> TIME: 2017-01-16 16:54:21.655|INTERFACE: eth2|OP:1 BOOTPREQUEST|CIADDR:
> 172.20.75.77|YIADDR: 0.0.0.0|SIADDR: 0.0.0.0|GIADDR: 172.20.75.8|CHADDR:
> fc:f8:ae:e8:ef:db:00:00:00:00:00:00:00:00:00:00|OPTION: 53 1 DHCP message
> type: 8 |DHCPINFORM|OPTION: 61 7 Client-identifier:
> 01:fc:f8:ae:e8:ef:db|OPTION: 12 5 Host name: Q1244|OPTION: 60 8 Vendor
> class identifier: MSFT 5.0|OPTION: 55 13 Parameter Request List: 1
> (Subnet mask)|| 15 (Domainname)|| 3 (Routers)|| 6 (DNS server)|| 44
> (NetBIOS name server)|| 46 (NetBIOS node type)|| 47 (NetBIOS scope)|| 31
> (Perform router discovery)|| 33 (Static route)||121 (Classless Static
> Route)||249 (MSFT - Classless route)|| 43 (Vendor specific info)||252 (MSFT -
> WinSock Proxy Auto Detect)|||IP: 10.10.10.177 > 172.20.1.11 |
> b8:ca:3a:67:95:8a > 0:50:56:84:68:43
> TIME: 2017-01-16 17:13:14.548|INTERFACE: eth2|OP:1 BOOTPREQUEST|CIADDR:
> 172.20.75.77|YIADDR: 0.0.0.0|SIADDR: 0.0.0.0|GIADDR: 172.20.75.8|CHADDR:
> fc:f8:ae:e8:ef:db:00:00:00:00:00:00:00:00:00:00|OPTION: 53 1 DHCP message
> type: 8 |DHCPINFORM|OPTION: 61 7 Client-identifier:
> 01:fc:f8:ae:e8:ef:db|OPTION: 12 5 Host name: Q1244|OPTION: 60 8 Vendor
> class identifier: MSFT 5.0|OPTION: 55 13 Parameter Request List: 1
> (Subnet mask)|| 15 (Domainname)|| 3 (Routers)|| 6 (DNS server)|| 44
> (NetBIOS name server)|| 46 (NetBIOS node type)|| 47 (NetBIOS scope)|| 31
> (Perform router discovery)|| 33 (Static route)||121 (Classless Static
> Route)||249 (MSFT - Classless route)|| 43 (Vendor specific info)||252 (MSFT -
> WinSock Proxy Auto Detect)|||IP: 10.10.10.177 > 172.20.1.10 |
> b8:ca:3a:67:95:8a > 0:50:56:b9:28:ac
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
