mrcrazy04

I’ve got VOIP from Andrews and Arnold. I don’t use it very often (I mainly use my mobile for calls); but when I have, the calls have always been clear. I got a new phone number when I signed up, rather than porting my old number across. I pay about £1.50 per month, and most outbound calls are about 1p per minute. Payment is via direct debit. I went full nerd, and setup an Asterisk server as well; but they had configuration instructions available for a range of VOIP phones/ATAs, etc. for free (without needing to sign up) on their website. I then have a Gigaset VOIP DECT base station connect my cordless handsets to the Asterisk server. I have a static IP address, so configured it so they just send any inbound calls straight to me, rather than me having to poll for them. That seems a bit more reliable; but requires a static IP address and extra firewall rules, etc. to work. They also offer IP allow listing, so you can set it to only allow calls from your home IP address, to guard against credential theft. They also use a randomly generated password for the VOIP calls. I don’t think they have a minimum sign up period, so it might be worth signing up for a new phone number and having a play around to see if it will work for you.

I have a mixture of Hue and Tradfri bulbs with a Hue hub, and out of home access works well, both in the app and with Alexa and Google Assistant. I got quite a few of the Hue bulbs when they were on special offer on Amazon. At points they can be in the region of £10 per bulb for the white ones (bayonet or Edison fittings) - particularly around Prime Day. My Tradfri bulbs are mainly in the kitchen and toilet (GU10 Hue bulbs were too expensive for the number I needed), and I haven’t noticed any difference in brightness or whiteness compared to regular LED bulbs from Tesco or similar. Some of the newer Amazon Echos include a Zigbee hub, so can connect directly to the smart bulbs. I set this up for my parents, and it works well. I don’t think they’ve tried, but I expect out of home control will work with the Alexa app. I’ve not kept up to date with the Google hubs, but do any of them include a Zigbee hub? If you just want to control a single light by the front door, the newer Hue bulbs also include Bluetooth, so you could pair the bulb directly to your phone and turn it on when needed. That does, however, mean you won’t be able to control it when away or give lots of people access.

AppLocker allows you to control Windows Store apps, so a whitelist of permitted apps (including store apps) should be the simplest way to do it. NCSC have a sample set of AppLocker policies at https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/eud-security-guidance-windows-10-1809#applockerconfig. It’s aimed at government departments though, so will probably need further restrictions to block things like PowerShell, and a more general block on Windows Store apps.

NCSC recommend using an AppLocker allow list (whitelist) to control which applications can run, and have a set of policies at https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/eud-security-guidance-windows-10-1809#applockerconfig They have some more recent guidance, but it’s not as detailed. You can, however, download a set of GPOs to review. If you just want to block Roblox, hopefully it’s digitally signed, in which case you can create a publisher rule to block it. If it’s not digitally signed, you’ll probably need to add a path or hash rule, which may end up being like whack-a-mole in terms of blocking it.

The NCSC recommends using an application Allow List (I.e. application whitelisting) using AppLocker. Controlling what can be run on user workstations will make it much harder for an attacker to gain a foothold, reducing the risk of compromise of your estate. This is particularly the case with ransomware, as others have mentioned. NCSC has published some AppLocker rules that will allow most software to function. You’ll probably want to add additional rules for Chrome and Teams - I’d suggest allowing the digital signature and all name. The list of rules is here - https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/eud-security-guidance-windows-10-1809#applockerconfig. The most recent guidance is much shorter, so doesn’t list out the policies; but does include a set of GPOs you can download - https://www.ncsc.gov.uk/collection/mobile-device-guidance/platform-guides/windows-10

I think it’s worth pointing out that Microsoft stopped supporting Server 2008R2 in January, unless you pay them lots of money, so I’d strongly recommend upgrading to a supported operating system (Server 2012 or later). Beyond the SMB issues, there won’t be any new patches, which increases the risk of the server being compromised. If you’re using the server to administer other systems, then that could make it easier for an attacker (or sophisticated malware) to steal credentials and compromise the entire domain. If for some reason you need to continue running Server 2008R2, then it should be isolated as much as possible from the rest of the network (ideally with firewall rules to restrict access to certain services from hosts that need it), and either removed from the domain, or never accessed using privileged domain credentials (like domain admin). Doing this should only be a stopgap measure though, as it doesn’t entirely eliminate the risk.

I’ve seen a couple of places use large readers on their fire exits (combined with turnstiles on the entrances), so they’d know who was still in the building in the event of a fire. Apparently they’re not 100% accurate though, so you wouldn’t be able to guarantee who was or wasn’t in the building. A couple of readers might be the simplest solution, but would probably need a member of staff to supervise it and make sure everybody was touching in. The Paxton systems I’ve seen aren’t much slower than Oyster readers or the readers on buses, so a couple of readers shouldn’t cause massive queues. They will also register a card touch event whilst the attached door is unlocked/open.

At our place we’ve been having daily video calls within our team to provide some degree of social interaction. We’re also possibly looking at doing video coffee breaks from time to time, so video break time might be an option if the students have access to that in Teams. I’ve also made sure I take my breaks away from my desk (luckily I have a room set aside as an office, so do have clear segregation).

There's also DUO, which offers similar functionality; but if you're already using Azure, then Azure MFA is likely to be the cheapest solution and the easiest one to implement.

The Windows Always on VPN is pretty good, and is completely transparent to the user. NCSC have some recommendations on VPN security - https://www.ncsc.gov.uk/collection/end-user-device-security/eud-overview/vpns. I’ve found the guides from Richard Hicks to be generally good in terms of setting it up on the client - https://directaccess.richardhicks.com/ If you’re creating a setup from scratch, and want security baked in, then the NCSC walled garden architecture provides protocol breaks between user devices and internal systems, so if anybody got into the VPN, they still wouldn’t be able to go very far. There’s some guidance on that at https://www.ncsc.gov.uk/collection/mobile-device-guidance/infrastructure/network-architectures-for-remote-access

I found the Richard Hicks guide to be really useful. If you use a device tunnel, then any user should be able to login to a domain joined device (if you go with certificates alone). It’s worth noting that DirectAccess is somewhat deprecated (although not unsupported), so Always on VPN is the preferred option. NCSC has some guidance on the use of VPNs at https://www.ncsc.gov.uk/collection/end-user-device-security/eud-overview/vpns NCSC advise the use of IPSec over TLS VPNs; but I’ve found OpenVPN to be very useful, and quite versatile for remote access [emoji846]

If you’re after a good starting point, NCSC has published some AppLocker rules as part of their Windows 10 End User Device Security Guidance. The guidance is aimed primarily at large government organisations with single user devices, so the rest of is less likely to be relevant. The AppLocker rules should provide a good starting point though, as the default rules can be bypassed. https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/eud-security-guidance-windows-10-1809#applockerconfig If you want to make sure nothing breaks, you can configure it in audit mode initially, and then check the event logs to see if any essential software is being blocked before enforcing the rules.

If users are going to be connecting their own devices to a VPN, I’d recommend going with a DMZ (and making sure that’s all the VPN users can access) to avoid a malicious device running around your internal network. I also second the use of 2FA, as odds are at least one user will have a rubbish password (even if it meets the password complexity requirements, “January@2020#” isn’t a good password). If you don’t have AppLocker rules for teachers, I’d suggest looking at implementing them on the RDP servers, to reduce the attack surface. If Server 2016/2019 supports it, it’s also worth looking at the Windows Defender Attack Surface Reduction Rules, which can block malicious PDFs and macro behaviours. There are other things you can do, like putting the RDP servers in a segregated network with tightly locked down access to other resources, or using Read Only Domain Controllers - but how far you want to take it will depend on your risk appetite and how much time you have to build and support this. If you’re looking to roll such a solution out to students down the line, it’s worth noting that if an RDP server is compromised, it could expose a large number of user credentials (although Windows 2012R2 and later have made that more difficult). Taking extra steps on those, such as segregating them and not logging onto them with Domain Admin or other privileged domain accounts would probably be a good idea for those.

To answer the original question, if you can man in the middle the device, or sit on a mirror port, you could then use Wireshark to see the traffic passing back and forth. Any unanswered SYN packets would tell you that something upstream was blocking it, but not necessarily where. It should also allow you to see if any TLS handshakes are failing, but you obviously won’t be able to decrypt any TLS traffic. An alternative could be to setup an intercepting proxy, such as Burp Community Edition or Fiddler, and make that the device’s proxy server temporarily, with the original proxy set as an upstream proxy. That might be a bit easier, as you won’t have to wade through lots of network traffic to get a better idea as to what’s going on.

I've used the Always On VPN and it works quite well, although you can end up with some split tunnelling (where some traffic doesn't go via the VPN) - which can be useful for logging in to public WiFi, but isn't great if you want all traffic to go through your web filter. I've found Richard Hicks' website to be very useful for configuring Always on VPN (although I think there were a couple of areas that I had to puzzle through on my own). NCSC have released some PowerShell scripts to help configure things on the clients, which should also be of assistance - https://s3.eu-west-2.amazonaws.com/eud-security-guidance/NCSC+Remote+Access+Scripts+Version+3.4.zip (linked from https://www.ncsc.gov.uk/collection/end-user-device-security/platform-specific-guidance/eud-security-guidance-windows-10-1809). The DeviceTunnel means the device will bring up a VPN connection before users login, so it can pull GPO updates and so on when remote - I've found it can sometimes take a while to bring up the DeviceTunnel though, and transitioning to the UserTunnel when a user logs in can also take a little while. In terms of setting it up from scratch, you'll need to have a VPN server (I've used StrongSwan on Linux as it supports the most things, but has a very steep learning curve to get everything up and running). You'll then need to create a client certificate for each device that connects, signed by an internal CA (if you have one already, you could use that), and configure your VPN server to allow connections from clients with certificates signed by that CA. Using a separate certificate per device means that if a certificate is compromised, you can just revoke it without having to re-provision all your devices. I've only done fairly small-scale deployments, so haven't needed to automate pushing the certificates to devices - has anybody got an easy way of doing that? If you're worried about the VPN certificate being compromised, following good security practice in terms of the laptop build (so BitLocker, AppLocker, locking after a period of inactivity, and not giving users admin access) should help reduce the risk of that. If you want to be extra paranoid, you could implement NCSC's walled garden, but I'm guessing that won't give you access to the various domain resources that you'd like.