I have a Mac running OS X Server 5.2 and due to company policy I need to force the server to use TLS 1.2 only and turn off TLS 1 and TLS 1.2.
I have edit the conf files in the /Library/Server/Web/Config/apache2/sites to SSLProtocol -all +TLSv1.2 but it still allows connection with tls1 and tls1.2
Does anybody know how to enforce TLS 1.2 connections only?
Thanks!
If that is an option, update your Server app. Starting with Server version 5.3, support for TLS 1 and TLS 1.1 has been disabled by default, so this solution would be simple and effective.
If you cannot update for some reason, you will have to remove these protocols in /Library/Server/Web/config/proxy/apache_serviceproxy.conf, and possibly in /library/server/web/config/apache2/httpd.conf. Also note that I have found that you have to restart macOS in order to restart the proxy server (it is not sufficient to issue sudo serveradmin stop/start web). This seems to be unnecessary - see my update below!
Update
It looks like there is a bug in Apache that can prevent the above setting from working as expected. It seems that, if there ciphers active that are not allowed any more in TLS 1.2, the older TLS versions remain available despite the setting in SSLProtocol. These older cipher suites need to be deactivated as well.
Therefore, use this recommended configuration:
SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL
SSLHonorCipherOrder on
Besides that, it looks like it's enough to update /Library/Server/Web/config/proxy/apache_serviceproxy.conf, as SSL/TLS is handled by the proxy process only. To restart the proxy use
$ sudo launchctl unload -w /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.serviceproxy.plist
$ sudo launchctl load -w /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.serviceproxy.plist
A server restart is not required.
There might be multiple occurrences in the configuration. I replaced them all, which may or may not be necessary.
Related
Since a day or so I can not access the databases on two of my servers any longer
I use
mysql -h host.sld.TLD -P 3306 -user user
which I have configured to allow my user from my host without password
but get the above error.
However, when I use
telnet host.sld.TLD 3306
I get
5.5.5-10.8.5-MariaDB-1:10.8.5+maria~ubu2004(si4cyW'Y��-n;{ypDA\)VU)mysql_native_passwordC
I am using homebrew's mariadb (currently 10.9.3) on my machine, which I can reach from the outside. One each of the 'failed' remotes is on ubuntu with 10.8 and one on a Mac also with 10.8, and outgoing works from both. OpenSSL is version 1.1.1s on both Macs
I have installed a number of different mariadb versions all have the same issues, as do their perl libraries. mysql itself works.
What am I doing wrong here?
This issue has been fixed in MariaDB 10.9.4 which was released yesterday. Brew still offers 10.9.3, usually it takes a couple of days until latest 10.9 release will be available via brew.
The issue doesn't affect the server itself, but Connector/C and command line tools which link against Connector/C.
See also: MariaDB connector in Python cannot connect to remote server
I am running CentOS 7.9 (server edition)
I have been searching online for some help on how to disable weak ssh cypher. However, I do not seem to be able to fix the issue. Qualys scans keeps reporting weak cipher in ssh service. I followed some recommendations (i.e: https://www.thegeekdiary.com/how-to-disable-weak-cipher-and-insecure-hmac-algorithms-in-ssh-services-for-centos-rhel-6-and-7/) online without any luck.
Here is what my /etc/ssh/sshd_config looks like
# Addresses Qualys QID 38739 Deprecated SSH Cryptographic Settings (CentOS 6)
## Changed this line:
##ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc#lysator.liu.se
## to this line:
ciphers aes128-ctr,aes192-ctr,aes256-ctr
Thank you for your help.
Step 1:
Go to below directory and uncomment the below line
Vi /etc/sysconfig/sshd
Uncomment
CRYPTO_POLICY=
Step 2:
Go to the below directories and append the below lines at the end of file
vi /etc/ssh/sshd_config
KexAlgorithms curve25519-sha256#libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305#openssh.com,aes256-gcm#openssh.com,aes128-gcm#openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm#openssh.com,hmac-sha2-256-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128#openssh.com
Step 3:
systemctl restart sshd
I'm using vagrant (VVV actually) to run local wordpress installs. I want to test different behaviors for different GEO's on my local machine instead of upload it every time to the server which is annoying.
So, I've tried to install the GeoIP nginx module to the local machine with the following guide https://piwik.org/faq/how-to/faq_166/ (and a bit more google but it doesn't matter at the moment).
When I'm using ./configure the following is exists:
checking for GeoIP library ... found
checking for GeoIP IPv6 support ... found
I've also set the .dat files in my conf file, and set the $_SERVER (fastcgi_param) parameters - so they displayed when I'm printing the $_SERVER var.
But those GeoIP vars are empty. I'm not sure about the reason, but 2 things is bothering me. First, when I'm write nginx -V in the terminal the argument --with-http_geoip_module is missing. Second, could it actually works if the REMOTE_ADDR (IP) is not my real IP? (192.168.1.50 for example).
nginx is a bit strange for me, so sorry if something isn't exact..
--
Operating system - macOS, nginx version - 1.3.15, running with VVV (vagrant box)
If there is a reverse proxy in front of your nginx, use geoip_proxy to set IPs whose X-Forwarded-For-Header can be trusted.
You can also use that without actually having a reverse proxy when you're developing. Add your local IP to the geoip_proxy-list and set the X-Forwarded-For-Header to your public IP in your browser (use a plugin like Modify Headers).
NFS Mount is not working in my RHEL 7 AWS instance.
When I do a
mount -o nfsvers=3 10.10.11.10:/ndvp2 /root/mountme2/
I get the error:
mount.nfs: requested NFS version or transport protocol is not supported
Can anyone point me where I am wrong?
Thanks.
Check the nfs service is started or reboot the nfs service.
sudo systemctl status nfs-kernel-server
In my case this package was not running and the issue was in /etc/exports file where i was having same IP address for two machines.
So i commented one ip address for the machine and restarted nf-kernel-server using
sudo systemctl restart nfs-kernel-server and reload the machine.
It worked.
A precision which might be useful for the dump (like me): systemctl status nfs-server.service and systemctl start nfs-server.service must be executed on the server!
Some additional data
If, like me, you've deleted a VM without shutting it down right you might also need to manually edit the file /etc/exports because NFS is trying to connect to it and fails but doesn't continue with the next, it just dies.
After that you can manually restart as mentioned in other answers.
In my case, a simple reload didn't suffice. I had to perform a full restart:
sudo systemctl status nfs-kernel-server
In my case, it didn't work correctly with version NFS 4.1.
So in Vargantfile in each place where is type: 'nfs' I added coma and nfs_version: 4, nfs_udp: false
Here is more detailing explanation NFS
If you're giving a specific protocol to connect with, also check to make sure your NFS server has that protocol enabled.
I got this error when trying to start up a Vagrant box, and my nfs server was running. It turns out that the command Vagrant uses is:
mount -o vers=3,udp,rw,actimeo=1 192.168.56.1:/dir/on/host /vagrant
Which specifically asks for UDP. My server was running but it was not configured to enable connecting over UDP. After consulting /etc/nfs.conf, I created /etc/nfs.conf.d/10-enable-udp.conf with the following contents to enable udp:
[nfsd]
udp=y
The name of the file doesn't matter, as long as it's in the conf.d directory and ends in .conf. Depending on your distribution it may be configured differently. You can directly edit nfs.conf, but using a conf.d file is more likely to preserve the changes after upgrading your system.
Try to ping IP address of the server "ping " from client "ping , if you get reply then install nfs server on the host. Then edit /etc/exports file don't forget to add port along with IP address
I got the solution: make an entry in nfs server /etc/nfsmount.conf with Defaultvers=3 .
There will # Defaultvers=3 just unhash it and then mount on nfs client.
Issue will be resolved!
I'm trying to fetch the following URL via various libraries and command-line tools, but running into a SSL handshake error.
> curl https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I've seen here it may be fixed by reducing possible ciphers, but trying this less strict call with restricted ciphers doesn't fix it.
curl -vlkL "https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts" --ciphers DHE-RSA-AES256-SHA
Any ideas how I can fix this? It's a shared account, ie no root available.
The server supports only TLS version 1.2, i.e. no TLS 1.0 or even SSL 3.0. My guess is that the curl you use is simply too old to use TLS 1.2, but without further details about the version you use this guess can not be verified.
To determine the version of curl use curl --version. If you see it is compiled with OpenSSL than it should show at least version 1.0.1 of OpenSSL to have TLS 1.2 support.
curl -vlkL ... --ciphers DHE-RSA-AES256-SHA
This is not a cipher supported by the server. One of the ciphers supported is AES128-SHA but again, no chance if your curl does not support TLS 1.2.