Walkman? Who remembers it anymore?
via placidiappunti
Following the Debian Security Advisory DSA-2896-1 openssl — security update, a good practice would be to check wether your server is affected by the OpenSSL Heartbleed security bug or not.
If you find your server affected by the bug, here are some few steps to fix the problem on Debian Wheezy (but with slight changes you can use with other distros too).
As root:
aptitude update aptitude upgrade libssl1.0.0 aptitude upgrade openssl
As you reboot you Apache or SSH servers, you will notice that the bug is fixed, but the problem is still here, you private keys may be compromised, so it’s time to generate new secrets.
Apache
Let’s generate a new private key. First, let’s move to the ssl private keys directory:
cd /etc/ssl/private
Let’s issue:
openssl genrsa -des3 -out server.key 1024 openssl req -new -key server.key -out server.csr
So now we have a new private key and a csr (certificate signing request).
Time to strip the password from the private key:
cp server.key server.key.org openssl rsa -in server.key.org -out server.key
And now, we self sign the certificate:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Have a look at your new certificate:
openssl x509 -in server.crt -text | less
Now let’s make everything readable just by root user, remember that we stripped the password from private key:
chmod o-r server*
Finally let’s copy the new public certificate to the right directory:
cp server.crt ../certs/
Do not forget to modify, if needed, the entry for certificate files in Apache conf :
SSLCertificateFile /etc/ssl/certs/server.crt SSLCertificateKeyFile /etc/ssl/private/server.key
Now, restart Apache:
service apache2 restart
SSHD
For OpenSSH it’s way easier. First, we remove the old host keys:
rm /etc/ssh/ssh_host_*
Now we reconfigure openssh-server package to generate new keys:
dpkg-reconfigure openssh-server
Finally, if dpkg-reconfigure did not, we restart SSH
service ssh restart
Some thoughs on mod_gearman benefits.
In this chart I “collapsed” the gearmand daemon under the “Monitor” box.
This is just a skeleton. It works but no checks on input. It’s meant to be run by a cronjob, so, really, input check?
——————————————————–
#!/bin/bash
# Mod-Gearman Passive Check Wrapper
# (few lines) coded by Giorgio Zarrelli
COMMAND=`$1`
RETURN_CODE=”$?”
SEND_BIN=’/path/to/send_gearman’
SERVER=’gearmand_server_ip:4730′
HOST=”my_passive_host_as_in_nagios”
ENCRYTION=”yes”
KEY=’my_secret_key’
SERVICE=”$2″
$SEND_BIN –server=”$SERVER” –encryption=”$ENCRYPTION” –key=”$KEY” –host=”$HOST” –service=”$SERVICE” –message=”$COMMAND” –returncode=”$RETURN_CODE”
So:
./send_gearman.sh “/path/to/nagios/plugins/libexec/check_users -w 1 -c 5” check-users
Note to myself:
# This configuration file allows the manual to be accessed at
# http://localhost/manual/
#
#Loglevel debug
KeepAlive On
Alias /glpi “/var/www/glpi”
<Directory “/var/www/glpi”>
PerlAuthenHandler Apache2::AuthenNTLM
AuthType ntlm,basic
AuthName Access
require valid-user
PerlAddVar ntdomain “DOMAIN PDO BDO”
PerlSetVar defaultdomain DOMAIN
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmdebug 0
PerlSetVar ntlmauthoritative off
# Uncomment following to force use of HTTPS in Administration Server
#SSLRequireSSL
# PHP tuning (not working on all distribution, use php.ini instead)
AddType application/x-httpd-php .php
php_flag file_uploads on
# Some PHP tuning for deployement feature up to 8 MB
# post_max_size must be greater than upload_max_filesize
# because of HTTP headers
php_value post_max_size 9m
php_value upload_max_filesize 8m
# You may have to uncomment following on errors
#php_value max_execution_time -1
#php_value max_input_time -1
# Uncomment following to allow HTTP body request up to 4 MB
# instead default 512 KB
#LimitRequestBody 4194304
</Directory>
Install Apache2::AuthenNTLM Perl module. In Debian just type:
aptitude install libapache2-authenntlm-perl
Remember to enable ntlm authentication on Windows machines. Not all versions (xp does), have it enabled.