So last night while playing around with my router trying to get it running as an OpenVPN Server (which was nothing but an all-day, bang-your-head-against-the-wall kind of experience since, from what I can tell reading multiple sites about Mikrotik, does not have a solid OpenVPN server package) I noticed this little gem in my Squert console via Security Onion:
Since this was nothing but UDP packets, SO is not going to give me the full skinny like it would for HTTP traffic and the such. But thankfully we can use the integration that Squert has with ELSA (pulling in Bro logs about connections and DNS requests) to take a different look into this as you can see below:
So since the 21st of April till now (at the time of this writing) there have been 9147 DNS calls and 4637 connection attempts and I am just now seeing this alert fire from Snort? Needless to say this was odd and a wee bit interesting. Time to see what I could find out…
First thing that I looked at was the reference link in the actual Snort rule (en.wikipedia.org/wiki/Xunlei) to see if that would help. Based on what the wiki link I seriously doubted that my wife would install anything like a download-manager/P2P application on her laptop since she is setup as a regular “user” on the laptop and requires “admin” rights to install such things (which I would have heard all kinds of grumbling about). With that lead out the window I did some more looking around (especially in ELSA). ELSA gave me some more insight into which systems (since there were a couple of others making the same type of calls to this IP address/port combination), but nothing like a smoking gun (that I saw at that time). So off to the magic 8-ball known as Google.
Googling around I found some interesting links, but this one (which then lead me to this one) sounded like it was the best contender considering the fact that you see the name ‘Kristis-Laptop’ in the payload of the packet:
LLMNR queries are sent to and received on port 5355. The IPv4 link-
scope multicast address a given responder listens to, and to which a
sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
address a given responder listens to, and to which a sender sends all
queries, is FF02:0:0:0:0:0:1:3.Responders MUST listen on UDP port 5355 on the link-scope
multicast address(es) defined in Section 2, and on TCP port 5355
on the unicast address(es) that could be set as the source
address(es) when the responder responds to the LLMNR query.
The interesting thing is that I did not realize that the 224.0.0.0/8 was considered the multicast address; in particular 224.0.0.252 being the IP address of Link-local Multicast Name Resolution (LLMNR) address.
Mystery solved now and alert cleared. Phew!