-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SIEM] Add DNS enrichment to system/socket dataset #14004
Conversation
Pinging @elastic/siem (Team:SIEM) |
999b4e7
to
43e9a63
Compare
This patch adds DNS monitoring to the system/socket dataset so that events can be enriched with domain names. Its been implemented using af_packet so that filtering can be used at the kernel level and only DNS responses are copied to userspace. In the future it might be possible to use a kprobes-based implementation which will make correlating DNS requests to processes much easier, but we need to find out how to filter DNS requests at kprobe level, given that sometimes is necessary to inspect the packet to obtain the source port.
433a8dd
to
158328e
Compare
jenkins, test this |
@@ -804,6 +925,15 @@ func (f *flow) toEvent(final bool) (ev mb.Event, err error) { | |||
metricset["euid"] = f.process.euid | |||
metricset["egid"] = f.process.egid | |||
} | |||
|
|||
if resolver != nil { | |||
if domain, found := resolver.ResolveIP(f.pid, f.local.addr.IP); found { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So does this enrichment happen at the end of the "connection"?
I'm thinking about the case of a long running connection where it does an initial DNS query then keeps the connection open for hours. So it might be better to do the enrichment with domain as soon as we have the endpoints of the socket available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch, that was an oversight on my side. Thanks for catching. I've refactored it so that reverse DNS is stored by process.
|
||
// RegisterEndpoint registers a new local endpoint used for DNS queries | ||
// to correlate captured DNS packets with their originator process. | ||
func (dt *dnsTracker) RegisterEndpoint(addr net.UDPAddr, pid uint32) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's great that it stores the info based on PID.
This refactor avoids having to store the transactions by PID and avoids expiration issues because the *process is kept around until the process terminates.
This patch adds DNS monitoring to the system/socket dataset so that events can be enriched with domain names. Its been implemented using af_packet so that filtering can be used at the kernel level and only DNS responses are copied to userspace. In the future it might be possible to use a kprobes-based implementation which will make correlating DNS requests to processes much easier, but we need to find out how to filter DNS requests at kprobe level, given that sometimes is necessary to inspect the packet to obtain the source port. (cherry picked from commit ed9dba5)
This patch adds DNS monitoring to the system/socket dataset so that events can be enriched with domain names.
Its been implemented using af_packet so that filtering can be used at the kernel level and only DNS responses are copied to userspace.
In the future it might be possible to use a kprobes-based implementation which will make correlating DNS requests to processes much easier, but we need to find out how to filter DNS requests at kprobe level, given that sometimes is necessary to inspect the packet to obtain the source port.