I have been reading about UPNP vulnerabilities and I can see issues with the protocol. I was wondering what is the best approach to mitigate the risks. My network runs with virtualized servers and can be configured with as many LAN's and/or HotLAN's that I wish to have, I also have VLAN capabilities across my Switches and WIFI AP's.. For this setup (Home) I would prefer to only use one gateway.
I was thinking possibly moving all the appliances that uses UPNP to the HOTLAN and if needed open the ports to the appliances that require access to the LAN or would it be equivalent to have a second LAN setup for these appliances? It would be less work running the appliances on a second LAN but I am not sure if the vulnerability includes the traversal to other LAN'S? I believe that would be unlikely but not sure? Anyone's input would be appreciated.
What would be the best approach to the modification of CLearOS miniupnp for the above? Would it be to modify miniupnpd.conf permission rules? For the HOTLAN approach: modify the permission rules or exclude manually the LAN in the configuration file: init_clearos.sh ?
I was thinking possibly moving all the appliances that uses UPNP to the HOTLAN and if needed open the ports to the appliances that require access to the LAN or would it be equivalent to have a second LAN setup for these appliances? It would be less work running the appliances on a second LAN but I am not sure if the vulnerability includes the traversal to other LAN'S? I believe that would be unlikely but not sure? Anyone's input would be appreciated.
What would be the best approach to the modification of CLearOS miniupnp for the above? Would it be to modify miniupnpd.conf permission rules? For the HOTLAN approach: modify the permission rules or exclude manually the LAN in the configuration file: init_clearos.sh ?
Share this post:
Responses (13)
-
Accepted Answer
I am not sure about multiple subnets. Multiple HotLAN's are a bit buggy with the firewall script but can be fixed. I think it is in the documentation of the IP Settings. What you could try is editing /etc/miniupnpd/miniupnpd.conf and uncomment and set listening_ip. I've no idea if this will work.
At some time I need to have another go at the app to read in more parameters from miniupnpd.conf. -
Accepted Answer
Hello Nick, Very nice to see heard from you. You had a good suggestion about the IP Settings but I do not believe miniupnp likes the idea?
Feb 7 16:17:58 test miniupnpd[17190]: shutting down MiniUPnPd
Feb 7 16:17:58 test iptables_init.sh: NAT table clean..initalizing..
Feb 7 16:17:58 test iptables_init.sh: Filter table clean..initalizing..
Feb 7 16:17:58 test miniupnp-options: WAN=-i ppp0 LAN=-a ens192 Options=
Feb 7 16:17:58 test miniupnpd: it is advised to use network interface name instead of 192.168.6.1/24
Feb 7 16:17:58 test miniupnpd[27647]: could not open lease file: /var/lib/miniupnpd/upnp.leases
Feb 7 16:17:58 test miniupnpd[27647]: HTTP listening on port 36534
Feb 7 16:17:58 test miniupnpd[27647]: Listening for NAT-PMP/PCP traffic on port 5351 -
Accepted Answer
I added a few modification to the miniupnp service to fit my customization needs (/etc/miniupnpd/init_clearos.sh)
#!/bin/sh
#
# Prep the parameters to pass to systemd
#
# Source networking configuration.
. /etc/clearos/network.conf
# Source miniupnpd_clearos.conf configuration.
. /etc/miniupnpd/miniupnpd_clearos.conf
# Determine WAN interface default route
MINIUPNPD_WAN="-i `LC_ALL=C ip -4 route | grep 'default' | sed -e 's/.*dev[[:space:]]*//' -e 's/[[:space:]].*//'`"
# kludge for when WAN goes down to stop miniupnpd failing
if [ "$MINIUPNPD_WAN" = "-i " ]; then
MINIUPNPD_WAN="-i lo"
fi
MINIUPNPD_LANS=""
if [ -z "$CUSTOM_LAN" ]; then
# List all the LAN's with the correct config parameter, checking the LANIF's are valid
for LAN in $LANIF; do
CHECK=$(ip r | grep "$LAN " 2>/dev/null)
if [ -n "$CHECK" ]; then
MINIUPNPD_LANS="$MINIUPNPD_LANS-a $LAN "
fi
done
if [ "$USE_HOTLAN" = "yes" -a ! -z "$HOTIF" ]; then
CHECK=$(ip r | grep "$HOTIF " 2>/dev/null)
if [ -n "$CHECK" ]; then
MINIUPNPD_LANS="$MINIUPNPD_LANS-a $HOTIF "
fi
fi
else
for val in $CUSTOM_LAN; do
for LAN in $LANIF; do
CHECK=$(ip r | grep "$val " 2>/dev/null)
if [ -n "$CHECK" ]; then
MINIUPNPD_LANS="$MINIUPNPD_LANS-a $val "
fi
done
done
fi
# kludge if LAN not yet configured
if [ "$MINIUPNPD_LANS" = "" ]; then
MINIUPNPD_LANS="-a lo"
fi
systemctl set-environment MINIUPNPD_START_OPTIONS="$MINIUPNPD_WAN $MINIUPNPD_LANS $MINIUPNPD_OPTIONS"
logger -t miniupnp-options "WAN=$MINIUPNPD_WAN LAN=$MINIUPNPD_LANS Options=$MINIUPNPD_OPTIONS"
exit 0
The customization requires that you add the parameter CUSTOM_LAN to /etc/miniupnpd/miniupnpd_clearos.conf
# Uncomment the next line if you want uPnP to work on the HotLan interface
#USE_HOTLAN="yes"
# Custom configuration, overrides Lan and/or HotLan configurations.
# Uncomment the next line and add the interface(s) you want uPnP to work with. Example: CUSTOM_LAN="ens192 ens224"
CUSTOM_LAN="ens224" -
Accepted Answer
-
Accepted Answer
I have a standalone server running Home Assistant with a feature that allows me to emulates a Roku appliance for my Harmony Hub to discover and include in its activities for running customized scripts.
My UPNP discovery needs seem to be covered (Thanks to Nick and MiniUPNP) when I run my server without a firewall. Since this server is running in the HotLan. I would prefer to enable the firewall but I have had some difficulties figuring out what ports below are needed to allow the Harmony Hub to find the emulated Roku device
[root@cognoquest ~]# netstat -lntup | grep "upnp"
tcp 0 0 0.0.0.0:41732 0.0.0.0:* LISTEN 5511/miniupnpd
udp 0 0 192.168.4.1:5351 0.0.0.0:* 5511/miniupnpd
udp 0 0 192.168.4.1:56763 0.0.0.0:* 5511/miniupnpd
udp 0 0 0.0.0.0:1900 0.0.0.0:* 5511/miniupnpd
[root@cognoquest ~]#
I tried to allow in UDP port 1900 but was not successful at penetrating the firewall. Any suggestions to what ports are needed for the discovery to work.and reduce the security vulnerabilities.
Corrections: The emulated Roku appliance runs on port 8060. That is not the one I am having issue with, it is the discovery portion that I wish to clarify. Thank You -
Accepted Answer
Nick Howitt wrote:
I am not sure why you are iterating over $LANIF. I think this will exclude any $CUSTOM_LAN which is in $HOTIF. Do you just want:else
for val in $CUSTOM_LAN; do
CHECK=$(ip r | grep "$val " 2>/dev/null)
if [ -n "$CHECK" ]; then
MINIUPNPD_LANS="$MINIUPNPD_LANS-a $val "
fi
done
fi
Good point, I had the same thought when I was coding this. But it seems that the LAN iteration is including the HotLAN?
I am including my log, ens224 is configures as my HotLAN
Feb 13 02:25:25 cognoquest miniupnp-options: WAN=-i ppp0 LAN=-a ens224 Options=
Feb 13 02:25:25 cognoquest miniupnpd[5511]: HTTP listening on port 41732
Feb 13 02:25:25 cognoquest miniupnpd[5511]: Listening for NAT-PMP/PCP traffic on port 5351 -
Accepted Answer
Philippe Eveleigh wrote:
I don't see how you are getting that result. Have a look in /etc/clearos/network.conf for LANIF or do "grep IF /etc/clearos/network.conf"
Nick Howitt wrote:
I am not sure why you are iterating over $LANIF. I think this will exclude any $CUSTOM_LAN which is in $HOTIF. Do you just want:else
for val in $CUSTOM_LAN; do
CHECK=$(ip r | grep "$val " 2>/dev/null)
if [ -n "$CHECK" ]; then
MINIUPNPD_LANS="$MINIUPNPD_LANS-a $val "
fi
done
fi
Good point, I had the same thought when I was coding this. But it seems that the LAN iteration is including the HotLAN?
I am including my log, ens224 is configures as my HotLAN
Feb 13 02:25:25 cognoquest miniupnp-options: WAN=-i ppp0 LAN=-a ens224 Options=
Feb 13 02:25:25 cognoquest miniupnpd[5511]: HTTP listening on port 41732
Feb 13 02:25:25 cognoquest miniupnpd[5511]: Listening for NAT-PMP/PCP traffic on port 5351
How did you allow UDP/SSDP discovery? It looks like it uses a MultiCast IP address.
[edit]
Perhaps:
[/edit]$IPTABLES -I INPUT -i ens224 -p udp --dport 1900 -j ACCEPT
[edit2]
Or:
[/edit2]$IPTABLES -I INPUT -i ens224 -d 239.255.255.250 -j ACCEPT
-
Accepted Answer
Hello Nick,
I know why it worked and I feel kind of dumb. The LAN loop has no effect on the CUSTOM loop, not exactly my best coding...
else
for val in $CUSTOM_LAN; do
logger -t miniupnp-options "LANIF=$LANIF"
for LAN in $LANIF; do
logger -t miniupnp-options "LAN=$LAN"
CHECK=$(ip r | grep "$val " 2>/dev/null)
logger -t miniupnp-options "CHECK=$CHECK"
if [ -n "$CHECK" ]; then
MINIUPNPD_LANS="$MINIUPNPD_LANS-a $val "
fi
done
done
fi
The log:
Feb 13 07:23:58 test miniupnp-options: LANIF=ens192
Feb 13 07:23:58 test miniupnp-options: LAN=ens192
Feb 13 07:23:58 test miniupnp-options: CHECK=192.168.4.0/24 dev ens224 proto kernel scope link src 192.168.4.1
Feb 13 07:23:58 test miniupnp-options: LANIF=ens192
Feb 13 07:23:58 test miniupnp-options: LAN=ens192
Feb 13 07:23:58 test miniupnp-options: CHECK=
Feb 13 07:23:58 test miniupnp-options: WAN=-i ppp0 LAN=-a ens224 Options=
In regards to the firewall I used the ClearOS Incoming Firewall configuration before tightening even more the rule set by using a custom rule:
[root@services26 ~]# iptables -L -n -v | grep 1900
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.4.26 udp dpt:1900
0 0 ACCEPT udp -- * ens192 192.168.4.26 0.0.0.0/0 udp spt:1900
[root@services26 ~]#
But that does not seem to help my Harmony Hub find the emulated Roku appliance. I will have to do more testing once I am at home -
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
Good catch with the loop.
I am lost with the other. Where are the Roku emulator and Harmony Hub (IP's and interfaces)? Have you thought of some packet sniffing with tcpdump?
I agree a little confusing let me try again. For the interface that one is easy, it is all happening on the same interface my HotLAN: ens224.
The Roku Emulator is the ClearOS Server it run on IP: 192.168.4.26 port 8060 can be accessed with or without the firewall enabled via the browser:
http://192.168.4.26:8060/
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:roku-com:devicelayer:1-0</deviceType>
<friendlyName>Home Assistant Roku</friendlyName>
<manufacturer>Roku</manufacturer>
<manufacturerURL>http://www.roku.com/</manufacturerURL>
<modelDescription>Emulated Roku</modelDescription>
<modelName>Roku 4</modelName>
<modelNumber>4400x</modelNumber>
<modelURL>http://www.roku.com/</modelURL>
<serialNumber>Home Assistant Roku</serialNumber>
<UDN>uuid:8d5caa9c-dd9b-57e4-b812-c6b5dc571b51</UDN>
</device>
</root>
The Harmony Hub sits on IP: 192.168.4.205
The Harmony Hub can be asked to discover all appliances and with the help of UPNP it seems to find all the appliances T:V, Receiver etc including the above Emulated Roku 4 on Server 192.168.4.26 when the firewall is disabled. If the firewall is enable all the appliances are found except for the Emulated Roku.
Never used tcpdump, if I can not find the above issue might be a good solution, thanks for the suggestion -
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
As far as I am aware, uPnP does not feature in this. I think MiniuPnP's role is to just map external port forwards automatically. I don't know how device discovery works for other devices.
Interesting, I thought it also allowed the devices on your home network to discover each other and access certain services. Thanks for your help in all of this, if I find additional information I will chime in. -
Accepted Answer
Nick I think you are correct miniUPnP even if it is part of the UPnP Protocol Stack is more involved at the end of the Stack, if port forwarding is required by the device/appliance i.e. TV, receiver, etc...The second issue that I was having has more to do with the Simple Service Discovery Protocol even if SSDP was incorporated in the UPnP Protocol Stack not really related to miniUPnp tasks. In retrospect I confused the two different actions and I should probably have created a second forum entry for my second question.
But all is good with your help I was able to confine miniUPnP port forwarding to the interface of my choice, which is what I wanted. The second issue was to limit the access to my Standalone Server to port 8060 acting as an Emulated Roku device. I think I got that resolved by adding the following two custom rules.
#UPNP discovery access to Services26 multicast for Harmony Hub
$IPTABLES -I INPUT -i ens192 -s 192.168.4.205 -d 239.255.255.250 -p udp --dport 1900 -j ACCEPT
#TCP access to Services26 for Harmony Hub
$IPTABLES -I INPUT -i ens192 -s 192.168.4.205 -p tcp --dport 8060 -j ACCEPT
I wish to apologize for the confusion with the interfaces. The interface: ens224 belongs to the Gateway Server HotLan, where the above interface: ens192 belongs to the Standalone server running the emulated Roku device. The first rule is to open the discovery process to the Harmony Hub, this is a standard SSDP process required for the discovery of devices. The second rule is for allowing the Harmony Hub access to the Emulated Roku Device.
For the audience that is wondering how can ClearOS become a Roku device? Well in this particular case it does for my Harmony Hub. The Harmony Remote activities sees the server as a Roku device and triggers Home Assistant events such as controlling lights, motorized curtains, etc... running on the same Standalone ClearOS server.
Thank you again to Nick for all the help.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »