MikroTik RouterOS: Detecting and blocking IP addresses pinged by IoT devices

Recently while analyzing connections leaving my network, I noticed a “wi-fi extender” device (just a stripped-down WAP) that I’ve acquired was generating a lot of ICMP packets going to various IP addresses. That inspired this post outlining the method I used to track and block which IPs the device attempts to reach, utilizing the tools built into RouterOS. The same methods can apply to any device or host behind your Mikrotik router that you want to track.

First, the full pair of firewall filters. To block an individual device from pinging anything outside your network:

/ip firewall filter
add action=add-dst-to-address-list\
  address-list="BrosTrend IPs"\
  address-list-timeout=none-static\
  chain=forward\
  comment="Pinged by BrosTrend"\
  protocol=icmp\
  src-mac-address=XX:XX:XX:XX:XX:XX
add action=drop\
  chain=forward\
  comment="Drop BrosTrend IPs"\
  dst-address-list="BrosTrend IPs"\
  src-mac-address=XX:XX:XX:XX:XX:XX

Where XX:XX:XX:XX:XX:XX in src-mac-address is the device’s MAC address.

Explanation

Together, these two filters will create an address-list containing each IP address the device tries to ping, and then drop any packets the device sends to said addresses. If you’re not using a cloud controller like Meraki/Unifi gear, then a simple access point or “wi-fi extender” like this doesn’t have any reason to need an internet connection, so you could easily just put it on an untrusted VLAN or block it off with one simple filter and be done with it. But I feel like digging a little bit.

The first filter:

action=add-dst-to-address-list address-list="BrosTrend IPs" address-list-timeout=none-static chain=forward protocol=icmp src-mac-address=XX:XX:XX:XX:XX:XX comment="Pinged by BrosTrend"

This filter will create an address list named "BrosTrend IPs" and add each address to it that the BrosTrend device attempts to ping (or send any other ICMP packet to). You don’t need to create the address list first, as RouterOS will create it when a packet is matched.
address-list-timeout=none-static – An address list action can have a timeout, though I’ll set it to none in this case, and make it static since the addresses seem to be hardcoded in the extender device’s firmware and thus won’t change. If you set the timeout to none-dynamic, then each entry will only be stored until the next reboot. The other values are self-explanatory, if you’re familiar with RouterOS.

The second filter:

add action=drop chain=forward comment="Drop BrosTrend IPs" dst-address-list="BrosTrend IPs" src-mac-address=XX:XX:XX:XX:XX:XX

This filter will drop any packet sent from the target device to an IP that is found in the address-list created by the first filter (named BrosTrend IPs).

Findings

By observing the “BrosTrend IPs” address-list after some time, we can see there are 8 IP addresses that the device contacts, which comes out to an even 32 bytes of storage on the device:

• 119.29.29.29
• 180.76.76.76
• 223.5.5.5
• 114.114.114.114
• 120.25.108.11
• 108.59.2.24
• 212.47.249.141
• 129.6.15.28

Looking up the IPs on AbuseIPDb and ipinfo.io among other sources, the first 4 addresses look like Chinese DNS servers on netblocks owned by Baidu & Tencent, which is typical of a device like this checking for connectivity, though most of these blocks seem to be associated with various automated scanning and probing (possibly GFW-related?) so we’ll go ahead and block them anyways. The other 4 are NTP servers in China, France and the US, including a US NIST server. Ironically enough, NIST’s web page listing their time servers offers some solid advice against hardcoding time servers. The developers of this device’s firmware apparently didn’t get the memo. Anyways, I run my own NTP server so these aren’t necessary either; though if needed, the NIST server is probably trustworthy enough to allow.

Conclusions

In all, after inspecting some traffic a little further in Wireshark (RouterOS’s packet sniffer is a great feature), the BrosTrend device doesn’t seem to be doing anything nefarious- no ICMP exfiltration or other shenanigans stand out. Regardless, I still prefer to not allow networking equipment or other IoT devices to have WAN access simply because it doesn’t need it. Maybe I’ll cover untrusted VLANs or one-way VLAN routing in RouterOS in a future post.