Find the network host location
Find the network host location
I possess the IP addresses, but the sole MAC is from the forwarding gateway—the interface of our core router. It seems to reside in a separate broadcast domain, causing the original MAC to disappear each time it reaches another LAN segment. The logs from IDS/IPS, the firewall, and my sinkhole only capture DNS queries that fail to register the device name with our DHCP. What remains are just RFC1918 addresses and the domain it’s trying to resolve, which has been normal traffic for Microsoft and NSCI servers during that period. The IP appears largely irrelevant because the subnet it uses doesn’t exist in my setup.
Are there any virtual interfaces or IP addresses set up accidentally in the forwarding gateway?
The forwarding interface lacks virtual interfaces, but the ingress interface does. I’m unable to provide any logs due to restrictions. The data I have includes only IP, MAC addresses and DNS query details from the sinkhole, which isn’t much beyond that. I’m sorry for the inconvenience!
That's clear, I get it. I handle some isolated networks and share similar challenges. I enjoy the detective work, though I wish I could be there to follow those devices directly. It seems they're using Windows-based systems, which is generating a lot of network activity. No junior IT staff at the remote locations?
I usually enjoy digging into any kind of investigation, but these days it tends to move up the chain a bit. This is the first task I’ve managed on my own lately because of other busy projects. It’s basically about a Windows device making noise that caught my interest. Our field support crew just got three new green engineers on the job, and I’ve already prepared my usual “this network isn’t your playground” comment. I’m still a bit unsure, but I have some surprise posture checks coming up next week to confirm their reports. We’ll find out what happens then.
A properly executed 802.1X setup places minimal strain and likely saved you a lot of time. A centralized syslog server would also be beneficial, allowing logs to be sent to Greylog for full indexing and easy searching of useful data. However, these solutions aren't very helpful right now since we can't implement tools to assist further. What's going on here? Shouldn't you be able to trace each forwarding device through ARP tables as it happens? It seems unusual that you can't do that or at least narrow down the network segment. With the details you have about your network and routing tables, is there a more probable source segment? Would every segment permit this source IP to reach the destination, or would it be redirected elsewhere based on its origin? Often it's simpler to rule out impossible paths before proceeding.
Sorry for the delay, but I just reviewed the post here, @Tzomb1e. You need to set up DHCP relay with option 82 on the server, ensuring every static address is covered. Option 82 works by encapsulating switch/router TLV data directly to the server. This method acts as a sudo authentication and provides precise details about any malicious device. The DHCP records every lease, linking it to the switch/router hostname, IP, VLAN and port. This simplifies tracking DHCP clients since the lease reveals the exact device and port. As an ISP, we must comply with legal requirements for this level of tracking to verify authentication and protect customers. While better software options exist, I haven’t pursued that path yet. For static devices, dot1x tracking is essential and unavoidable.