If you are running FreeNAS, simply create a new jail from the jail template. If you are on FreeBSD, follow the instructions below.
|
|
|
|
|
|
|
|
/etc/jail.conf
and enter the appropriate configuration
|
|
fstab
file
|
|
|
|
|
|
|
|
mediagroup
and the group ID being 816
. For FreeNAS this can be done through the GUI, for FreeBSD run:
|
|
|
|
Enter the new jail. In FreeNAS you can click the terminal window. In FreeBSD, run jexec mediajail /bin/sh
If the jail is in an unsupported version of FreeBSD (looking at you FreeNAS), an unsupported version of sqlite3
is needed. Run the following, accepting all defaults
|
|
pkg install
with the application names. If you do not have Plex Pass, replace plexmediaserver-plexpass
with plexmediaserver
|
|
plexmediaserver_plexpass_enable=YES
with plexmediaserver_enable=YES
|
|
mediagroup
group in the jail and add all the appliation accounts needed
|
|
|
|
localhost
initially. First, stop sabnzbd
|
|
|
|
sabnzbd
|
|
|
|
Run through the initial setup of SABnzbd, inputting the language and news server details.
Once in SABnzbd, click on the cog in the top right corner to get to the settings.Click on the cog on the top to get to “General” settings.
Set up a username and password, then click “Save Changes”.
Go to the “Folders” settings and click “Advanced Settings”. Set the “Temporary Download Folder” to:
|
|
|
|
775
then press “Save Changes”.localhost
initially, same as SABnzbd. First, stop transmission
|
|
settings.json
and edit the following lines:
|
|
|
|
|
|
|
|
|
|
Go to “Settings” and then “General”
Change the “URL Base” to:
|
|
Forms
and enter a Username and Password. Click “Save”.
|
|
Go to “Settings” and then “General”
Change the “URL Base” to:
|
|
Forms
and enter a Username and Password. Click “Save”.
|
|
/usr/local/etc/nginx/nginx.conf
in an editor and change to the following, changing when needed
|
|
|
|
|
|
|
|
visudo
|
|
You can now access services through the following:
<hostname>
/sonarr<hostname>
/radarr<hostname>
/sabnzbd<hostname>
/transmissionTrusted root CAs are organizations that have protocols in place to issue certificates at different levels. They are audited regularly and comply to ISO standards. A list of all root CAs that have completed these requirements are provided and updated regularly by most operating systems:
More often than not, certificates used on the internet are not issued by a root CA, but instead from an intermediate CA. One of the many reasons is that if the intermediate CA were to be compromised, the root CA can issue out a revocation that tells clients not to trust any certificate by that intermediate CA. There can be multiple levels of intermediate CA’s underneath a root CA.
Just as root CAs generally don’t issue client certificates, intermediate CAs don’t have to issue client certificates either. When a CA starts issuing certificates to clients, it is called an issuing CA.
The CDP (CRL distribution point) is a network location that is stamped on to a certificate when it is issued from a CA. It contains one or many CRLs (certificate revocation list). A CRL is a file that the client reads to see if any issued certificates have been revoked. CRLs in the CDP are usually updated automatically by the CA software itself. The exception to this are root CAs, which are generally kept offline. This CRL needs to be updated manually and transferred from the airgapped system to the CDP accessible by clients on the internet (or network, if it is LAN CA). There can be a CRL and multiple delta CRLs, which contain changes in between CRL refresh periods. This helps to keep download sizes minimal.
OCSP (Online Certificate Status Protocol) is a great alternative to CRLs. The OCSP responder server URI is stamped on to the certicate when it is issued from the CA. When the client needs to check the status of a certificate, it sends the serial number of the certificate to the OCSP responder to check if it is still valid. The server then responds with the status. It uses much less bandwidth than a CDP with CRLs and delta CRLs.
Best practice guidance from Microsoft suggests the following infrastructure:
There are three different types of certificates, each with different levels of trust and verification.
This is the base type of certificate. All that is usually needed to verify ownership of the domain is to add a TXT record, or click on a link sent to admin@domain.com
. Whilst the encryption being used can be the same as the higher certificates, the level of trust may be low.
This certificate type requires further verification. Normally it requires an exchange of physical documents to prove ownership of the business that the domain name is representing.
This certificate has the highest level of trust. When applied to a website, users’ web browsers show a green bar. It has the following requirements:
It is not currently possible to get a wildcard EV certificate - it is just for the domains in the certificate request.
A certificate contains the following information:
Symmetric encryption is used when both parties have the same encryption key.
Asymmetric encryption is used when both parties have different encryption keys. This is more commonly called public/private key encryption. The keys are generated at the same time. Anything encrypted with the private key can be decrypted by the public key, and vice-versa.
TLS uses a combination of both asymmetric and symmetric encryption whilst communicating.
ClientHello
message to the server, which specifies the highest TLS protocol it supports, a random number, a list of ciphers it supports and a list of compression methods it supports.ServerHello
message to the client, containing the TLS protocol, compression method and cipher from the lists sent from the user, as well as a random number. The server may also send a session ID, however this is not mandatory.Certificate
(which contains the public key of the server, and is verified by a third-party) and a ServerKeyExchange
message, depending on the cipher suite. The server can also send a CertificateRequest
message if mutual certificate authentication is being used.ServerHelloDone
message, to show it is done with handshake negotiation.Certificate
message (if mutual certificate authentication is being used).ClientKeyExchange
message, which contains either a PreMasterSecret
, public key, or nothing. It is encrypted with the public key of the server certificate.CertificateVerify
message, which is a signature for the previous client handshake messages and is generated using the client private key. It can be verified with the client public key.PreMasterSecret
to generate a common shared secret. This is called the master secret
. All future data is encrypted with this secret and a psudorandom function.ChangeCipherSpec
message. This lets the server know that the cient will only talk in that cipher for the rest of the session.Finished
message that contains a hash of all the previous handshake messages. If this fails at the server end, the TLS connection is not considered valid and will be torn down.ChangeCipherSpec
message. This lets the client know that the server will only talk in that server for the rest of the session.Finished
message that contains a hash of all the previous handshake messages. If this fails at the client end, the TLS connection is not considered valid and will be torn down.The handshake is now complete and now that both ends have the same master secret
, they can switch to symmetric encryption, which is computationally much less expensive.
TLS versions and ciphers are independent of certificates, and can be changed at any time on the server. This may have implications with client support, however nearly all modern clients have support for TLS 1.2 (the latest version as of this blog post).
SSL 3.0 was first introducted in 1996. It has been depreciated by the IETF since 2015 and is not considered secure. It should no longer be used, as it has been broken due to multiple vulnerabilities (POODLE, DROWN, etc).
TLS 1.0 supports downgrade negitiation, allowing an attacker to bring the server back down to SSL 3.0, and therefore bringing the vulnerabilities with it. It should also no longer be used. It does however allow the use of better ciphers than SSL 3.0
TLS 1.1 should be considered the bare minimum for TLS-protected communications. No protocol-level vulnerabilities have been found so far. It provides protection against padding errors (the basis of the POODLE attack).
TLS 1.2 is the newest TLS protocol, introduced in 2008. It is currently the strongest TLS protocol.
TLS 1.3 is currently a working draft with the IETF and is not released for general use yet.
Along with the TLS protocol version, the client and server also negotiate a cipher to communicate with. The ciphers considered secure change as cracking technology progresses and vulnerabilities are found.
I’ve found that https://cipherli.st/ is a great resource for server cipher list configuration, and https://www.ssllabs.com/ssltest/ is great for testing your site.
]]>First, clone the skeleton snapshot to the thinjails directory for each jail:
|
|
Next, create the mount folders for the jails
|
|
Add the configurations for the jails in /etc/jail.conf
|
|
Create a fstab file for each jail at /usr/local/jails/<jailname>.fstab
, replacing <jailname>
with the jail name of each.
|
|
Create and start jails
|
|
Add jails to auto-start on boot in /etc/rc.conf
|
|
Enter jail, replacing <id>
with the ID of the Sonarr jail shown in jls
output
|
|
Install Sonarr, answering yes
to installing pkg
and the package itself
|
|
Enable and start Sonarr
|
|
Enter jail, replacing <id>
with the ID of the Radarr jail shown in jls
output
|
|
Install Radarr, answering yes
to installing pkg
and the package itself
|
|
Enable and start Radarr
|
|
Enter jail, replacing <id>
with the ID of the SABnzbd jail shown in jls
output
|
|
Install SABbnzbd, answering “yes” to installing pkg and the package itself
|
|
Enable and start SABbnzbd
|
|
Enter jail, replacing <id>
with the ID of the Plex jail shown in jls
output
|
|
Install Plex, answering “yes” to installing pkg and the package itself
|
|
Enable and start Plex
|
|
Enter jail, replacing <id>
with the ID of the nginx jail shown in jls
output
|
|
Install nginx, answering “yes” to installing pkg and the package itself
|
|
Enable nginx
|
|
Edit /usr/local/etc/nginx/nginx.conf
|
|
Start nginx
|
|
I will follow up this blog post with another detailing integration with the jails.
]]>I was tempted to run a jail management tool such as ezjail, iocage or qjail, however configuring manually through jail.conf and the jail command seems to be quite easy once you wrap your head around it. This guide walks through building a base jail template that can easily be added as a layer to new jails. This approach is great as you only need to update one layer when OS-level updates get released.
First, enable jails in your OS.
|
|
Create a dataset for the jails and thinjails
|
|
Then, create another dataset for the 11.0-RELEASE files
|
|
Download and extract all required binaries from a FreeBSD mirror. I chose Optus Australia as that is my closest/fastest mirror.
|
|
Update to latest patch level (p10 at the release of this blog post)
|
|
Verify nothing was damaged in transit (this is more paranoia than anything…)
|
|
Add local timezone and DNS servers to files
|
|
Snapshot the release. Since mine is patch level 10, I chose the name p10
|
|
Clone the 11.0-RELEASE
snapshot to a new base jail. This will be the first layer in future jails.
|
|
Create a skeleton dataset that will be used for jail-specific files
|
|
Create folders in skeleton dataset
|
|
Move folders from the base jail layer to the skeleton jail layer. These are jail-specific directories.
|
|
For some reason /var/empty
still remained when I moved the folders, so I had to remove it manually.
|
|
Symlink the directories to the skeleton layer. Make sure you are in /usr/local/jails/templates/base-11.0-RELEASE/
folder before running the commands, as the paths are all relative.
|
|
Update the ports make configuration to build in the non-default directory
|
|
Snapshot the skeleton so we can clone it in each jail
|
|
Create /etc/jail.conf with the below text. I have added comments to explain each section.
|
|
Done! We now have the components to create many thin jails. Now we will create our first thin jail off this template.
First, clone the skeleton files for the new jail, and then set the hostname
|
|
Create folder where the layers for the jail will be mounted
|
|
Create fstab at /usr/local/jails/jail1.fstab
. The first layer is the base, mounted as read-only. The next is the skeleton we cloned, mounted as read-write.
|
|
Create and start jail “jail1”
|
|
Add jail to auto-start on boot in /etc/rc.conf
|
|
For each new jail, just follow the process:
/etc/jail.conf
/usr/local/jails/thinjails/<jailname>
/etc/rc.conf
in new jail files/usr/local/jails/<jailname>
for new jail/usr/local/jails/<jailname>.fstab
and populate with layer informationjail -c jailname
Whenever we want to update all jails at once, shut down the jails and run:
|
|
This will update the base to the latest patch level, and update to the latest ports tree.
]]>foglight
.
/usr/local/tomcat/conf
directoryfoglight
for all password prompts: /usr/local/jre1.6.0_43/bin/keytool -importkeystore -srckeystore /usr/local/tomcat/conf/foglight.pfx -srcstoretype pkcs12 -destkeystore /usr/local/tomcat/conf/foglight.jks -deststoretype JKS
/usr/local/tomcat/conf/server.xml
in your favourite editorReplace the Connector section with SSL with the following:
|
|
Restart Tomcat with service tomcat restart
After a restart, the web interface will now be using the new certificate.
For reference, the username and password for the appliance is vkernel/vkernel
and the su
password is password
.
It was roughly copied from a Reddit thread (link) however it had a few bugs relating to fine-grained password policies and was using .NET methods for a few things instead of Powershell cmdlets.
Hope it comes in useful for someone.
]]>Enjoy!
]]>vkernel
and password is vkernel
also.su -
. Default password is password
.nano /usr/local/tomcat/conf/server.xml
to edit the Tomcat config file.<Connector server="VKernel" port="443" maxHttpHeaderSize="8192" ....
), you will find a cipher list like ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ...."
. Replace this with: ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
Ctrl + X
and then y
to save the file.service tomcat stop
then service tomcat start
to reload the config fileYou should now be able to access the site properly with Chrome v45+.
]]>http://h17007.www1.hp.com/us/en/enterprise/servers/products/service_pack/spp/index.aspx
]]>MAIL_E_NAMEN
error and then WSAECONNRESET
.Use with .\BitLocker-ACE.ps1 -Read
to check if the ACE is already there and .\BitLocker-ACE.ps1 -Write
to create the ACE.
If your environment uses a proxy to connect to the internet, continue with this section. If not, skip.
First, create a new directory to store the extra configuration.
|
|
Next, create a http-proxy.conf
file in the directory and edit it.
|
|
Add the following information to the file (substituting where necessary) and save with Ctrl + X
.
|
|
Reload the systemd
daemon and restart Docker.
|
|
Docker now has access to the internet.
By default, Docker only allows connection through UNIX sockets. Since we will be controlling it via the Windows client, we need TCP access.
Open up the Docker service file in nano
|
|
Edit the Service -> ExecStart
line to allow TCP connections by changing:
|
|
to
|
|
Reload the systemd
daemon and restart Docker.
|
|
Photon comes with Docker 1.5.0 but unfortunately the Windows client only works with 1.6.0 and above.
If you are using a corporate proxy, you will first need to set the http_proxy
environmental variable so wget
works
|
|
Download the Docker 1.6.0 binary
|
|
Move the binary to /bin/
and mark it as executable
|
|
You will now have Docker 1.6.0 running.
Download Docker 1.6.0 for Windows from Docker.com - 32-bit or 64-bit and open PowerShell in that directory. At this point I recommend renaming the file to docker.exe
.
To connect to the Photon host, run the following:
|
|
This will show information about the Docker host like so:
|
|
You are now connected!
]]>Connect-MsolService
.
|
|
You can add more switches for more license types but we only use E3 and E1. Types are:
|
|
Enjoy.
]]>The script should be run as the user whos mailbox will be monitored (ours is set up as a scheduled task). Next, it should have to subfolders called “Error” and “Processed”. Successful emails get marked as read and send to “Processed”, and unsuccessful emails get kept as unread and moved to “Error”. Because we send from some systems that don’t have SMTP authentication, there is a field called “Secret” that should be defined at the top of the PowerShell script and put in each email.
The format for the email is:
|
|
The script is set to run every 20 seconds.
]]>Install VMware Player from the VMware website
Get the Managed Object ID of the VM. This can be done through PowerCLI with the following script:
|
|
Give the user access to the VM. The permission “Virtual Machine\Interaction\Console Interation” needs to be given on both the VM and the host. It doesn’t need to inherit to children so deselect “Propagate to children” in the permisisons screen”.
Create a shortcut to connect straight to the VM. The following PowerShell script can create the shortcut automatically.
|
|
Afterwards, double click on the shortcut on the desktop and enter appropriate credentials. You’ll be straight in to the console.
]]>Simply save the file as pydio.ps1 and run it on the target server. Make sure to download the prerequisite files (PHP, VC++ 2012 Redistributable, PHP Manager for IIS) and put them in an accessible location.
]]>