Disable TLS 1.0 and 1.1 on ESXi 6.5, et. al. (Enable TLS 1.2)

Problem:

TLS Version 1.0 and 1.1 Protocol Detection (Nessus Plugins #104743 and #157288) on ESXi hosts.

Solution:

To mitigate this, we disable TLS 1.0 and 1.1 on our cluster(s) via SSH shell on our VCSA as well as SSH shell on the ESXi host(s). We ultimately put ESXi hosts into Maintenance mode and reboot. Please see the detailed step below. if for some reason you do not use clusters, then please reference the sources i’v elisted below and be sure to correct the command-line path location whcih has changed in 6.5+; otherwise the commands should work.

Sources:

I’ve used the following resources to enable SSH as well as disable TLS. I am not the originator, and the resources may be slightly stale, but still a very good reference froom which i solved my issues.

• Enable/Disable SSH via PowerCli (short version): https://vmmasterblog.wordpress.com/2016/07/08/enabledisable-ssh-on-all-esxi-hosts/
• Enable/Disable SSH via PowerCli (long version): https://discoposse.com/2013/10/09/powercli-enabling-and-disabling-ssh-on-vsphere-hosts/
• Disable TLS 1.0 and TLS 1.1 on vCenter as well as ESXI Hosts: http://www.nuthouse.us/vsphere/2018/10/07/TLSDisable.html

Steps:

1. Enable SSH and BASH on VCSA (vCenter Server Appliance)
   

   
   
   
   
   
   
   

2. Disable TLS 1.0 in vCenter. Use the reconfigureESX command to enable only TLS 1.1 and TLS 1.2.
   (alternatively, only TLS 1.2, if inclined to do so.)
   
   a) ssh into your vCenter and launch the bash shell
   
   

   
   
   
b) Execute the command: (note to remove the 1.1 if inclined)
/usr/lib/vmware-TlsReconfigurator/EsxTlsReconfigurator/reconfigureEsx vCenterCluster -c 'MY-CLUSTER' -u 'ADMIN-USER' -p TLSv1.1 TLSv1.2` , where the cluster is your cluster name and your administrative user is your privileged AD (Active Directory) account or administrator@vsphere.local account.

For security reasons, revert SSH and BASH to disabled state on vCenter.

Enable SSH on ESXi hosts and per sources listed above.

Disable TLS 1.0 and TLS1.1 on ESXi host(s) via SSH shell: (alternatively only TLS1.0, edit appropriately)
a) backup existing watchdog config: cp -p /etc/sfcb/sfcb.cfg /etc/sfcb/sfcb.bak
b) stop watchdog: /etc/init.d/sfcbd-watchdog stop
c) disable protocols and set ciphers in sfcb.cfg with new settings:

echo -e "enableSSLv3: false" >> /etc/sfcb/sfcb.cfg
echo -e "enableTLSv1: false" >> /etc/sfcb/sfcb.cfg
echo -e "enableTLSv1_1: false" >> /etc/sfcb/sfcb.cfg
echo -e "enableTLSv1_2: true" >> /etc/sfcb/sfcb.cfg
echo -e "sslCipherList:ECDHE-RSA-AES256-GCM-SHA384:HIGH:!AECDH-AES256-SHA:!AECDH-DES-CBC3-SHA:!AECDH-AES128-SHA:!AES128-SHA:!AES128-SHA256:!AES128-GCM-SHA256:!AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384:!AECDH-AES256-SHA:!CAMELLIA128-SHA:!CAMELLIA256-SHA" >> /etc/sfcb/sfcb.cfg

d) start watchdog: /etc/init.d/sfcbd-watchdog start

e) backup existing httppproxy config: cp -p /etc/vmware/rhttpproxy/config.xml /etc/vmware/rhttpproxy/config.bak

f) set ciphers with: sed -i '/following node to disable SSL -->/a\ <cipherList>ECDHE-RSA-AES256-GCM-SHA384:!aNULL:!AES128-SHA:!AES128-SHA256:!AES128-GCM-SHA256:!AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384<\/cipherList>' /etc/vmware/rhttpproxy/config.xml

g) restart httpproxy: /etc/init.d/rhttpproxy restart

For security reasons, disable SSH again for each ESXi host as per sources listed above.

For Each ESXi host, but only one at a time, enter maintenance-mode, then reboot.

Re-running Nessus scans should now produce clean results for TLS 1.0 (and alternatively TLS 1.1).

~~~
good luck!

Please consider crypto tipping:
  

SSH - no matching cipher found

Edit: Please do your research, this may re-introduce vulnerable ciphers -- i don't have time to be safe. lmao.  
Please reference https://stribika.github.io/2015/01/04/secure-secure-shell.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After a recent update of either Debian testing (Jessie) or OSX (Mavericks), I could no longer SSH from OSX into my Debian testing boxes.

I really don't know which OS update was at fault, but when I tried to SSH into my Debian testing boxes, i received the following message:

no matching cipher found: client blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

I can't have that -- my daughter needed to play on the minecraft server and she NEEDED TO PLAY NOW!

What this told me is that that my client (OSX) expected blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc but my server (Debian) supported aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

That sucks; stupid computer! (Wow, had not said that once since leaving Windows®)

Via web searches, I found that I could force a cipher like so: ssh -c aes128-ctr username@hostname so i did successfully. (I could just as well used ssh -c none username@hostname, but that's risky)

Once logged into my Debian box(es), I edited the ssh daemon config:

sudo nano /etc/ssh/sshd_config

and added the following to the bottom:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

As you can see, since I didn't know if there is an order of preference or not, I erred on the safe side and added the previously supported server ciphers before the client's expected ciphers.

Afterward I had to restart and verify the SSH Daemon:

sudo service sshd restart ; sudo service sshd status

On my OSX client, I tried to SSH and it complained WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! .. Oh my lord the world will end.

An easy fix was ssh-keygen -R hostname, where hostname was my Debian's hostname or IP obviosuly.

Now it worked as expected (and should have never failed in the first place).

-end-

But Daddy, you forgot the minecraft server... START THE MINECRAFT SERVER NOW!

~~~
As always, good luck!

Please consider crypto tipping:
  

Replacing LogMeIn with TeamViewer on OSX and Linux

LogMeIn is no longer free and I'm not paying!

There are many remote desktop solutions and I have multiple ways of seeing my Linux desktop in emergency, but I've found TeamViewer (free for personal use) is a great replacement of LogMeIn on OSX.

I was accustomed to LogMeIn on OSX because it was always running and quite simple to remote from the web-console, LogMeIn Ignition, or even Android and iOS.  TeamViewer, although not the prettiest interface, works the same, supports multiple monitors, and even supports Linux. It also has advanced features such as file-transfer, meeting-mode, and video/audio conferencing -- but I'm not one to utilize such. TeamViewer does indeed have Android and iOS clients as well.

Go ahead and install the "All-In-One: TeamViewer full version" from TeamViewer.com/en/download for either Linux or OSX or both. If you choose, make them run at startup (as a daemon (service)). I also have a way around this as you will see further down.

Now the key settings to make TeamViewer work like LogMeIn is the following:

1) Create an account on TeamViewer.com !
2) Assign your client(s) to your account: TeamViewer>Preferences>General>Assign to account.
3) Set your client to unattended mode: TeamViewer>Preferences>Security>Password.

Presto change-o -- a LogMeIn replacement!

===============================================================


* The issue mentioned below seems to be fix in recent versions; However, I'll keep this info available: 


I had one issue that bugged me: On Linux, the client constantly bugged me with a pop-up and reported "click to disable" (the pop-up).  But it would never disable, no matter what.  So my solution is to NOT run TeamViewer upon startup; HOWEVER, I can still launch it via remote SSH login.

The key to this is that I still run LogMeIn Hamachi (Mesh VPN) on all my machines so that I always have SSH access to any of them (as long as Hamachi doesn't fail).

Now, from a remote machine, SSH into the Linux machine and perform the following:

env DISPLAY=:0 teamviewer

Don't close your SSH (preferably, run it from screen). This will set the GUI of TeamViewer to the default display (the monitor) and launch it properly -- now TeamViewer should be ready for a client connection.  (If it does not launch, see below regarding the daemon start command)

------------------------------------------------------------------------------------------------------------

Similarly, this can be done with OSX, but there seems to be a bug that requires a particular work-around that I was lucky to notice.  TeamViewer will need to be run twice -- once as sudo, and another as the user:

SSH into the OSX machine and run TeamViewer like so:

sudo /Applications/TeamViewer.app/Contents/MacOS/TeamViewer 

It should fail and report:
com.teamviewer.desktop: Invalid argument
com.teamviewer.teamviewer: Invalid argument

Now run it again without sudo:

/Applications/TeamViewer.app/Contents/MacOS/TeamViewer

This should launch TeamViewer and make it ready for a client connection.

If for some reason it fails to launch, try setting the display first with:

export DISPLAY=:0

===============================================================

I've had some occasions where the programs stay running or won't relaunch properly.  It's probably best to quit the program from the desktop GUI, but if all else fails, in Linux, we can use the killall command to stop the processes:

killall teamviewer
killall wineserver
killall TeamViewer.exe
sudo killall teamviewerd

(It turns out TeamViewer for Linux actually runs a custom version of wine to emulate the windows version.)

You should restart the daemon service after any kills, as the GUI client will not run without:

sudo teamviewer --daemon start

In OSX, it seems I could only quit TeamViewer from the Desktop and unfortunately not use the killall nor the kill commands.

You may have better success, you can find the processes with the following command:

ps aux | grep [Tt]eam[Vv]iewer

===============================================================

Other free options that you may research -- but likely require direct network connectivity or VPN and therefore do not work like LogMeIn or TeamViewer for "from anywhere" remote access:

Both Linux and OSX:
X11 Forwarding over SSH
NoMachine.com (NXRemote) -- I had played with version 3 which was SSH secure and as fast as RDP.  It created virtual desktops like RDP, but I had issues keeping it working.  Version 4 is now available and works differently -- it now connects to the actual desktop much as LogMeIn or x11vnc.  It is, however, direct access only until they release "NoMachine Anywhere." Android and iOS clients are in Alpha and not yet released.

OSX:
Preferences>Sharing>Screen Sharing (VNC) (There commandlines/files to enable, but different versions of OSX have different commands, so you may research that on your own.)

Linux (likely in your repositories) :
xrdp - RDP for X !
A ton of different VNC servers, but i like x11vnc best.

===============================================================

Related to the subject, here are RDP Clients:

OSX:
Microsoft RDP Client v2.1.1
Microsoft RDP Client v8.x (on a domain, use the "DOMAIN\username" syntax) ; Available on iOS also!

Linux (likely in your repositories):
Remmina+freerdp (xfreerdp) -- supports Microsoft's Network Level Authentication (NLA).

===============================================================

Related to the subject, here are alternatives to Hamachi (listing only cross-platform solutions):

ZeroTier One (RECOMMENDED - i have move off of hamachi onto this; with great success)
n2n - a Layer Two Peer-to-Peer VPN
SoftEther VPN Project
tinc vpn
freelan (no redhat, et al?)
Remobo -- I had tried this a long time ago, but didn't like it so much.  It might be worth a revisit.
NeoRouter Free (as opposed to the Mesh and Pro versions)

=========
Good Luck!
=========


Please consider crypto tipping:
  

Holy X11 Batman (RDP via ssh X11Forwarding from an OSX host over VPN -- it's true!)

Can it be true??? YES it IS... with a caveat I hope you solve for me...
The caveat is with a Linux client; I've verified OSX to OSX has no issue.

Scenario: I wanted to ssh into my Mac Pro at work from my Linux box at home and launch RDP via X11Forwarding.  Of course, from-Linux to-Linux is a non-issue, but in this case my host is OSX.  I got to playing, and the surprise was joyous.

Setup/Prerequisites:
 Client: Linux or OSX
 Host: OSX 10.8
 VPN: Hamachi (Hamachi for Linux in Labs)
 RDP Client: FreeRDP via OSX HomeBrew
 X11: XQuartz will be required for both OSX Hosts and OSX Clients.  Of course X11 is already part of any Linux Desktop Environment.
 Host firewall's ssh port 22 open for NIC "ham0"


Assumptions/Prerequisites:
 Let's assume you've installed XQuarts on the OSX host already.
 Let's assume you have Hamachi fully operational on both machines. (i.e. hamachi logged in, VPN created, joined on both machines, firewall open for ham0) -- ("hamachi list" to see your IP's, "hamachi -h" for other options).
 Let's assume you've installed Homebrew on the host already. (or you can do it while ssh'd in).

We will do this remotely through the hamachi VPN.

From your linux client, ssh into your OSX host: (If on an OSX client, XQuartz's xterm is necessary)
 ssh -XC user@hostIP #(-X is for X11 forwarding, -C is for compression)

Edit the ssh server config:
 sudo nano /etc/sshd_config
Adding the following 3 lines to the end of the config file:
 AddressFamily inet #(required when IPv6 is disabled on any client or host)
 X11Forwarding yes
 X11DisplayOffset 10

Restart the sshd service:
 ps -ef | grep sshd | awk {'print $2'} | sudo xargs kill -HUP
 
This will have disconnected you, so ssh in again:
 ssh -XC user@hostIP

Let's install FreeRDP:
 brew install freerdp

Setup the display for the X11Forward:
 export DISPLAY=localhost:10.0

Now run xfreerdp:
 xfreerdp serverIP #(where serverIP is a legitimate internal network IP)
 #OR
 xfreerdp -u username -d domain serverIP  #(where -d domain is only needed for Active Directory members)

Proof:

Caveat:
  I've found a significant issue strictly when on Linux client-side --  When i type into the RDP session I get completely different characters making the session unusable.

Here I type "Administrator":

I'm sure it's a keyboard or character set issue.  I'm looking into the xfreerdp -k option, but have not solved it yet.  If you solve my problem, PLEASE post it in a comment.  Thank you, and good luck!
------------
Please consider crypto tipping: