mDNS and SSDP vulnerabilities a suggestion for devices in the DMZ

[ravenstar68]

The other day I got a letter about a device on my home network responding to Multicast DNS (mDNS) queries from outside my home network.

Other people have received similar letters and also letters discussing Netbios, and SSDP vulnerabilities as well.

These letters come as a result of Virgin Media being contacted by a third party organisation -shadowserver.org  Who send queries out to peoples public facing IP's and see if they get a response back.

Why are Shadowserver doing this?

Quite simply to enable the closing down of exploits that others can use to mount DDOS attacks against internet users.

Devices in the DMZ

In several cases in the mDNS threads we see devices have been placed in the DMZ to facilitate some aspect of internet connectivity.  In several cases these have been PS4's in my own case it was a PC.  The problem is that if a device is in the DMZ - all unsolicited traffic is sent to that device - UNLESS there is a separate port forwarding rule in place.  This exposes any flaw in the way a device handles incoming SSDP and mDNS queries from the internet.

False positive?

Several people have suggested that the letters are sent out based on false positives.  Based on my own experience, I would say this is not correct.  Contacting Shadowserver, I was sent the log of what they found from my IP.  I recognised the culprit straight away as being Airserver, which allows me to stream from my Ipad to my PC.  However the logs can be confusing to the average user.

Port blocking?

Advice from Virgin Media suggests blocking inbound ports in the firewall section.  Unfortunately the Superhub 3 does not have any rules to do this, and some people advise that turning up the firewall breaks their gaming experience.  So we need to consider an alternative method.

Using Port Fowawrding to drop the inbound traffic.

Inbound traffic is evaluated in the following order.

NAT table entry - response to outbound traffic?
Port Forwarding rule
Device in DMZ

So by setting up port forwarding rules to an IP address that doesn't have anything connected we can drop the inbound traffic from the internet side of the network.

This won't affect normal LAN traffic, so devices on the same LAN can still find each other.  I've already done this with mDNS and my IPad can still happily find Airserver on my PC but Shadowserver can no longer find it.

This help article by Virgin Media describes for to Port Forward on the different Hubs

As noted above rules should be set according to the Vulnerability or you can preempt them.  And set them all up.

I currently have mDNS - Port 5353 UDP forwarded to 192.168.0.253
                         SSDP - Port 1900 UDP forwarded to 192.168.0.253

Will this stop a device connecting to the Internet?

No - these services are meant for use on the Local network only.  Devices connecting to the net use other outbound ports to do so.

Ravenstar68

Note: Windows Firewall makes it possible to limit a system to allowing inbound connections from the same LAN.  I've actually done this with Airserver and a number of other mDNS listeners.  However as this won't help people who are not using Windows devices, I feel port forwarding offers the easiest option.

[ravenstar68]

---

@用心棒 wrote:

---

@Vince68 wrote:

⋮
I have had a similar issue in the past which, apparently, was caused by the PS4 in the DMZ and resolved it by forwarding port 5353 to a high port 65535 on the Hub.

⋮

The solution proposed was to forward port 5353 to an unallocated IP address within your LAN, is that what you have done?

---

The solution depended on what the port forwarding mechanics would allow.  Where the hub allowed you to port forward asymmetrically e.g. port 80 -> device port 81.  I chose an existing device with a port of 65535 (which doesn't normally listen for inbound requests - hence the packet gets dropped)

Doing a quick check I believe the Nighthawk that Vince is using does allow the former.

If port forwarding can only be done symmetrically then I recommended forwarding the port to an IP address that wasn't being used.

However @Vince68 reports that when he tries to port forward he's getting conflict errors.

Vince what port forwarding rules are currently showing?

Can you walk us through EXACTLY how you are trying to set up the new rule?  Remember we can't see what you are doing here.

Tim

[ravenstar68]

---

@jem101 wrote:

However we can't really assume that third party routers behave in the same manner - for example the help page for the Asus RT-66 under DMZ, if you take their description at face value, seems to be saying that it forwards ALL unsolicited inbound traffic to the device which you specify as being in the DMZ. Now it could just be poorly worded, but it does sound that if you have a device in the DMZ, the Asus is simply going to ignore the port forward rules and simply forward everything there. It may be that other third-party routers do the same. Another possibility is that if a rule tries to forward traffic to an unresponsive host, then rather than dropping the packets, it forwards them to the DMZ device instead.   

---

Actually you'd hope all third party routers  behave consistently in certain respects.

When allowing traffic you'd normally expect the router to check the following:

1. Returning packet - send packet back to device in NAT table.
2. Unsolicited packet - Port Forwarding rule exists - send packet to device specified using Port Forwarding rule
3. Unsolicited packet - Device in DMZ - send packet to the DMZ device
4. Unsolicited packet - Drop the packet.

Certainly when I tested my Port forwarding rule with the Hub 3, it did do as I expected, i.e. with my PC in the DMZ the mDNS packets were no longer reaching port 5353 on my PC and Windows Firewall was quietly dropping the packet as there was nothing listening on the port the packet arrived at.

I would also remind all third party router owners to check to see if anyone else with their router has experienced anything similar mind you.

Tim

[jem101]

---

@ravenstar68 wrote:

---

@jem101 wrote:

However we can't really assume that third party routers behave in the same manner - for example the help page for the Asus RT-66 under DMZ, if you take their description at face value, seems to be saying that it forwards ALL unsolicited inbound traffic to the device which you specify as being in the DMZ. Now it could just be poorly worded, but it does sound that if you have a device in the DMZ, the Asus is simply going to ignore the port forward rules and simply forward everything there. It may be that other third-party routers do the same. Another possibility is that if a rule tries to forward traffic to an unresponsive host, then rather than dropping the packets, it forwards them to the DMZ device instead.   

---

Actually you'd hope all third party routers  behave consistently in certain respects.

snip...

---

Well yes, but I've been doing this for long enough to know that how you might expect a device to behave like is sometime (often?) not the way it actually does in the real world. I'm used to working with enterprise type firewalls and routers and their definitions of a DMZ has only a passing resemblance to what is called DMZ on domestic routers - so I really wouldn't rule anything out!

Anyhow I'm purely going on what some posters above have claimed, that putting an explicit port forward rule in their routers isn't working, and taking their claims at face value - just idle speculation really.

John

[Vince68]

@用心棒

I have not bee able to as stated in my post due to a port conflict 

[Vince68]

@Ravenstar68

I was simply following the previous advice of forwarding port 5353 to 65534 but I get the error Port conflict with other service.

Service name; MDNS

Service type: UDP

External starting port: 5353

External ending port 65535

Use the same port range for internal port: ticked

Internal IP address: PS4 IP address

As I said on the R7000 I was able to do it never received any emails from VM about MDNS vulnerability. I have not been able to set up the rule since switching to a R8000.

[inkx27]

Sorry to resurrect this one again but I am on a third letter from VM regarding mDNS vulnerability.

I run a webserver with peronal cloud, pihole with recursive DNS (personal DNS server - this is NOT open to public only inside LAN), ssh, openvpn and media server etc. At the moment I have 80,443 (for web and openvpn - using port share option) and ssh port open which is not on 22, 53 or 5353. I also have a PS4 pro in DMZ and hence my interest in this thread and the responses. I also have upnp disabled.

So I have run exhaustive full port scans both on my Virgin IP, website and internal LAN network. From the outside world, 5353 is blocked and the only one open are the ones mentioned above and some ftp ones.

Having read the 5 pages of this thread there appears to be two solutions here.

1) create port forwarding rules for 5353 and 1900 and send them to an un-used ip so they get dumped.

2) find out which device is allowing mDNS which I guess I will need the report from ShadowServer or run more scans from the outside world to check which device is responding and then create port forward for the incoming 5353 and 1900 to a higher port number so they can be dropped.

At the moment I am considering using point 1 above and see if this stops the VM emails if not then I will go down the route of point 2.

Do you have guys generally agree this is the best way forward?

Thanks

V

[ravenstar68]

"I also have a PS4 pro in DMZ"

From checking with other users the PS4 in the DMZ is the issue here.  There's a Spotify mDNS responder that is active even if the Spotify app itself is not installed on the PS4, and it is this that responds to mDNS queries from external sources.  You can test this for yourself if you wish.

The Port Forwarding rule discussed will stop the external queries reaching your LAN while still allowing devices on the LAN itself to use mDNS

Tim 

[inkx27]

Interesting to hear that PS4 Pro has a spotify mDNS responder. Do you happen to know what ip address its using or even name of the server?

I will enable logging internally to find out the culprit address and block it. May be that might be a way forward if all queries generating from PS4 Pro Spotify are blocked rather than allowed to go out.

[inkx27]

I will run some further tests tomorrow with logging enabled to see what ps4 is doing for mdns requests. 

In the meantime, would you say I should go for option 1 or option 2 as per my post above. 

That is to forward port 5353 to an unused ip address or use the ps4 pro ip and forward them to a higher port on ps4. 

[ravenstar68]

I think you misunderstand what's happening.

Any unsolicited incoming traffic not covered by a specific port forwarding rule is forwarded to the device in the DMZ if there is one, otherwise it is dropped.

So the PS4 isn't generating a query, instead there's a query being sent to your public IP address and the hub is doing what you've asked it to and sending the query to your PS4 which is then sending back a response.

Now assuming you pick up a query from Shadowserver and block their address, that would stop the letters from Virgin Media, BUT it would still leave your PS4 open to being used to take part in a DDOS attack, as mDNS queries from other external IP addresses would still get through.

This is why I developed the strategy of port forwarding port 5353 to either an unused port or an unused IP address.  You effectively filter all inbound mDNS queries that would otherwise be sent to your PS4 no matter what IP address they arrive from.

Tim