Backing up Plex Media Server (PMS)

For those of you that have a Plex Server you know that a ton of data is held on the computer that hosts the server software. Thankfully, from what I have seen, you only need to backup two things:

1. Registry Key
2. Plex Media Server Folder

Excellent, but where are these located? 

The registry key is located at:

   HKCU\Software\Plex, Inc.\Plex Media Server

The Plex Media Server folder is located at:

  

  %localappdata%\Plex Media Server

I created a simple batch file to copy the registry key and folder to a NAS device on my home network. 

Here is the batch file:

@echo off

reg export "HKCU\Software\Plex, Inc.\Plex Media Server" p:\plex.reg /y

"c:\Program Files\WinRAR\rar.exe" a -r "d:\pms\pms-%date:/=-% %time::=-%.zip" "%localappdata%\Plex Media Server"

robocopy d:\pms\ p:\ /E /R:1 /W:1

del d:\pms\*.* /q

I export the registry key and then zip the Plex Media Server folder to my hard drive and then copy it to the NAS device. I then delete the file from my local hard drive.

A few things to keep in mind:

1. The Plex Media Server folder can be pretty large. Mine was a little over 6GB.
2. The updates folder inside the Plex Media Server Folder can be quite large. Mine had over 2GB of files and they are safe to delete. 
3. Zipping the folder can take around 20-30 minutes. 

Once i created the batch file I created a Scheduled task to run every Sunday at midnight.

Powershell Malware

I've been wanting to post about this subject for a while now but haven't had the chance. Hopefully I can give everyone some info on this subject.

First, what is Powershell Malware? Simply put, its powershell commands that go out and download powershell scripts that install keyloggers, takes screenshots, copies clipboard data and downloads more code.

From what I can tell, this is the life cycle of powershell malware:

1. A user clicks a link or otherwise gets a piece of malware on their computer starts the process
2. It creates a value called ComputerID under HKCU\Software\Microsoft\Windows\CurrentVersion.
3. It will then create a value in HKCU\Software\Microsoft\Windows\CurrentVersion\Run
4. Some of the malware will create scheduled tasks so that even if you delete those values the scheduled task will recreate them
5. In domain environments it creates or adds to a GPO so that these values are sent to all the computers in the domain and also creating scheduled tasks.

Here is what it looks like (I removed the full Base64 string):

Invoke-Expression(New-Object IO.StreamReader((New-Object IO.Compression.DeflateStream([IO.MemoryStream][Convert]::FromBase64String('rV............

To figure out what they're doing, substitute "Write-Host" for the "Invoke-Expression" at the beginning and run it, and you get the following (again, I took out the Base64 code and replaced it with dots):

Set-ItemProperty -Force -Path HKLM:Software\Microsoft\Windows\CurrentVersion -Name ComputerID -Value  "......................."; Set-ItemProperty -Force -Path HKLM:Software\Microsoft\Windows\CurrentVersion\Run -Name Powersh
ellActiveDirectoryValue"`"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`" -c `"`$x=`$((gp HKLM:Software\Microsoft\Windows\CurrentVersion ComputerID).ComputerID);powershell -Win Hidden -enc `$x`""

The above is the powershell malware creating the values with the commands in Base64.

At this point in time when it executes those commands it goes to a website to download the other scripts that will create key loggers, screen shots, copy clipboard data, etc. It would look something like this:

http://X.X.X.X:9002/script?id=random&name=keylog

The port above is 9002 but it can be any port or just HTTPS.

The poweshell scripts it downloads seem to be from PowerSploit. I wont link here but you can Google it or find more info on Github. 

The worse part about this whole thing is that it will bypass all of your security measures. I mean, for the most part, who is blocking powershell commands? As Administrator we use them all the time on all of our systems. Since it's just downloading files most web filtering will let it through. 

So how do you stop it? A couple things but not much (as far as I know at this point and time)

1. Use AppLocker to put Powershell in constrained language mode. 
2. Enable Powershell logging and (if possible) centrally collect it
3. Whitelist know scripts and dont let anything lese run powershell scripts. This can be done with AppLocker
4. Block port that you don't need

If I find any more info I will post it.

CREDIT

I want to thank Tanner Kinkead, tanner.kinkead@gmail.com for helping me decipher the code and filling in the missing pieces for me as well as the suggestions above on how to help prevent it.

Microsoft Azure - Networking

I've been getting my feet wet with Azure as we might be building a new infrastructure and services there.

We currently use VMWare so I am very familiar with creating VM's, networking them (even in different subnets, etc). I'm still getting used to the way Azure does networking, subnets and VPN's.

When creating a basic network inside Azure you need two things:

1.  Address Space
2.  Subnets

For those of us who have been building networks for years, this can sound extremely confusing. An address space is already part of a subnet. For example, if you have a network of 192.168.0.0/24, the /24 is your subnet. This gives you 256 IP's (192.168.0.1-0.255) and the subnet mask would be 255.255.255.0. So why do I need to create both? Shouldn't Azure just know what my address space is based on my subnets?

I can't speak for the Azure engineers but the only thing i can think of is they wanted organization and for it to be easy for people who have never created network before. 

You start by creating a new Virtual Network. When you create a new VNet, it will ask for your address space and a subnet.

ADDRESS SPACE

Let's start with the address space. This will be represented using a CIDR range. For example, you can get crazy and put in 192.168.0.0/16. This will give you a huge amount of IP's (192.168.0.1-192.168.255.254). You can name the Address space something like Main Network

Creating the address space is only the first step. Without creating a subnet you can't do much (at least in Azure). The address space in Azure is just a place holder letting Azure know the network space you want to work with and give your VM's. 

SUBNETS

Here is where you will break up your networks into logical chunks. Even though your address space is 192.168.0.0/16, your first subnet could be 192.168.0.0/24. This will give you IP's from 192.168.0.1-192.168.0.254. You can name the subnet something like Servers.

After you create this VNet, you can go back in an create more subnets where the VM's will live. You could create another subnet 192.168.1.0/24 and name it Desktops. 

One thing to keep in mind is that even though they are on different subnets, because they are in the same address space in Azure, they can talk to each other without needing a gateway (I mean, there is a gateway but Azure handles all of that in the background).

The only exception to this is if you create another address space, lets say 172.16.0.0/16. If you create this address space and then create subnets underneath that, you will need to create a VNet to VNet gateway if you want these to Address Space/Subnets to talk to each other. For this to work they must be in the same Azure location (IE, South Central US).

When you start creating new VM's you will be asked which Virtual Network you want to use and then which subnet you want to use.

VPNs

VPN's are a little confusing inside Azure. I hope to be able to do a more in depth post on VPN's but for now I will briefly discuss how you set them up.

Azure has pretty much three type of VPN's Point to site, Point to Point and Express Route. Broken down they are:

Point to Site - Point to Site is basically a windows client connecting to the Azure network.

Point to Point - Point to Point is what I know as Site to Site. You will need a VPN device to connect to Azure. 

Express Route - Express route is a direct connection from your office directly to an Azure data center. Its like an MPLS. It doesn't go through the internet. Its a direct private link to your Azure environment.

POINT TO SITE

To create a point to site you will need to go to your Virtual Network that you created, go to subnets and add a GatewaySubnet. I've been trying to find more info on why this is needed but I can't find a definitive answer. I'm assuming its a bridge between the Azure network and you. When you setup the GatewaySubnet, it will use a subnet from your available address space. Most articles say to give it a /28 or /27 CIDR to make sure you have enough IP's if you will be adding several VPN connections.

Once you create the GatewaySubnet, create a new Virtual Network Gateway. When creating this new VNet Gateway, make sure you select the correct VPN Type. Most people will use Route based (I had to use Policy based. I'll explain when i talk about Point to Point). 

Gateway Type will be VPN. Create a name, select your virtual network and Public IP (create a public IP if need be). Once you click create, it could take up to 45 minutes before its provisioned. 

Once the VNet Gateway is created, select it and select Point to Site Configuration. From here you will create an address pool and upload a root certificate. 

The address pool is the IP address the windows client will receive when connecting to the VPN. When creating and address pool make sure it doesn't conflict with anything on the Azure network side or your internal network side. I wont go into detail on how to create a root cert but you can do this using makecert.exe. I used the Windows 10 SDK to create both a root cert and a client cert. The root cert you have to export (without the private key) to a X509 certicate and upload the data (copy and paste from notepad) into the Public Certificate Data box inside the Point to Site configuration.

Once you have all of the info filled out you can save the configuration and then download the VPN client.

POINT TO POINT

Point to Point requires more work because you need to make sure you configure your VPN device correctly. I used a watchguard firewall. But you can use Cisco, Juniper, etc. One thing to keep in mind is if you will be using Policy based or Routing based VPN. My watchguard only does policy based. 

When I created my VNet Gateway initially I choose Policy based. Make sure you choose correctly. If you don't you will need to delete and recreate your VNet Gateway since the Point to Point VPN attaches to a VNet Gateway and you can only have one VNet Gateway attached to your Virtual Network. If you have multiple Virtual Networks then I assume you can have different VPN types.

Once you've determined the correct VPN type, create a Virtual Network Gateway if you don't have one already. Once you do that, you will need to create a new Local Network Gateway. Give it a name, the public IP address of your VPN device, your local IP address scheme in CIDR format that you use in your office, Azure location and click create.

Once its created go inside the Local Network Gateway and select connections under settings. 

Click add, give it a name, attach it to a virtual network gateway and a Local Network Gateway. The next option is a pre shared key. Make this key long and something you will remember. My device only accepts letters and numbers. This key will be used in Azure and your VPN device. 

Connection type should already say Site-To-Site and be grayed out.

Once you create this connection, you will need to setup your VPN device in your office. The Public IP for your office device to connect to will be listed in the Local Gateway Network under the connection you just created.

HERE is a link that shows whats devices are supported and if they are Policy based, Route based or both.

EXPRESS ROUTE

I have not been able to create an express route since we have not gotten to that point yet but from what I see you will need a circuit id that will be provided by your current (MPLS) provider. You will need to create an new ExpressRoute Network Connection and fill out the info. Your MPLS provider should have the info.

EDIT 4-23-18: To create an Express route you need to add it from the networking area. Once you do you will need the service key listed and you will give that to your MPLS provider. Once they have this they will provision the circuit. Here is where it gets confusing. Microsoft calls the network connection Peering. They have three types:

1. Azure Private
2. Azure Public
3. Microsoft

Azure private is what it says. It creates a connection from your MPLS to Azure without the need for a VPN.

Azure Public lets you connect to Azure Public IP's through a private link.

Microsoft lets you connect directly to O365 (Exchange Online, Sahrepoint, Skype, etc) and Dynamics Apps without going through the internet.

A few things to note:

1. Azure Public is being phased out.
2. To use Microsoft Peering you need permission from Microsoft before your MPLS provider will provision this for you.
3. Make sure you tell your MPLS provider which of the three you want.

Once it's provisioned they will give you some VLAN, ASN and IP info. you enter that info and then create a virtual gateway and then add a connection from inside the provision circuit and point it to the virtual gateway. When I did this everything started working since my MPLS provider was sending BGP and it knew what IP's were my local network. Microsoft support also did some stuff on their end as I did have to call support for some help. 

Thats about it. If I get a chance I might put pictures and more details in another post. I'll put each connection type in it's own post.

POLICY OR ROUTE BASED?

This is from Microsoft's Azure site:

What is a policy-based (static-routing) gateway?

Policy-based gateways implement policy-based VPNs. Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the combinations of address prefixes between your on-premises network and the Azure VNet. The policy (or Traffic Selector) is usually defined as an access list in the VPN configuration.

What is a route-based (dynamic-routing) gateway?

Route-based gateways implement the route-based VPNs. Route-based VPNs use "routes" in the IP forwarding or routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the tunnels. The policy or traffic selector for route based VPNs are configured as any-to-any (or wild cards).

Microsoft Azure - Networking

I've been getting my feet wet with Azure as we might be building a new infrastructure and services there.

We currently use VMWare so I am very familiar with creating VM's, networking them (even in different subnets, etc). I'm still getting used to the way Azure does networking, subnets and VPN's.

When creating a basic network inside Azure you need two things:

1.  Address Space
2.  Subnets

For those of us who have been building networks for years, this can sound extremely confusing. An address space is already part of a subnet. For example, if you have a network of 192.168.0.0/24, the /24 is your subnet. This gives you 256 IP's (192.168.0.1-0.255) and the subnet mask would be 255.255.255.0. So why do I need to create both? Shouldn't Azure just know what my address space is based on my subnets?

I can't speak for the Azure engineers but the only thing i can think of is they wanted organization and for it to be easy for people who have never created network before. 

You start by creating a new Virtual Network. When you create a new VNet, it will ask for your address space and a subnet.

ADDRESS SPACE

Let's start with the address space. This will be represented using a CIDR range. For example, you can get crazy and put in 192.168.0.0/16. This will give you a huge amount of IP's (192.168.0.1-192.168.255.254). You can name the Address space something like Main Network

Creating the address space is only the first step. Without creating a subnet you can't do much (at least in Azure). The address space in Azure is just a place holder letting Azure know the network space you want to work with and give your VM's. 

SUBNETS

Here is where you will break up your networks into logical chunks. Even though your address space is 192.168.0.0/16, your first subnet could be 192.168.0.0/24. This will give you IP's from 192.168.0.1-192.168.0.254. You can name the subnet something like Servers.

After you create this VNet, you can go back in an create more subnets where the VM's will live. You could create another subnet 192.168.1.0/24 and name it Desktops. 

One thing to keep in mind is that even though they are on different subnets, because they are in the same address space in Azure, they can talk to each other without needing a gateway (I mean, there is a gateway but Azure handles all of that in the background).

The only exception to this is if you create another address space, lets say 172.16.0.0/16. If you create this address space and then create subnets underneath that, you will need to create a VNet to VNet gateway if you want these to Address Space/Subnets to talk to each other. For this to work they must be in the same Azure location (IE, South Central US).

When you start creating new VM's you will be asked which Virtual Network you want to use and then which subnet you want to use.

VPNS

VPN's are a little confusing inside Azure. I hope to be able to do a more in depth post on VPN's but for now I will briefly discuss how you set them up.

Azure has pretty much three type of VPN's Point to site, Point to Point and Express Route. Borek down they are:

Point to Site - Point to Site is basically a windows client connecting to the Azure network.

Point to Point - Point to Point is what I know as Site to Site. You will need a VPN device to connect to Azure. 

Express Route - Express route is a direct connection from your office directly to an Azure data center. Its like an MPLS. It doesn't go through the internet. Its a direct private link to your Azure environment.

POINT TO SITE

To create a point to site you will need to go to your Virtual Network that you created, go to subnets and add a GatewaySubnet. I've been trying to find more info on why this is needed but I can't find a definitive answer. I'm assuming its a bridge between the Azure network and you. When you setup the GatewaySubnet, it will use a subnet from your available address space. Most articles say to give it a /28 or /27 CIDR to make sure you have enough IP's if you will be adding several VPN connections.

Once you create the GatewaySubnet, create a new Virtual Network Gateway. When creating this new VNet Gateway, make sure you select the correct VPN Type. Most people will use Route based (I had to use Policy based. I'll explain when i talk about Point to Point). 

Gateway Type will be VPN. Create a name, select your virtual network and Public IP (create a public IP if need be). Once you click create, it could take up to 45 minutes before its provisioned. 

Once the VNet Gateway is created, select it and select Point to Site Configuration. From here you will create an address pool and upload a root certificate. 

The address pool is the IP address the windows client will receive when connecting to the VPN. When creating and address pool make sure it doesn't conflict with anything on the Azure network side or your internal network side. I wont go into detail on how to create a root cert but you can do this using makecert.exe. I used the Windows 10 SDK to create both a root cert and a client cert. The root cert you have to export (without the private key) to a X509 certicate and upload the data (copy and paste from notepad) into the Public Certificate Data box inside the Point to Site configuration.

Once you have all of the info filled out you can save the configuration and then download the VPN client.

POINT TO POINT

Point to Point requires more work because you need to make sure you configure your VPN device correctly. I used a watchguard firewall. But you can use Cisco, Juniper, etc. One thing to keep in mind is if you will be using Policy based or Routing based VPN. My watchguard only does policy based. 

Policy based is using a static gateway and Routing based uses a Dynamic Gateway. 

When I created my VNet Gateway initially I choose Policy based. Make sure you choose correctly. If you don't you will need to delete and recreate your VNet Gateway since the Point to Point VPN attaches to a VNet Gateway and you can only have one VNet Gateway attached to your Virtual Network. If you have multiple Virtual Networks then I assume you can have different VPN types.

Once you've determined the correct VPN type, create a Virtual Network Gateway if you don't have one already. Once you do that, you will need to create a new Local Network Gateway. Give it a name, the public IP address of your VPN device, your local IP address scheme in CIDR format that you use in your office, Azure location and click create.

Once its created go inside the Local Network Gateway and select connections under settings. 

Click add, give it a name, attach it to a virtual network gateway and a Local Network Gateway. The next option is a pre shared key. Make this key long and something you will remember. My device only accepts letters and numbers. This key will be used in Azure and your VPN device. 

Connection type should already say Site-To-Site and be grayed out.

Once you create this connection, you will need to setup your VPN device in your office. The Public IP for your office device to connect to will be listed in the Local Gateway Network under the connection you just created.

HERE is a link that shows whats devices are supported and if they are Policy based, Route based or both.

EXPRESS ROUTE

I have not been able to create an express route since we have not gotten to that point yet but from what I see you will need a circuit id that will be provided by your current (MPLS) provider. You will need to create an new ExpressRoute Network Connection and fill out the info. Your MPLS provider should have the info.

Thats about it. If I get a chance I might put pictures and more details in another post. I'll put each connection type in it's own post.

File locked on Snap Server

We use Overland Snap Servers for some of our network shares. Sometimes a file will get locked and even if we try to close it using windows management with the correct user name and password of the server, it will tell us access is denied.

What I have to do is SSH to the snap server, log in and run this command:

lsof|grep -i /path/to/filename

This will give you a PID of the file.

Once you have the PID you can kill it with this command:

kill -9 pid

If you get any errors while trying to do the commands, make sure you are root. To do this on the snap server log in via SSH as the user you would normally log in on the web GUI. then type:

osshell

su -

It will ask for a password. This will be the same password you used to log in.

Minecraft - Spigot server Authentication Servers are down

My son has been begging me for a while to make him a Minecraft server. At the office we have a couple developers who have a couple servers in AWS that they may want me to take over. So I figured, this would be a good time to get familiar with AWS.

I setup AWS and created a micro ubuntu server and installed craftbukkit and spigot. Whenever we would logon, it would say the authentication servers were down when in fact they were up.

I found this on a post:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Seems to be an issue with ubuntu. After running this command I no longer got the errors.

Is Minecraft crashing on you (or your kids) when playing?

Normally I talk about servers and work related fixes but today I'm going a little off base and talking about a video game. The reason I am doing this is because even video games you have to troubleshoot at times.

My son is playing Minecraft and every so often it crashes with an error similar to this (I grabbed this from google images so its not the exact error, but close):

I looked high and low for a fix, updating video drivers and even moving to the new minecraft.exe launcher that supposedly doesn't need java. Nothing worked. 

The fix, as it turn out is to open the options.txt file and change fboEnable:true to fboEnable:false.

This little change seems to have fixed it. The way we found the fix was another kid saw his Minecraft crashing during a Minecraft league and helped us out.