Is this a discovery attack?

Installing and Using OpenWrt
1

Guys, I've seen this many times in my syslog ...

Tue May 23 16:33:35 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:55667 not from a LAN, ignoring
Tue May 23 16:33:36 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:55667 not from a LAN, ignoring
Tue May 23 16:33:37 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:55667 not from a LAN, ignoring
Tue May 23 16:33:38 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:55667 not from a LAN, ignoring
Tue May 23 16:33:57 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:51436 not from a LAN, ignoring
Tue May 23 16:33:58 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:51436 not from a LAN, ignoring
Tue May 23 16:33:59 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:51436 not from a LAN, ignoring
Tue May 23 16:34:00 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:51436 not from a LAN, ignoring
Tue May 23 16:34:25 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:63353 not from a LAN, ignoring
Tue May 23 16:34:26 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:63353 not from a LAN, ignoring
Tue May 23 16:34:27 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:63353 not from a LAN, ignoring
Tue May 23 16:34:28 2017 daemon.warn miniupnpd[2245]: SSDP packet sender 169.254.5.164:63353 not from a LAN, ignoring

All grouped together in batches ... in the last 48 hours, this has happened just once, but in the past I've seen this many times.

I'm hypothesizing that those "169.x.x,x" packets can be coming from 2 sources:
A) The ISP Router side - BUT ... how did this packages made it through the firewall into miniupnpd?
B) My own internal network - that address is generally auto.assigned when a device can't find a for whatever reason a DHCP server to get an IP address. I'm biased towards thinking that this is not what's happening since all of my devices are working ok and I have all of them mapped to MAC addresses for DHCP assignments.

My paranoid side is telling me it may be someone trying to discover my internal network services ... Ideas?

2

This was discussed here: Latest LEDE 17.01 - problem with firewall or miniupnp? (solved: igmpproxy was the culprit)
The igmpproxy is letting some igmp traffic through the firewall.

3

@wind , good post, thanks!

2 things I would like to get your thoughts on:

A) I had igmpproxy installed but disabled and stopped, so what was described in the article does not seem to be my issue... just in case I've uninstalled it. Let's see if the problem persists
B) Those packets were not coming from my network ... so could this be an outside attempt to discover my network's internal services, or maybe just a misconfigured ISP router?

Thanks in advance!

4

A) If just disabling or uninstalling the igmpproxy is not enough, try restarting the firewall to flush those igmp rules out.

B) While not impossible, you might be right, that without firewall on LAN, a rogue device on lan could connect to miniupnpd on port 1900. Can you:

  • provide your network and subnets layout
  • run "arp" to see if that IP is cached
  • since pinging and tracerouting that 169.254.5.164 IP is going to be fruitless, try the following to rule out the possibility that it's coming from LAN: install and enable igmpproxy to see the warning in the log again. Then, run "iptables" manually to get rid of the rules that process igmp packets. Essentially, if you block igmp traffic on the firewall, but still see the warnings, then it's definitely from LAN.
    An alternative to editing iptables rules - just pull WAN cable out and see if miniupnpd still gets those bad packets.