PlasmaTree PID-Analyzer must be an integer, when a scalar

Problem:
line 1054, in histogramdd raise TypeError( TypeError: bins[1] must be an integer, when a scalar

Solution:
Use Smeat's fork for updated numpy prerequisite: https://github.com/Smeat/PID-Analyzer
Please consider crypto tipping:
  

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:
  

Dell iDrac virtual console network connection dropped

Problem:
Dell iDrac Virtual Console viewer failing :

The viewer has terminated. Reason: The network connection has been dropped.

Cause:
Java releases after 8.?? have stricter security settings, disabling 3DES_EDE_CBC.

Solution:
We may unblock 3DES_EDE_CBC to allow iDrac Virtual Console viewer.jnlp to work again.

Linux example:
Use sudo powers to modify your /etc/java-11-openjdk/security/java.security or similar file near line 656. (Locating your java version obviously.) Replace [modify or duplicate with commenting-out]:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

with

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, anon, NULL

In Windows, the file will be C:\Program Files\Java\jre1.8.0_271\lib\security\java.security or similar. (Locating your java version obviously.)

Other resources will tell you to comment the entire jdk.tls.disabledAlgorithms line(s), but this will unblock multiple weak securities. At least unblocking the single 3DES_EDE_CBC is less impactful, albeit still less secure than defaults.

Please consider crypto tipping: