Online Connectivity & Security Considerations
| Site: | QSC |
| Course: | Q-SYS Reflect Technician Training |
| Book: | Online Connectivity & Security Considerations |
| Printed by: | Guest user |
| Date: | Friday, 22 November 2024, 1:08 PM |
Description
Video Transcript
00:07
Today we’re going to talk a little bit about network security options that you have on your Q-SYS system.
00:12
Q-SYS Designer Software version 8.0 or higher
00:15
uses a powerful web-based browser tool that allows for simplified Core management, known as CORE-MAN.
00:23
CORE-MAN! Who has the ability to adjust your network services with a single click!
00:30
Ah, I’m sorry, the complete name is Core-Manager,
00:36
but it does give you superhero-level powers.
00:39
Core Manager allows for a lot of granularity in your network security options -
00:44
especially when you give your Core access to QSC’s Cloud services via the Internet.
00:49
Now let’s start by setting up our Core for safe and secure connectivity
00:53
to QSC services like Q-SYS Reflect Enterprise Manager.
00:57
First, let's open up any web browser and enter your Core’s IP address into the address bar.
01:05
You can find your device’s IP address from its front panel,
01:08
or—if you’re already connected—from the top bar in the software.
01:12
You can use this IP address to access the Core Manager,
01:15
but before you do that … let’s talk briefly about connection protocols.
01:20
HTTP, or HyperText Transfer Protocol,
01:23
is the method by which information is formatted and transmitted on the web.
01:27
Now HTTPS is the same protocol, but it’s encrypted –
01:32
the S actually stands for Hope.
01:36
No, the S stands for Secure, obviously.
01:39
The two different protocols connect using two different ports –
01:42
HTTP uses port 80, where HTTPS uses port 443 – more on that later.
01:48
We recommend that you always use the HTTPS protocols when connecting to QSC devices using a browser.
01:55
However, there are a couple of things you should be aware of. Such as this:
02:01
Wow. That’s concerning.
02:03
Except, actually, it’s not; because I’m connecting to a device that I own as part of my infrastructure,
02:10
on the same local network as my computer– in this case, my Core processor.
02:14
I know this web page is accurate and encrypted.
02:17
In fact, it’s more secure than using HTTP
02:21
which, ironically, does not prompt these standard web browser warning messages.
02:25
So, it’s ok to bypass this warning and open the connection.
02:30
By the way, if you ever see this warning whiile trying to connect to a public website like your bank,
02:36
or … maybe that website with superhero fan-fiction, you probably (definitely) shouldn’t bypass that warning.
02:46
If you look at the address bar of the browser, however,
02:48
you’ll notice that the connection is flagged as Not Secure – but this is not entirely accurate.
02:55
The Core is using what’s referred to as a self-signed security certificate—
02:59
which may sound like something about as trustworthy as a dentistry license printed from home—
03:06
but because the connection made is using the HTTPS designation,
03:11
it is, in fact, still encrypted and more secure than a non-encrypted HTTP connection.
03:18
You can connect to a Core using standard HTTP and avoid these browser warning messages,
03:23
but you need to understand that those sessions are unencrypted, so inherently less secure.
03:30
As a result, you really should get into the habit of using this secure,
03:34
HTTPS method when connecting to your Core via a browser.
03:39
Now, let's look at Core Manager
03:41
We can see the status of my Core: including the Model, Firmware Version, the running design, etc.
03:48
Today, we’re going to focus on three main tabs: Users, Network Services, and Network Settings.
03:55
Let’s take a look at Users first.
03:57
It’s a good idea to protect your Core with a Username and Password.
04:02
Let’s “Enable Access Control”
04:04
to create different Users and permission levels defining who can edit or access the Core.
04:10
Let’s create our first User.
04:12
The first User created will always be an Administrator level user,
04:16
but you can name the user anything you like.
04:20
So rather than “Admin”, I'm going to name mine after someone who should have all the power …
04:26
... and our lawyers are telling me I need to use the full name of … SUPERMANAGER.
04:32
And of course, we need a password:
04:35
… double check it,
04:37
There.
04:38
Now that we’re all set up, you’re ready to log into our Core, using our newly-created credentials.
04:44
Once we’re in,
04:45
we’re going to head over to the Users tab and set up another user by pressing the New User button.
04:52
Once again we can create a username and password,
04:56
but you’ll also notice that we can now assign the user a role.
05:01
There are three roles available – Viewer, Technician, and Administrator.
05:06
Our first user was automatically an Administrator.
05:09
An Administrator has full, unfettered access,
05:12
including the ability to add, edit and delete User accounts, and even disable Access Control entirely.
05:19
A Technician has full read/write access, with the exception of User accounts, which are read-only.
05:26
I’ll create a Technician role for a user who needs to make changes,
05:30
but doesn’t have as much power as our Admin role.
05:34
The final role is a Viewer.
05:36
A Viewer is essentially a read-only user that can view all of the settings except passwords and PINs,
05:43
but cannot edit anything.
05:45
The only action that the Viewer can perform is to reboot the Core from Core Manager.
05:50
So let’s make a Viewer user for somebody who is basically only good for watching:
05:56
Yes.
05:58
So, that’s Access Control—and it’s something that you should really use every time you deploy a Core.
06:03
Note that Users with the Administrator Role can edit other User’s passwords,
06:08
but if you forget the password for all Users with the Administrator Role, there is no real way to recover it –
06:15
so make sure you store it somewhere secure;
06:17
Remember, with great power comes great….
06:20
Oh, I'm sorry, I’m told that’s from a different universe.
06:24
Alright, let’s move on and talk about networking and IT security.
06:29
For that, we’ll navigate to the Network Settings page.
06:32
You’ll see that on the Core 110f we have three sections: LAN A, LAN B and DNS.
06:40
LAN A and LAN B represent the network interface ports of the same names on my Core.
06:45
The DNS addresses and gateway settings populate automatically from a DHCP server
06:51
somewhere on the corporate network,
06:53
or are provided by the network administrators.
06:56
Without a valid gateway and DNS address,
06:59
you’d be unable to connect to a web address using a Fully Qualified Domain Name, or FQDN.
07:06
In order to use certain Cloud services like Software Feature License activation,
07:11
or Q-SYS Reflect Enterprise Manager,
07:14
your Core will need to be able to connect to QSC’s secure servers via the Internet –
07:19
however, in most deployments, AV equipment tends to be on a dedicated,
07:23
and often not web-connected, subnet.
07:27
That’s where the LAN B comes in.
07:29
Most installers use LAN A for a dedicated AV subnet,
07:32
and LAN B for the main corporate network or some other network that provides secure web connectivity,
07:38
so you can take full advantage of those QSC web services.
07:41
‘But wait!’ I hear you cry ‘Isn’t that going to make our friends in IT a little nervous?'
07:46
Don’t worry citizen, we’ve got that covered, and we’ll talk about how to manage this later.
07:52
As you can see, my LAN A connection has a statically-assigned IP address and net mask,
07:57
and does not have a gateway assigned.
08:00
This is because it is a dedicated subnet, with no requirement for a Gateway.
08:05
My LAN B connection, however, in addition to an IP address and net mask, also has a Gateway address.
08:12
This is the pathway for the Internet.
08:14
Another interesting thing to note
08:16
is that all communication between the Core and QSC’s Cloud services
08:21
are initiated by the Core as a secure, outbound connection on Port 443—
08:26
which, you may remember, is what HTTPS uses.
08:31
What this means is that, in most cases,
08:34
no additional network or firewall configuration is needed
08:38
to allow for full communication between the Core and QSC’s Cloud services.
08:42
So, now that the Core can connect both to our dedicated AV subnet and QSC’s Cloud services via the Internet,
08:49
let’s talk about managing the services running on those network ports.
08:54
For that, we’re going to look at the Network Services tab.
08:58
Here, in the Summary tab,
09:00
we can see the two network interfaces on my Core: LAN A and LAN B -
09:05
and, for each interface, there are a number of network protocols listed.
09:09
Each service displays the relevant TCP or UDP Ports it uses defined in the Protocol Detail field –
09:16
you can see port 80 for HTTP and port 443 for HTTPS, for example -
09:22
and all of which are currently enabled on both network interfaces.
09:27
If I click over here on the plus symbol for any protocol, I can see which services require this protocol.
09:33
Q-SYS Discovery Protocol, for instance, is required for Device Discovery,
09:37
Audio Enabled Peripherals and Control Peripherals, and communicating with TSC-3 touchpanels.
09:43
Long story, but those use a slightly different protocol than our other touchpanels.
09:47
If you click on the same plus symbol for the Q-SYS Control Binary protocol,
09:51
you’ll see a different set of services appear.
09:54
If we look over here on the right,
09:56
we can see that we have individual check marks
09:59
for each of the protocols and services in our expanded view.
10:02
Let’s go into the Management tab, and change a few of these settings.
10:06
As you can see,
10:06
we’re looking at the same information
10:08
but from the perspective of the Services rather than their underlying Protocols.
10:13
By clicking on the Edit button here, I can turn these services on or off individually for each LAN port.
10:21
Let’s say I have some Q-SYS Cameras deployed in my Design.
10:25
Obviously, those cameras need to communicate with the Core,
10:27
so we’re going to leave that particular service enabled on LAN A,
10:31
but the Core doesn’t need to be able to discover Q-SYS Cameras on the Corporate Network,
10:35
so let’s turn that service off on LAN B.
10:40
Now, I simply hit Save, my Core updates, and I’m taken back to my Summary tab –
10:46
where I can see that WSD, which uses port 3702, is disabled on LAN B.
10:54
If I click the plus symbol, my expanded view tells me that, yes, this protocol is used for Q-SYS Cameras,
11:01
and that it’s enabled on LAN A and disabled on LAN B.
11:05
That means the Core is no longer advertising,
11:09
or making available any ports or services related to the Q-SYS cameras on LAN B.
11:14
Note that some Protocols are used by multiple Services, look at Q-SYS Control Binary as an example.
11:21
In these cases, that Protocol (TCP:1700) will remain active
11:26
until all of those Services have been disabled using the Management tab.
11:31
Now, in most cases, you’ll want to leave all of the services for your AV LAN (typically LAN A) enabled
11:37
unless there are items that you know are not required,
11:41
but feel free to check with the IT Department to confirm that this is ok.
11:44
How many services you leave enabled on LAN B will really depend on the requirements of your project,
11:50
and the network security policies for the corporate network in question.
11:54
In many scenarios, where you simply want to use LAN B for secure communication with QSC’s Cloud services,
12:01
you would disable all Services leaving only secure, HTTPS enabled on LAN B.
12:07
Note that some services, like VoIP or SNMP,
12:10
are managed using their own pages outside of the Network Services Manager
12:14
so you'll want to consult those pages as well when locking down your Q-SYS Core for secure deployments.
12:20
So, now you’re equipped to manage secure access to your Core,
12:24
connect that Core to QSC’s secure web services,
12:27
and manage communications on all of your Core LAN ports.
12:31
Thanks for watching.
Lesson Description
Learn some of the common best network practices you should use with your Core, including how to use the tools to secure your Core on a larger network.