[[Support] Linuxserver.io - OpenVPN AS]

No comment from them on when they will upgrade openvpn-as to openvpn 2.4 but it seems it is not necessary anyway as the config options to avoid this are available now. They are described in https://sweet32.info/ as either a client side only option

reneg-bytes 64000000

Alternatively, if you control the server and client, then you can set on both the server and client config directives (via the Advanced VPN page)

cipher AES-256-CBC

It doesn't seem there is a way to set this via the cli or in config so I don't suppose there is anything you can do to set this in the container. I suppose you could add something to the setup docs though. 

 

FWIW further reading suggests to use a few other directives, namely to set server and client as follows for a reasonably hardened config

cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256

This seems to work fine for me.

 

The support guy also commented on the possibility of an attack via the embedded twisted web server which I'll just post here for reference

 

Quote

And if you are referring to sweet32 vulnerable cipher being used on the web services, then you can adjust the web services to disable any ciphers you don't want to use. Usually this means adding !3DES to the cipher suite string or such. 

This issue has nothing to do with version of OpenVPN at all.

The OpenVPN Access Server program has a built-in web server that is based on Twisted (Python) web server, but modified for enhanced security. Because the security on web servers in regards to SSL/TLS encryption is an area of encryption that constantly changes due to ongoing research into how to improve security and how to break older, less secure, encryption methods, we have made it possible to change the encryption scheme used into a custom set of ciphers.

In the Admin UI, under SSL Settings, there are 3 sections. The first is to select OpenSSL or PolarSSL, and we recommend the default; OpenSSL. Another is for the TLS level used by the OpenVPN daemons, by which the default is usually TLS 1.0 (default). We generally recommend that this is not changed unless you have a specific need to. This particular OpenVPN daemons setting does not affect the web services but it affects the VPN tunnels themselves. But the other setting, for the OpenVPN web services, does affect the web services. We recommend that this setting is TLS 1.0 or higher. Please choose your preferred setting here. What you prefer in general hinges on current recommendations on security and compatibility for web browsers. This changes with time. For example, there was a time when Internet Explorer 6 was widely used, and TLS 1.2 simply would not work on this, making it impossible for IE6 users to connect. As time passes, these older browsers are no longer used and more secure methods can be used. We advise that you look up recommendations online for the current state of security and compatibility for web browsers. Our recommendation is TLS 1.0 to be compatible and reasonably safe.

The web server also uses a cipher string. This cipher string is in OpenSSL standard format and defines which encryption methods for the web browser sessions are allowed or specifically disallowed. We do have a recommendation ourselves, but, again, as time passes, this will likely change. For example at some point 3DES was an acceptable cipher string, but now it is no longer, because a vulnerability has been found it that makes it possible to crack it. Not very easily so, but still possible, and thus the recommendation now is to disable this. Again we refer to resources online to look up recommendations on the current state of security and compatibility for web browsers. And if you are using a security program that scans for vulnerabilities and reports a specific cipher as undesirable, please look up in the OpenSSL documentation how to disable this in the cipher string, and then implement this change in the cipher string used by the Access Server.

Below links are for the OpenSSL cipher string documentation and our documentation on how to change the cipher string in the OpenVPN Access Server. The commands mentioned in our documentation are meant to be run on the OpenVPN Access Server operating system itself, as root user, in the /usr/local/openvpn_as/scripts/ folder.

https://www.openssl.org/docs/man1.0.2/apps/ciphers.html
https://docs.openvpn.net/docs/access-server/openvpn-access-server-command-line-tools.html#selecting-web-server-ciphersuites

 

 

[[Support] Linuxserver.io - OpenVPN AS]

I can't find a public repo for openvpn-as & it seems they use a trac instance on their site instead of github for issues so I logged a support ticket.

[[Support] Linuxserver.io - OpenVPN AS]

I've added this to my setup recently, v easy to get going so thanks for providing it. 

 

I'm using a 2.4.3 openvpn client and I notice it complains about 

WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.
Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).'

This seems to be  https://community.openvpn.net/openvpn/wiki/SWEET32 

 

The container logs indicate this is a 2.3.17 server

 

2017-08-04 17:14:46+0100 [-] OVPN 0 OUT: 'Fri Aug  4 17:14:46 2017 OpenVPN 2.3.17 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 27 2017'

https://openvpn.net/index.php/open-source/downloads.html indicates this is the old stable version, 2.4.3 is the current stable and this seems to be the fix (e.g. picking some other random docker openvpn container - https://github.com/kylemanna/docker-openvpn/issues/267) .

 

I notice that your dependency is on https://openvpn.net/index.php/access-server/download-openvpn-as-sw.html for ubuntu 16 and it's not immediately obvious how this relates to the openvpn version. Do you have a plan to close this gap?

 

[Dynamix File Integrity plugin]

Over the last few weeks my server has been getting random kernel warnings. I have been trying to figure out why they are happening all of the sudden and I think they have something to do with this plugin. After updating to the latest plugin I started running the initial build and export on both of my disks. This kernel warning happened right after I started that process. Does any of this log mean anything too you?

bts buffer is the branch trace store buffer, google indicates there was a patch last year to reduce the frequency of such logs & whether it happens or not is a function of memory fragmentation. I would think that seeing this is just a sign that this plugin is working your CPU hard. Any other problems noted or just that warn?

[Dynamix File Integrity plugin]

Thanks for your observation.

 

I have seen in the past that RFS can have issues in V6 when writing extended attributes and once in a blue moon completely hangs. I am going to put a BIG warning that using this plugin in combination with RFS may lead to instability.

 

WARNING: USING THIS PLUGIN ON DISKS FORMATTED IN REISERFS MAY LEAD TO SYSTEM INSTABILITY. IT IS ADVISED TO USE XFS.

OK thanks, good to have an explanation for the behaviour.

[Dynamix File Integrity plugin]

I installed this earlier and it almost immediately triggered the reiser issue described in https://lime-technology.com/forum/index.php?topic=39911.0 which I've never seen before, by "almost immediately" I mean "within a minute or so".

 

emhttp was then hung and wa times were at ~50% or so & it seems this was due to a bs2sum process being stuck in D state (hence unkillable even by kill -9) as it attempted to calculate the hash for some particular file, the offending disk was thus unmountable and a hard reset was the only way out. The system itself was still responsive through all this, just emhttp and that zombie process was the (big) problem.

 

The disk in question has been running solidly for a shade over 2yrs and no other disk issues noted until now on that sata controller. reiserfsck has just finished on the offending disk and no issues noted (some journal replay action but nothing else to report), smart report is also completely clear.

 

It's not obvious how your plugin could trigger this (as opposed to some previously unexploited weakness in my system) but thought I'd mention it anyway. 

[Post your known good Xen hardware configs]

System "Name" - Debian jessie

Xen capable? - Yes

PCI Passthrough capable? - Yes

 

• Case - 3u server case
  
• CPU - Intel i5-4570
  
• Motherboard- asrock z87 extreme 6
  
• GPU - Intel hd4600
  
• RAM 8G ddr3
  
• PSU - thermaltake sp550-m
  
• HBA / SAS Card - N/A (Mobo has 2 sata controllers)
  
• NIC(s) - dual onboard Intel NICs bonded with ifenslave in 802.3ad LAG mode and assigned to xenbr0
  
• Hard drives - Samsung evo 840 + WD Reds 2TB
  

 

Brief description of VMs and use cases

 

Dom0 - debian jessie

DomU1 - unraid

DomU2 - Logitech media server

 

Sent from my Nexus 7 using Tapatalk

 

[unRAID Virtualization FAQ inc example .cfg files]

vt-d is required for passthrough to an HVM and is highly recommended, but not required, for passthrough to a PV.

 

VT-d (or AMD-Vi) is required for device passthrough PERIOD, regardless of the type of VM you are passing it to.

 

Perhaps you were referring to VT-x (or AMD-V)?  VT-x is required for HVM, but has nothing to do with passthrough.  It is not required for PV, nor am I aware of an instance where it's recommended.

i was quoting the xen wiki earlier.

 

No iommu means a security flaw but this doesn't seem like a massive concern in a home network (opinions may vary of course). Full details on the relevant page -  http://wiki.xen.org/wiki/Xen_PCI_Passthrough

 

A quick Google shows examples of people using this feature recently - http://comments.gmane.org/gmane.comp.emulators.xen.user/80723

 

[unRAID Virtualization FAQ inc example .cfg files]

A few thoughts

 

* shouldn't this be on the wiki itself? I think a page like this should start with the use cases, i.e. give people a reason to care.

* you start by saying "you need xyz in order to do abc" but then don't say how to determine whether you have xyz

* annotating each section with links to the relevant bits of the xen wiki for further reading would make sense

* a factual inaccuracy

 

In English, that means your CPU / motherboard must be of a certain standard to make the cut for HVM. Intel requires vt-d (check the ark part of the intel site if you're unsure) and AMD have AMD-V technology (I'm not as familiar with this). Intel K series processors are generally not supported, but in addition to the CPU supporting vt-d, your motherboard and more specifically your exact BIOS revision must as well.

you're conflating HVM and IOMMU, as the xen wiki says

 

Note that IOMMU/VT-d support is not the same as HVM support; it is possible to have HVM support without an IOMMU, or vice versa.

 

vt-d is required for passthrough to an HVM and is highly recommended, but not required, for passthrough to a PV.