Mind Circuitry

Recently, I've invested in a GivEnergy All-In-One (AIO) battery and Gateway to be smarter with our energy management with an aim of reducing our bills. This article documents the initial installation, with the main focus on the security configuration of the devices.

NOTE: I'm assuming an element of technical knowledge from the reader here, this is by no means a HOWTO guide.

Installation

As part of the commissioning, the installation engineers requested my wireless network details so the devices could communicate back to the GivEnergy Cloud, and once this was done – the only advice I received was to “change the password of the portal for the devices”. So, better go and do that first then!

First, I needed to find the IP addresses of the devices. Both the AIO and Gateway connect to the wireless separately, so I was looking for two IP addresses. I run Unifi Access Points and Switches at home, so this was a breeze. Once found, dropped the addresses into a browser and logged in with the default credentials (admin\admin).

When changing the password for the admin account to the devices, first thing I noticed is the clear text password field! 😱 Argh! oh well, it is what it is.. better get it updated first.

Lets have a look at the settings and menu choices we have:

Mode Selection

This appears to allow us to change between AP and STA mode. Noted. Looks good so far, its on STA mode.

AP Interface Setting

This enables the Access Point of the device for configuration. Hmm, looks concerning, but the previous setting looked like this wasn't enabled? Maybe it's not so bad?

STA Interface Setting

This allows us to configure the device onto the home wireless network. Sigh, more clear-text password fields, but OK – let's move on.

I'm not a security professional, so there maybe more issues present, but these concerns jumped out at me here:

1. All password and SSID passphrase text boxes were clear text.
2. AP Interface Security Mode is Open by default!
3. If I was being really picky, it's HTTP only, and no HTTPS.
4. I noticed TELNET (not SSH) was open. (I'm going to dig into this in the future)

Digging deeper into these as part of improving the security stance, I discovered the following:

• The device password field is 20 characters maximum length
• The SSID passphase fields is 63 characters maximum length
• The 'Hidden' tickbox on the AP Interface appears to make the AIO\Gateway unavailable in the GivEnergy Portal
• If changing the AP SSID name, it also appears to make the AIO\Gateway unavailable in the GivEnergy Portal
• The Mode Selection between AP and STA does NOT disable the AP SSID! The AP SSID was being broadcasted, no matter which option was set!

In terms of basic security, this is sub-optimal. In summary, if I was do not do any configuration (as a basic consumer) a bad-actor could connect wirelessly to the AP mode of the device, and browse my network for other devices to exploit\pivot\etc or use my bandwidth for free. I repeat, SUB-OPTIMAL.

Improving Security

Firstly, I configured the GivEnergy devices as best I can taking into account all of the above, which involved one solitary, but important step:

• Encrypting the AP Interface mode with a strong password and WPA2 encryption. This did NOT break communication back to the GivEnergy Cloud, which was nice 😉.

My house runs Unifi for Access Points, Switches and Camera's, and I love it! As part of this configuration, there are a number of key VLAN's configured:

• Management (Wired devices and native VLAN)
• Wireless (Single SSID associated with it)
• Security (Camera's, NVR etc)
• DMZ (NextCloud instance)

Although these devices were only on my Wireless VLAN, I was still very uncomfortable with this, as this VLAN is used heavily by everyone in the house and has a lot of devices that connect to it. These are the steps I took to improve security:

Within Unifi: 1. Create a separate Wireless Network called “Energy” 2. Create a separate VLAN and publish the SSID only to that VLAN. 3. Create a WiFi Speed Limit profile and attach to the new “Energy” network. 4. Enable MAC Address filtering on the “Energy” network for only the GivEnergy devices

At the firewall: 1. Ensure only HTTP, HTTPS, NTP, DNS, and TCP/7654 could access outbound network. 2. Ensure no traversing of VLAN's was possible from “Energy”, but allow “Management” access to “Energy” for configuration of the device portals.

Note: There is probably more I can do here at the firewall level, but leaving that for another article. I'd like to understand what traffic goes out, and to what IP addresses, and lock it down just to accessing those ranges if possible.

Pitfalls

When configuring these improvements, there were a couple of issues that tripped me up! When configuring the wireless settings on the Gateway, I accidentally changed the SSID or password on the STA mode setting (see point #1 below), and ended up locking myself out of the administration portal for that device. I learnt some things here:

1. Don't drink beer and watch TV at the same time of making critical configuration changes 😉
2. If wanting to use LAN instead of WiFi, you can do but you need to change DIP switches on the side of the Gateway. I never got this working, it could have been related to point #1, or just me being impatient.
3. Not sure what triggered this, however after some time of trying to get access through the LAN, the wireless module on the Gateway reset itself. So, I reconnected in via the AP mode with OPEN Security (and a reset admin password) and re-configured everything again. Not sure if this was the changes of DIP switches to enable LAN, or the fact that the WiFi module couldn't connect to the provided SSID.

The manual outlines the DIP switches settings if you need to understand them and it appears like you cannot have both? Makes me think – If in LAN mode, will that disable the AP Mode Setting? All of point #3 is one to understand another day, and document appropriately.

The mobile app has two settings – “Home” and “Away”. Home connects locally via IP, whereas the “Away” connects via the GivEnergy Cloud. Now that the GivEnergy devices are isolated on their own VLAN, the Mobile app does not find the devices when at “Home”. This I assume is down to broadcasting traffic and inter-vlan traffic being blocked. It's not a major concern, as you can still see data when “Away” and the portal still works fine. Again, another one to investigate for another day.

I'm not 100% happy with this configuration, however it was fine for now, and I I was keen to get the cost saving elements configured up so I can start saving money! I plan to revisit security of these devices with a view on LAN configuration, disabling the AP mode completely, and further investigation into secure firewall configuration.

Energy Configuration

Now that my devices are configured up, and more secure than “factory default”, it was time to turn my attention to ensuring maximum cost saving, and configuring them to charge during the lowest tariff period of the day.

I decided to use Octopus Agile – a beta smart tariff in the UK that provide access to half-hourly energy prices, tied to wholesale prices and updated daily. The plan was to charge my battery up at the cheapest point, and draw from the battery at the most expensive time of day (usually between 4pm – 7pm).

You can see the historical data of their tariffs here here

As there was no information provided to me by the installer's, it was down to me on how to figure how to configure the charging schedules. What I learnt here, may help others to reach the optimum process quicker!

Mobile App

First, the obvious place to look, I discovered I could set a single charging period per 24hr period via the mobile app. Not a bad start, however, it's only a single charge period and checking the historical data from the above website, I can see that these time periods change daily, and more noticably at weekend periods.

GivEnergy Portal

Once you've found the method of configuring this, it allowed for more charging period, however they are still static time periods. For note, the way to do this is go to My Invertors > Remote Control on the All-In-One:

Once there, you configure the time period that you want it to start and end charging, along with maximum percentage. It's got a weird read and commit process on each setting. There are 10 time periods you can have, and you can also set discharge periods.

Still this isn't dynamic! What else?

HomeAssistant

I'm also running a HomeAssistant installation at home, and perhaps this can do it with it's automations? Yes it can, however it isn't by any means simple. Firstly, it requires the GivTCP Addon installing in HomeAssistant. That addon then needs access to your GivEnergy devices, which if you recall from above, are on an isolated VLAN to my other devices. So, some Inter-VLAN firewall-rule-hackery takes place, and they can now see the devices. Next hurdle is there appears to be some bug around pulling data from them.

• Forum Post
• GitHub Issue

I gave up here as after some more internet searching I found the following solution!

Octopus R&D Labs

Octopus Energy have an R&D Labs site that utilises the GivEnergy API to schedule charging at low tariff periods! Fan-bloody-tastic!

Configuration was actually quite simple – get the API details from GivEnergy Portal, create a Device Group and add in your GivEnergy Devices. Also, put in your Octopus Agile API details (found within My Account in your Octopus Portal).

The R&D site also includes a number of guides on how to configure charging based on lowest tariffs:

Following the guide was simple, and so far after a few days I can say that this appears to be working as intended.

As with any pre-release\beta software, we should always be mindful that features can change, but so far – this looks excellent. A key point to remember (and it does tell you this during configuration) is that this will overide any configuration set in GivEnergy, although the time periods may still be set.

Conclusion

From this, we've learnt a good deal:

• It is highly insecure as factory default, and MUST be secured!
• Some of this security configuration can be daunting for a non-technical person. Always see advice from a trusted techie\expert to help 😉
• I'm not affiliated with Octopus, however their R&D Labs made the scheduling so simple. This ideally needs to be better advertised\outlined when signing up to their Agile Tariff.

I'll investigate into the networking aspects further in a separate post, as I am keen to access these devices via LAN cabling. From reading the Givenergy community forum posts, it should be as simple as flicking a DIP switch.. but that didn't work so well for me! This said, I need to run some cabling in the house first before I get to make this happen.

#GivEnergy #Security #Energy #Technical

Background

Over the past year, I have been supporting a client with a multi-tenant application focused around data analytics. This article outlines some of the hurdles that were faced around Azure SQL Server when applying Defense in Depth security principles.

Note: The architectural decisions around the multi-tenancy aspect of the application was not designed by me, nor is is not under my control. My remit was to secure the application without significant design changes.

Architecture

This is a simplified architecture diagram of the product, with only the relevant elements included.

Data is pulled from the customer environment and stored within Azure SQL Server in the provider's tenancy. A PowerBI report is published to the customer's PowerBI App Service, which reads and visualizes data from the Azure SQL Server.

Problem

As part of regular security screening using the CIS Microsoft Azure Foundations benchmarking, it was identified that the Azure SQL Server had the following tick box enabled:

The documentation from Microsoft explains further:

When looking at this rule within PowerShell, it shows as 0.0.0.0/0!

Although the Microsoft Learn documentation says this is ONLY Azure IP Addresses, as a network guy, this screams to me says “everything”. Because we are applying defense in depth techniques (thus we cannot rely just on authentication alone), and this database contains customer data (with potentially PII within it), this checkbox needs to be disabled. Easy! ... well.... is it?

Options

Keeping in mind the requirement to have it as a multi-tenancy application, there were a number of options available (in order of least effort):

1. Programmatically get the PowerBI IP Address Ranges, and populate into ASQL Firewall Rules. Then disable “Allow Azure services and resources to access this server”.

2. Migrate the Azure SQL Server (ASQL) to Azure SQL Managed Instance(MI) or a Virtual Machine (VM). Apply a PowerBI Service Tag to the associated Network Security Group(NSG).

3. Implement Azure Firewall, connecting to a Private Endpoint on ASQL. Include an NSG on the Virtual Network to only allow IP's from PowerBI using it's Service Tag and\or put the Service Tag within the Azure Firewall rule.

4. Install Data Gateway in the Customers tenancy on Virtual Machine with a static Public IP address. Whitelist this IP Address in the ASQL Firewall Rules.

5. Use Virtual Network Gateway between customer tenancy and the service providers tenancy.

Let's run through these:

Option 1: Programmatically get PowerBI IP Address Ranges

This option involved getting all PowerBI Address ranges, and programmatically putting them into the ASQL firewall. This felt like a good solution – although not perfect, we are dramatically reducing the attack surface to just PowerBI App Service.

Firstly, before we write a script – let's get the JSON file from here, and then see how many address ranges there are for PowerBI to see if it's viable:

Well, this won't work, as there is a maximum of 256 rules for Server-level IP firewall rules.

Result: ❌ Rejected

Option 2: Use Virtual Network Gateway

This was a wildcard option – it would require work on the customer's tenancy side, and thus it was rejected quite early on, for the reasons that we should solve this project and secure the database with as little effort on the customer's tenancy as possible.

This involved using the Virtual Network Gateway and creating the relevant rules in the ASQL firewall to allow access from the customer's tenancy.

This article outlines more about how to achieve this, however for our requirements, it would be slightly different to their first diagram.

Result: ❌ Rejected

Option 3: Data Gateway in Customer Tenancy

Although this would technically work, it's additional resource that would require maintenance and additional resources at the customer's tenancy. For this reason alone, in a similar vein to Option 2, it was not a viable option for this issue.

Result: ❌ Rejected

Option 4: Migrate to Azure SQL MI / VM

There was feeling that this would work, however we were keen to move to PaaS services where possible. It was felt that running SQL Server on a VM would be a backwards step, as all the maintenance elements of running an VM would be required. The Managed Instance option was also possible to reduce these maintenance aspects, however it did come at quite a high cost. At this stage this option was rejected, how it was noted that this maybe revisited at a later time in the project.

Result: ❌ Rejected

Option 5: Implement Azure Firewall with Private Endpoints

This looked the most promising and following discussions with Microsoft, this was a strong contender, despite it not being their recommended solution. A Proof of Concept was set up in the following design:

This enabled us to access the database through a new hostname – customer.saasprovider.tld. When using SQL Authentication, it was important to pass the username including the server name:

sysadmin@customerdatabase.database.windows.net

To ensure only PowerBI endpoints could access the database, we added the Service Tag for PowerBI to a rule within the NSG.

It did not work! 😱 We had a suspicion that this was because the traffic was originating not from one of the IP addresses contained within the Service Tag. We were close.... When checking the documentation it stated that “Note: does not include frontend endpoints at the moment (e.g., app.powerbi.com).”. When raising this with Microsoft, they did not confirm or deny this, however they did outline the main cause of the issue. As the traffic was traversing Azure Firewall, it was being NAT'ed, therefore the source IP address accessing the ASQL private endpoint was not that of PowerBI, it was the internal IP address of the Azure Firewall! 🤯

Microsoft's suggestion was to add all the PowerBI IP address ranges into an Azure IP Group, and bind that to the relevant rule in the Azure firewall. We dutifully created an Azure Automation job to get the latest IP Addresses from the JSON file in #1, and populate an IP Groups object with said IP address. This worked a treat, however it was noted that Azure Firewall and IP Groups (to date) does not support IPv6 Addresses.

This finally looked like it was going to work! We started to plug in our PowerBI test report into the PoC and started configuration. Authentication was failing during the publishing phase from PowerBI to the PowerBI App Service. It appeared that when passing in username@customer.provider.tld failed, as ASQL had no understanding of that username. ASQL was expecting to see username@customerdatabase.database.windows.net, however we couldn't pass that username through as the ASQL Server was not available on the public internet!

At this point, we also discovered that even if we did run SQL on an Azure SQL Managed Instance, we would have exactly the same problem around authentication, thus option 4 was rejected again (and with confidence it would not work, even if the budget was appoved).

Result: ❌ Rejected

Next Steps

During the conversations with Microsoft, they suggested two more options:

• Use Semantic Model Sharing
• Power BI Embedded

Semantic Model Sharing although appeared to be a viable option, the lack of automation options around our DevOps deployment processes along with increased support administration also made this not a viable option. This is because we would have to share the semantic model with specific users, and thus they would need to be created as Guest Users within our EntraID.

Conclusion

This investigation took approximately six months, and included multiple scripts, proof of concepts and conversations with Solution Architects from Microsoft to help us meet the requirements of allowing access to Azure SQL Server in a multi-tenancy environment.

After discussions with senior management, the final result and conclusion was that the product should be re-architected so the report is published to the provider's tenancy, with a strong possibility of using PowerBI Embedded to surface this data via a web portal. This re-architecting is currently underway and being designed appropriately. In the meanwhile, we've learnt a huge amount of knowledge around how to secure Azure SQL Servers, which will do us in good stead moving forwards as other services and products are migrated from SQL Server on virtual machines or on premise. Hope you have learnt something too!

This is Part 2 of my Mid-life Changes posts.

Summary

As noted in Part 1, I've taken steps to improve life based on recent events. I had recently been feeling restless and constantly bored, despite my day filled with work, a side hustle, and house-chores. I've just had my first therapy session, and its opened my eyes to what is going on!

I discovered that:

• Up until now I have had a job – providing for my children, and now two of them have successfully moved out of home and are now mostly providing for themselves.
• Stemming from the custody battle, I have subconsciously believed that I must prove myself and my abilities.
• Everything that is done – is done for the children first, and me second.

Routine

Ever since I was a child, I've been a subject of routine. Two examples from when I was child that I strongly remember:

• Always having a walk\cycle in the park on Sunday afternoon
• Sitting round the table with my siblings eating tea at 5pm

Then, when I became a father, further routine was suggested to me by my parents. Not in a negative sense, but always with the words “a routine is so important for babies” etc. For example:

• Having a walk in the afternoon
• Tea at 4pm-5pm
• Then bath-time at 6-7pm
• Then a story in bed, followed by lights out.

Why did we do this? All to teach the baby good routine, so there are no surprises, which overall calms them and thus teaches them to sleep well at night. There are other examples, but this is easiest and most common.

Currently, I'm still very fixed in routine to this day. For example:

• For the past 6 years, I've nearly always gone to the local coffee shop at 2.45pm on a Thursday. 🤷‍♂️
• Wanting to know what tea is (either today\tomorrow\whenever) so I can plan my lunch and not have the same food group such as bread\pasta.

Session Two

This became the focus of my next therapy session. Without intention, we revisited the custody case and how this was a trauma event in my life.

The following was put to me:

• If there is a routine and I do the same things repeatedly, then I believe I won't ever reach the trauma event and I'll be safe.
• However, if I do stick to the routine, and something unexpected does happen, it will throw me off balance, potentially causing a bigger impact.

We discussed that whilst a routine is an excellent strategy, it doesn't work for me currently. I've been doing the same routine for years (caring and parenting children), and now two out of three have left home, thus leaving me a void in my life, with my routine now thrown out as such a large part of my life is not the same anymore. It's changed.

The Plan

It is now more important than ever to mix things up. Break the routine. Practice being uncomfortable. The more I practice this, the easier it will be should something unexpected come around the corner.

I found something oddly strange about this that I discovered in that second session.

The session took place on a Wednesday afternoon. Currently, as you may see from my other posts, I'm currently training for a marathon. My training is usually early morning approximately 6-7am, and on Monday's I do swimming as this is gentle cross-training the day after a long run on the Sunday.

On the Monday before therapy, I didn’t go swimming between 6am and 7am, I thought I'd have a rest day instead. However, at 7pm that day, I felt that I missed it, and I'll go swimming at 8.30pm (adult swim lanes) instead. To be completely honest, I was quite anxious over this. Parking was more difficult as the usual crowd were not there at 6.30am, when I looked into the pool it looked busier than 6.30am – There were people splashing, messing around and generally having fun! I thought to myself that I just need to crack on with this and go swimming. It's what I'm here for. I did – it was excellent, and I had a great swim! 🏊

So, this was naturally discussed as part of the routine conversations in session #2, and how although there was initial anxiety, nothing bad happened, and at the end of it a good swim took place!

So, the plan is all about mixing things up. Learning how to do different things, much like when changing job roles or companies.

My homework was then set for the following week, which was to mix things up. Break the routine, do things differently, don't plan – just do! This is also where this blog came from. I've always wanted to write a blog, mostly focusing on technical problems that I've come across in my life, so I though – why not just start? So I have, and here it is.

#lifeevents #reflection