1

Just reviewing some logs and I am seeing local scans to several local IP addresses on port 137 within my network. The source IP however is the broadcast IP of the VLAN (.255).

I have checked the logs and I can see the broadcast IP trying to initiate udp 137 connections on several other IP addresses of the same subnet.

Many of the errors being shown are "The Windows Filtering Platform has blocked a connection".

I cant really make sense of the Source IP address being the broadcast IP. Has anyone come across this before please? and from your experiences, where should I be looking that I could have missed? Thanks.

  • "reviewing logs" of what? Where in the network layout is this log capture being made? How are you concluding that they are "scans"? Is the network mask 255.255.255.0? (.255 can be a valid host IP in some networks) Have you done an ARP lookup to see if this IP has a host? This is looking more like a networking troubleshooting question than a security question. – schroeder Jan 6 at 18:08
0

It is possible to source a packet with an arbitrary IP address, even an invalid IP address. This is commonly done with DDOS attacks.

For scanning to be effective, the scanner needs to get the response traffic back. If the scan came from 192.168.2.255, and if the network was 192.168.2.0/24, then the response would be broadcast on that subnet and every host on that subnet (including possibly the scanner) would see the response.

To identify the scanner, look at the Ethernet header of an inbound scan on the originating subnet, and look for the source MAC address.

Long ago, “IP directed broadcast” was enabled by default on Cisco routers. My company used to synchronize time by broadcasting NTP updates to the class B directed broadcast address for our site (similar to 172.16.255.255). The NTP update would flood my class-B.

For the past two decades, “no IP directed broadcast” has been default on Cisco (and presumably other vendor) routers, for obvious security reasons.

192.168.2.255 is a perfectly valid IP address if the originating subnet is 192.168.2.0/23. The intermediate routers and your host have no idea if 192.168.2.255 is valid unless they are directly on that subnet.

It is good that the windows filtering platform is blocking and logging some of this. “Do not accept packets where the source IP is the broadcast IP of a directly attached subnet” sounds like a good rule. “Do not accept packets with a multicast source address” would be another good one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.