Call me paranoid, but I really don't like that my installation engineer and several Givenergy staff have the ability to change settings on my inverter. I would like to restrict the ability to change settings remotely, whilst still maintaining the ability to send statistics to the portal.
Anyone already doing this? Any suggestions as to the best method?
You can’t stop it I’m afraid. Only thing you can do is stop it talking to the Givenergy servers is by either blocking the calls back to the mothership going out the house or rather more draconian - Remove the Wi-Fi stick out the inverter.
Both of these will leave you on shaky ground with warranty claims (a condition of which is constant access by GE is to be maintained) and also stop your portal and app working.
What is the issue with GivEnergy being able to change something.
They are way too busy to bother playing with peoples inverters, if its working there would be no reason to interfere If something goes wrong, they can assist.
I wouldnt worry, unless youve fallen out with your installer and he might think its funny to mess. If this was the case Im sure GivEnergy would have something to say about it.
TheDragon (GivEnergy) I don't know how the engineer access works exactly, but it seems that the engineer account has a list of inverter serial numbers that they have installed and when the engineer needs to commission a system or make changes they choose from a list. It therefore seems possible that the installation engineer could accidentally choose the wrong inverter.
My concern with GivEnergy is they might decide to push out a firmware update or blanket change without warning. They demonstrated their ability to do this at the clock change in October.
Finally there is the possibility of some third party obtaining access using stolen credentials.
hoggy I am thinking the easiest method might be a firewall between the inverter (dongle) and the gateway router. Allow all packets from the dongle. Allow acknowledgement packets back to the dongle (or the dongle will just keep retransmitting) but drop other packets destined for the dongle. Firewall rules are easily switched on and off to allow access when required.
Rubikcube Sadly not that simple. The GE access is over a session initiated by your dongle. That's how you can have portal access without port forwarding and firewall changes on your home router.
The solution I have settled on (for now) is a simple packet filter using iptables. I think a better solution would be an IDS such as Snort (www.snort.org) but Intrusion Detection is outside my current area of expertise.
I am posting my code just in case someone else wants to try this. First I tried a whitelisting approach:
iptables -N Inverter 2>/dev/null
iptables -A FORWARD -i eth0 -o wlan1 -d 10.42.0.219 -j Inverter
iptables -A Inverter -p tcp --dport 8899 -j ACCEPT
iptables -A Inverter -p tcp --tcp-flags ACK,PSH ACK -j ACCEPT
iptables -A Inverter -p tcp -m length --length 40:80 -j ACCEPT
iptables -A Inverter -p tcp -j LOG --log-level info --log-prefix "GivEnergy "
iptables -A Inverter -p tcp -j DROP
which works, but prevents the dongle from reconnecting. So when I try to change a setting in the portal, it fails with Inverter Timeout (as it should) and the portal drops the connection. Then the dongle sits flashing because to reconnect it needs to get data from the server which the filter prevents from happening.
So I have switched to a blacklisting approach which blocks modbus packets with the 06 (write single register) function code.
iptables -N Inverter 2>/dev/null
iptables -N Blacklist 2>/dev/null
iptables -A FORWARD -i eth0 -o wlan1 -d 10.42.0.219 -j Inverter
iptables -A Inverter -p tcp --dport 8899 -j ACCEPT
iptables -A Inverter -p tcp -m length --length 40:80 -j ACCEPT
iptables -A Inverter -p tcp -m u32 -–u32 “50&0xFFFF=0x5959 && 76&0xff=6” -j Blacklist
iptables -A Blacklist -j LOG --log-level info --log-prefix "GivEnergy "
iptables -A Blacklist -j DROP
This blocks register changes correctly, but will probably be ineffective against other changes such as a firmware update.
Suggestions for improvements very welcome.
Since my last post here, my network has evolved. I have moved from using a router to a layer 2 bridge for easier access from my development machine which effectively sits in a DMZ. Because iptables is layer 3, I have switched to nftables on the ethernet bridge. Latest code below for information.
#!/usr/sbin/nft -f
define dongle_ip = 192.168.0.20
flush ruleset
table bridge br0 {
chain classify {
type filter hook forward priority 0; policy accept;
ip daddr $dongle_ip counter jump dongle
}
chain dongle {
ip length < 86 counter accept
tcp dport 8899 counter jump local
tcp sport 7654 counter jump portal
}
chain portal {
ip length > 86 counter log prefix "GivEnergyData " drop
counter
@th,472,8 3 counter
@th,472,8 4 counter
@th,472,8 6 counter log prefix "GivEnergyWrite " drop
@th,472,8 22 counter
}
chain local {
counter
# TCP bytes 32 and 33 of the tcp packet contain the modbus transaction id
# which for givenergy is always hex 5959.
@th,256,16 0x5959 counter
# TCP byte 59 contains the modbus function code
# (3=read settings, 4=read data, 6=write, 16=write multiple)
@th,476,4 4 counter
@th,476,4 6 counter
ip length 86 counter
ip length 86 @th,256,16 0x5959 @th,476,4 6 counter
}
}