Friday, December 18, 2015

HOWTO Flush the Mail Queue on Postfix

Flush the Mailq:

To flush mail queue under Postfix, just enter the following command to flush the mail queue:
$ postfix flush

OR
$ postfix -f

To see mail queue, enter:
$ mailq

To remove all mail from the queue, enter:
$ postsuper -d ALL

To remove all mails in the deferred queue, enter:
$ postsuper -d ALL deferred

Delete E-Mails with one Perl Script
The following script deletes all E-mails from the mailq which matches the regular expression specified as the first argument:

#!/usr/bin/perl

$REGEXP = shift || die "no email-adress given (regexp-style, e.g. bl.*\@yahoo.com)!";

@data = qx</usr/sbin/postqueue -p>;
for (@data) {
  if (/^(\w+)(\*|\!)?\s/) {
     $queue_id = $1;
  }
  if($queue_id) {
    if (/$REGEXP/i) {
      $Q{$queue_id} = 1;
      $queue_id = "";
    }
  }
}

#open(POSTSUPER,"|cat") || die "couldn't open postsuper" ;
open(POSTSUPER,"|postsuper -d -") || die "couldn't open postsuper" ;

foreach (keys %Q) {
  print POSTSUPER "$_\n";
};
close(POSTSUPER);


For example, delete all queued messages from or to the domain called banana.com, enter:
./postfix-delete.pl banana.com

Delete all queued messages that contain the word "xyz" in the e-mail address:
./postfix-delete.pl xyz


Delete E-Mails with one one-liner:
Another way to check and delete E-Mail from the mailq is a simple "one-liner":

Check the E-Mails:
for i in `mailq | egrep "^[0-9A-F]" | grep 'ximunix@blogspot.com' | cut -c1-12 | sed s/\*//g` ; do echo $i; done

Delete the E-Mails:
for i in `mailq | egrep "^[0-9A-F]" | grep 'ximunix@blogspot.com' | cut -c1-12 | sed s/\*//g` ; do postsuper -d $i; done

Monday, October 12, 2015

HOWTO Fix Webcam (dark) Problem In Skype

If you have a webcam that does not work correctly in Skype (for example, the image it's dark) but it works fine other apps like Cheese, you might want to check this out:

1. Install libv4l-0
ximena@ximunix:~$ sudo apt-get install libv4l-0

2. Now we need to edit the file "skype.desktop" so we can pre-load libv4l-0 with Skype.

ximena@ximunix:~$ sudo vi /usr/share/applications/skype.desktop

And replace the line following line:
Exec=skype 
with this new line:
Exec=bash -c 'LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so skype'

This is an example of the file /usr/share/applications/skype.desktop:
[Desktop Entry]
Name=Skype
Comment=Skype Internet Telephony
#Exec=skype %U
Exec=bash -c 'LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so skype'
Icon=skype.png
Terminal=false
Type=Application
Encoding=UTF-8
Categories=Network;Application;
MimeType=x-scheme-handler/skype;
X-KDE-Protocols=skype

Note: please check that in our case, libv4l is located under /usr/lib/x86_64-linux-gnu, but it can be located in another folder, depending on the OS.
To search for the location of the library, just search it quickly by typing:

ximena@ximunix:~$ locate v4l1compat.so
/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so
ximena@ximunix:~$ 

Now the camera should work fine and the image should be clear.

Hope it helps! :)

Wednesday, June 3, 2015

HOWTO Install Web fonts in Debian

1. First of all we will need to download the Fonts that you want to install on the Server.
For example:
ximena@xdev:~$ wget -O metalmania.woff http://themes.googleusercontent.com/static/fonts/metalmania/v2/_MPduYXiaptg6GQ2M6AHtIbN6UDyHWBl620a-IRfuBk.woff

Now, we will need to download the converter and convert the Fonts from .woff to .ttf (TrueType):

2. Download the converter:
ximena@xdev:~$ wget https://raw.github.com/hanikesn/woff2otf/master/woff2otf.py
ximena@xdev:~$ chmod u+x woff2otf.py

3. Convert the files:
ximena@xdev:~$ ./woff2otf.py metalmania.woff metalmania.ttf

Hint (1): you need to have python3 installed on your Server.

Now we will install the Font and Rebuild the Font Cache:

4. Install the fonts
ximena@xdev:~$ mv metalmania.ttf /usr/local/share/fonts/truetype/ttf-metalmania/

Hint (2): Remember to verify Font's permissions on disk (777); if you save your fonts in /usr/local/share/fonts:
ximena@xdev:~$ chmod -R 777 /usr/local/share/fonts

Hint (3): The Fonts Paths can be customized in the fontconfig configuration file: /etc/fonts/fonts.conf. You can also include subdirectories or links, which is useful if you have a directory of fonts on a separate hard drive (or partition or other location).

5. Rebuild the Fonts cache:
ximena@xdev:~$ fc-cache -fv
/usr/local/share/fonts: caching, new cache contents: 0 fonts, 1 dirs
/usr/local/share/fonts/truetype: caching, new cache contents: 0 fonts, 2 dirs
/usr/local/share/fonts/truetype/ttf-metalmania: caching, new cache contents: 1 fonts, 0 dirs
/usr/local/share/fonts/truetype/ttf-dejavu: caching, new cache contents: 6 fonts, 0 dirs
fc-cache: succeeded
ximena@xdev:~$

6. List the installed Fonts:
ximena@xdev:~$ fc-list

Hint (4): You may find the following useful to change default font rendering:
ximena@xdev:~$ dpkg-reconfigure fontconfig-config
ximena@xdev:~$ dpkg-reconfigure fontconfig

Tuesday, May 26, 2015

HOWTO Protect your Debian Server against the Logjam Attack

As many of you may already know, the current real-world deployment of Diffie-Hellman is less secure than previously believed. This post explains how to deploy Diffie-Hellman on your servers.

Recommendations for correctly deploying Diffie-Hellman for TLS:

1. Disable Export Cipher Suites
Even though modern browsers no longer support export suites, the FREAK and Logjam attacks allow a man-in-the-middle attacker to trick browsers into using export-grade cryptography, after which the TLS connection can be decrypted. Export ciphers are a remnant of 1990s-era policy that prevented strong cryptographic protocols from being exported from United States. No modern clients rely on export suites and there is little downside in disabling them.

2. Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE)
Elliptic-Curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original, finite field, Diffie-Hellman. The discrete log algorithms we used to attack standard Diffie-Hellman groups do not gain as strong of an advantage from precomputation, and individual servers do not need to generate unique elliptic curves.

3. Generate a Strong, Unique Diffie Hellman Group
A few fixed groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should generate unique, 2048-bit or stronger Diffie-Hellman groups using "safe" primes for each website or server.

You can test your server by using the Qualsys SSL Server Test.

Procedure:


The first step to secure your server is to generate a unique DH Group with the openssl command. Under the /etc/ssl/private/ directory, we will create the dhparams.pem file and set secure permissions:

cd /etc/ssl/private
openssl dhparam -out dhparams.pem 2048
chmod 600 dhparams.pem


Now, I will show you how to configure diferent services on your Servers:

apache2

First we will add a Secure Cipher Suite based on the recommendations from weakdh.org. Open the file /etc/apache2/mods-available/ssl.conf with an editor and change or add these lines:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Note: The SSLCipherSuide is just one long line, so do not add line breaks!!!

Set the DH Group in apache:

This part is only available for apache2 v. 2.4.8 and openssl v. 1.0.2 or newer !!!

Let's test our versions:
ximena@ximunix:~$ apache2 -v
Server version: Apache/2.2.22 (Debian)
Server built:   Feb  1 2014 21:26:04
ximena@ximunix:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
ximena@ximunix:~$ 

So, that means that I can't set the DH Group on this server. If your apache version is > 2.4.8 and OpenSSL > 1.0.2, then edit the /etc/apache2/mods-available/ssl.conf file again and add the following line:

SSLOpenSSLConfCmd DHParameters "/etc/ssl/private/dhparams.pem"

And then restart apache:

service apache2 restart

nginx

Edit the nginx configuration file /etc/nginx/nginx.conf

Add or replace the following lines:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /etc/ssl/private/dhparams.pem;

And then restart nginx:

service nginx restart

postfix

Edit the postfix configuration file /etc/postfix/main.cf and add the following lines:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA

smtpd_tls_dh1024_param_file = /etc/ssl/private/dhparams.pem

And restart postfix:

service postfix restart

dovecot

Edit the dovecot configuration file /etc/dovecot/dovecot.conf and add the following line right after the ssl_protocols line:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Now, let's check our dovecot version:

ximena@ximunix:~$ dovecot --version
2.1.7
ximena@ximunix:~$

If your dovecot version is 2.2.6 or greater, then add this additional line:

ssl_prefer_server_ciphers = yes

When the version is 2.2.7 or greater, then add this third line:

ssl_dh_parameters_length = 2048

Finally restart dovecot:

service dovecot restart

I hope that helps and works! ;)

Friday, May 15, 2015

hpacucli Error: No controllers detected.

If in your new freshly installed Debian Jessie you find the following error while running hpacucli:

ximena@xdev:~$ hpacucli ctrl all show status

Error: No controllers detected.

Don't break your brain and install "hpssacli" from the same repo:

ximena@xdev:~$ hpssacli ctrl all show config

Smart Array P440ar in Slot 0 (Embedded)   (sn: XXXXXXXXXXX)

   array A (SAS, Unused Space: 0  MB)


      logicaldrive 1 (558.9 GB, RAID 1, OK)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 600 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 600 GB, OK)

ximena@xdev:~$

And that's it... 

Linux Cheatsheets

cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.


So... Here is hoy you can cheat the command line, enjoy it: https://github.com/chrisallenlane/cheat

Thursday, April 30, 2015

Systemd vs SysVinit Cheatsheet

A good one to have in hand! ;)


Thanks a lot to: http://linoxide.com


Root Login Disabled per Default in Debian Jessie

If you, like me, were waiting for a long time the release of Debian Jessie 8.0 and after a fresh install of the system you could not login to the Box with root; well... Don't Panic and grab your towel! ;)

Here are some news for you:

https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#openssh
OpenSSH server defaults to "PermitRootLogin without-password" 
In an attempt to harden the default setup, the openssh-server configuration will now default to "PermitRootLogin without-password". If you rely on password authentication for the root user, you may be affected by this change.
The openssh-server will attempt to detect such cases and increase the priority of its debconf prompt.   

Here is a trick:

During the installation, Debian asked you to add another user with privileges, right? In my case, I created the user "yoda".

So, what we are going to do now, is to login to the Server with this user:

ximena@xdev:~$ ssh test02.ximunix.org -l yoda -p 22
yoda@test02.ximunix.de's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Apr 30 11:14:11 2015 from xdev.ipandmore.de
yoda@test02:~$ 

Now we will "su" into the root account:

yoda@test02:~$ su root
Passwort: 
root@test02:/home/yoda# 

Edit the sshd_config file:

root@test02:~# vi /etc/ssh/sshd_config 

And change this line:
PermitRootLogin without-password
For this line:
PermitRootLogin yes

Now, restart ssh:
root@test02:~# /etc/init.d/ssh restart

And you are ready to go. 

Please, after you login to your Server with root, change or install whatever you need, and in the end, please change the sshd_config to "PermitRootLogin no" in order to avoid any major security risks. It's never good to have "PermitRootLogin" set to "yes".

Hope it helps. :)



Wednesday, April 29, 2015

HOWTO Fix Error "...no public key available..." on Debian Wheezy

If you are getting an error similar to this one:

W: There is no public key available for the following key IDs:
7638D0442B90D010

when running an apt-get update on your Debian Wheezy. For example:

ximena@xdev:~$ sudo apt-get update
Get:1 http://security.debian.org wheezy/updates Release.gpg [1,571 B]
Get:2 http://security.debian.org wheezy/updates Release [102 kB]
Hit http://ftp.de.debian.org wheezy Release.gpg
Get:3 http://ftp.de.debian.org wheezy-updates Release.gpg [1,571 B]
Hit http://ftp.de.debian.org wheezy Release
Get:4 http://security.debian.org wheezy/updates/main Sources [175 kB]
Get:5 http://ftp.de.debian.org wheezy-updates Release [124 kB]
Get:6 http://apt.puppetlabs.com wheezy Release.gpg [876 B]
Get:7 http://security.debian.org wheezy/updates/main amd64 Packages [305 kB]
Hit http://ftp.de.debian.org wheezy/main Sources
Hit http://ftp.de.debian.org wheezy/main amd64 Packages
Get:8 http://apt.puppetlabs.com wheezy Release [29.4 kB]
Hit http://ftp.de.debian.org wheezy/main Translation-en
Get:9 http://security.debian.org wheezy/updates/main Translation-en [172 kB]
Hit http://ftp.de.debian.org wheezy/main Translation-de
Hit http://ftp.de.debian.org wheezy/main Translation-de_DE
Get:10 http://ftp.de.debian.org wheezy-updates/main Sources [3,303 B]
Hit http://ftp.de.debian.org wheezy-updates/main amd64 Packages/DiffIndex
Hit http://ftp.de.debian.org wheezy-updates/main Translation-en/DiffIndex
Get:11 http://apt.puppetlabs.com wheezy/main Sources [83.0 kB]
Get:12 http://apt.puppetlabs.com wheezy/dependencies Sources [9,234 B]
Get:13 http://apt.puppetlabs.com wheezy/main amd64 Packages [97.9 kB]
Get:14 http://apt.puppetlabs.com wheezy/dependencies amd64 Packages [6,422 B]
Ign http://apt.puppetlabs.com wheezy/dependencies Translation-en_US
Ign http://apt.puppetlabs.com wheezy/dependencies Translation-en
Ign http://apt.puppetlabs.com wheezy/dependencies Translation-de
Ign http://apt.puppetlabs.com wheezy/dependencies Translation-de_DE
Ign http://apt.puppetlabs.com wheezy/main Translation-en_US
Ign http://apt.puppetlabs.com wheezy/main Translation-en
Ign http://apt.puppetlabs.com wheezy/main Translation-de
Ign http://apt.puppetlabs.com wheezy/main Translation-de_DE
Fetched 1,112 kB in 4s (222 kB/s)
Reading package lists... Done
W: There is no public key available for the following key IDs:
9D6D8F6BC857C906
W: There is no public key available for the following key IDs:
7638D0442B90D010
W: There is no public key available for the following key IDs:
7638D0442B90D010
ximena@xdev:~$

Here is what you should do:

ximena@xdev:~$ sudo apt-get install debian-keyring debian-archive-keyring
ximena@xdev:~$ sudo apt-get update

And that should do it :)

HOWTO Check the WordPress Version on the command Line

After the news from the WordPress Bug few days ago, I wanted to check which versions of WordPress we have on our WebServer on the Command Line, and I've found this cool thing:

ximena@xdev:/www$ grep wp_version mywebsite/htdocs/wp-includes/version.php

Hope it helps! :)

Thursday, April 9, 2015

HOWTO Remove all Packages marked as "rc" by dpkg

Let’s see all the packages marked as rc by dpkg. The state "rc" means that the configuration files are not yet removed.

ximena@xdev:~$ dpkg -l |grep "^rc"
rc  apache2.2-common                       2.2.22-13+deb7u4               amd64        Apache HTTP Server common files
rc  libapache2-mod-php5                    5.4.36-0+deb7u3                amd64        server-side, HTML-embedded scripting language (Apache 2 module)
rc  libapr1                                1.4.6-3+deb7u1                 amd64        Apache Portable Runtime Library
rc  libaprutil1                            1.4.1-3                        amd64        Apache Portable Runtime Utility Library
rc  libgd2-noxpm:amd64                     2.0.36~rc1~dfsg-6.1            amd64        GD Graphics Library version 2 (without XPM support)
rc  libmozjs24d                            24.8.1esr-2~deb7u1             amd64        Mozilla SpiderMonkey JavaScript library
rc  libonig2                               5.9.1-1                        amd64        Oniguruma regular expressions library
rc  libqdbm14                              1.8.78-2                       amd64        QDBM Database Libraries without GDBM wrapper[runtime]
rc  libsensors4:amd64                      1:3.3.2-2+deb7u1               amd64        library to read temperature/voltage/fan sensors
rc  libsnmp-base                           5.4.3~dfsg-2.8+deb7u1          all          SNMP (Simple Network Management Protocol) MIBs and documentation
rc  libsnmp15                              5.4.3~dfsg-2.8+deb7u1          amd64        SNMP (Simple Network Management Protocol) library
rc  libvpx1:amd64                          1.1.0-1                        amd64        VP8 video codec (shared library)
rc  php5-cli                               5.4.36-0+deb7u3                amd64        command-line interpreter for the php5 scripting language
rc  php5-common                            5.4.36-0+deb7u3                amd64        Common files for packages built from the php5 source
rc  ssl-cert                               1.0.32                         all          simple debconf wrapper for OpenSSL
ximena@xdev:~$ 

Let’s extract out only the packages name marked as rc:

ximena@xdev:~$ dpkg -l |grep "^rc" | cut -d " " -f 3
apache2.2-common
libapache2-mod-php5
libapr1
libaprutil1
libgd2-noxpm:amd64
libmozjs24d
libonig2
libqdbm14
libsensors4:amd64
libsnmp-base
libsnmp15
libvpx1:amd64
php5-cli
php5-common
ssl-cert
ximena@xdev:~$ 

Now let’s remove all the packages marked as rc.

ximena@xdev:~$ dpkg -l |grep "^rc" | cut -d " " -f 3 | xargs sudo dpkg --purge
[sudo] password for ximena: 
(Reading database ... 44984 files and directories currently installed.)
Removing apache2.2-common ...
Purging configuration files for apache2.2-common ...
Removing libapache2-mod-php5 ...
Purging configuration files for libapache2-mod-php5 ...
Removing libapr1 ...
Purging configuration files for libapr1 ...
Removing libaprutil1 ...
Purging configuration files for libaprutil1 ...
Removing libgd2-noxpm:amd64 ...
Purging configuration files for libgd2-noxpm:amd64 ...
Removing libmozjs24d ...
Purging configuration files for libmozjs24d ...
Removing libonig2 ...
Purging configuration files for libonig2 ...
Removing libqdbm14 ...
Purging configuration files for libqdbm14 ...
Removing libsensors4:amd64 ...
Purging configuration files for libsensors4:amd64 ...
Removing libsnmp-base ...
Purging configuration files for libsnmp-base ...
Removing libsnmp15 ...
Purging configuration files for libsnmp15 ...
Removing libvpx1:amd64 ...
Purging configuration files for libvpx1:amd64 ...
Removing php5-cli ...
Purging configuration files for php5-cli ...
Removing php5-common ...
Purging configuration files for php5-common ...
Removing ssl-cert ...
Purging configuration files for ssl-cert ...
ximena@xdev:~$ 


Tuesday, March 10, 2015

HOWTO Deny or Block an User on Linux

Deny user login by locking out account

"passwd -l" it is used to lock the specified account. Only root is allowed to block the users. The locking is performed by rendering the encrypted password into an invalid string and by prefixing the encrypted string with an !.

root@ximunix:~# passwd -l guest

You can also change shell to /sbin/nologin:
root@ximunix:~# usermod -s /sbin/nologin guest

Unlock account or allow login:

root@ximunix:~# passwd -u guest

You can also need change back shell from /sbin/nologin to /bin/bash:
root@ximunix:~# usermod -s /bin/bash guest

/sbin/nologin shell:

/sbin/nologin displays a message that an account is not available and exits non-zero. It is intended as a replacement shell field for accounts that have been disabled or login is blocked.

Thursday, February 19, 2015

HOWTO Fix error: dpkg-query: failed to open package info file `/var/lib/dpkg/status' for reading: No such file or directory

After an Electrical Outage in our Datacenter, one of our Servers got corrupted and I was getting the following error when running "dpkg -l":
dpkg-query: failed to open package info file `/var/lib/dpkg/status' for reading: No such file or directory

After my almost Panic attack, I searched a bit and found an easy solution:

If /var/lib/dpkg/status becomes broken for any reason, the Debian system loses package selection data and suffers severely. Look for the old /var/lib/dpkg/status file at /var/lib/dpkg/status-old or /var/backups/dpkg.status.*.

If the old /var/lib/dpkg/status file is not available, you can still recover information from directories in /usr/share/doc/.

    # ls /usr/share/doc | \
      grep -v [A-Z] | \
      grep -v '^texmf$' | \
      grep -v '^debian$' | \
      awk '{print $1 " install"}' | \
      dpkg --set-selections

    # dselect --expert # reinstall system, de-select as needed

So... no need to panic and always bring your towel :)

Wednesday, February 4, 2015

HOWTO drop or block Attackers IP Addresses with null routes on Linux

If someone is trying to attack your Linux System, you can drop the attacker IP using IPtables or you can use the route or ip command to null route unwanted traffic.
A "null route" (also called as blackhole route) is a network route or kernel routing table entry that goes nowhere. Matching packets are dropped (ignored) rather than forwarded, acting as a kind of very limited firewall. The act of using null routes is often called "Blackhole Filtering".

You can "nullroute": stop various attacks coming from a single IP (spammers or hackers) using the following methods on a Linux based system:

Nullroute IP using route command

Let's suppose that the following IP is a bad one: 178.137.163.126. Then you can type the following command:
root@xdev:~# route add 178.137.163.126 gw 127.0.0.1 lo

You can verify it with the following commands:
root@xdev:~# netstat -nr
OR
root@xdev:~# route -n

You can also reject a target:
root@xdev:~# route add -host 178.137.163.126 reject

To confirm the null routing status, you can use the ip command as follows:
root@xdev:~#  ip route get 178.137.163.126
RTNETLINK answers: Network is unreachable

To drop entire subnet 192.67.16.0/24, type:
root@xdev:~# route add -net 192.67.16.0/24 gw 127.0.0.1 lo


Null routing using ip command

While traversing the RPDB, any route lookup which matches a rule with the blackhole rule type will cause the packet to be dropped. No ICMP will be sent and no packet will be forwarded. The syntax is follows for the ip command:

root@xdev:~# ip route add blackhole 202.54.5.2/29
root@xdev:~# ip route add blackhole from 202.54.1.2
root@xdev:~# ip rule add blackhole to 10.18.16.1/29
root@xdev:~# ip route


How to remove null routing or remove blocked IP address:

Now let's say that the attacker wasn't an attacker, or that you want to cleanup the routing table on your system.
For that, you can use the route delete command as follows:
root@xdev:~# route delete 178.137.163.126
OR
root@xdev:~# route del -host 178.137.163.126 reject

Or use NA command to delete route:
root@xdev:~# ip route delete 1.2.3.4/26 dev eth0

Now let's kick some attackers of your Systems! ;)

Monday, February 2, 2015

UPDATED!!! HOWTO Patch a GNU/Debian Linux Distribution against the libc GHOST Vulnerability CVE-2015-0235

The thing is that when you have Shared Web Servers, Storage Clusters, or any other Productive Servers/Systems it is not easy to do a "dist-upgrade", therefore I came across a second Solution:

First Choice: Upgrade libc6 without Dist-Upgrade


1- Check libc Version:
root@xdev:~# dpkg -l | grep libc6
root@xdev:~# ldd --version

2- Like it is descripted below on our Second Solution, check if the System is vulnerable:
root@xdev:~# ./ghosttest 

3- Check which packages/applications depends upon libc:
root@xdev:~# lsof | grep libc | awk '{print $1}' | sort | uniq

4- Let's update only the libraries needed. In our example, will only be:
root@xdev:~# apt-get update
root@xdev:~# apt-get install libc-bin libc6:amd64

5- After the upgrade, let's check the versions:
root@xdev:~# dpkg -l | grep libc6
root@xdev:~# ldd --version

6- And let's check if the Server is still vulnerable (it should not):
root@xdev:~# ./ghosttest

Now, the funny part. :)

7- In Debian Wheezy, we have the swesome "debian-goodies" which, in our case, we will be using "/usr/sbin/checkrestart" that helps to find and restart processes which are using old versions of upgraded files (such as libraries).

In our example:

root@xdev:~# /usr/sbin/checkrestart
Found 27 processes using old versions of upgraded files
(14 distinct programs)
(13 distinct packages)

Of these, 11 seem to contain init scripts which can be used to restart them:
The following packages seem to have init scripts that could be used
to restart them:
nfs-common:
        1721    /usr/sbin/rpc.idmapd
        1685    /sbin/rpc.statd
nbd-server:
        2467    /bin/nbd-server
rpcbind:
        1654    /sbin/rpcbind
apache2.2-bin:
        16641   /usr/lib/apache2/mpm-prefork/apache2
        2098    /usr/lib/apache2/mpm-prefork/apache2
        16636   /usr/lib/apache2/mpm-prefork/apache2
        16637   /usr/lib/apache2/mpm-prefork/apache2
        16635   /usr/lib/apache2/mpm-prefork/apache2
        16634   /usr/lib/apache2/mpm-prefork/apache2
openssh-server:
        18013   /usr/sbin/sshd
        2505    /usr/sbin/sshd
acpid:  
        2061    /usr/sbin/acpid
udev:   
        410     /sbin/udevd
        411     /sbin/udevd
        298     /sbin/udevd
cron:   
        2171    /usr/sbin/cron
at:
        2124    /usr/sbin/atd
rsyslog:
        2031    /usr/sbin/rsyslogd
exim4-daemon-light:
        2444    /usr/sbin/exim4

These are the init scripts:
service nfs-common restart
service nbd-server restart
service rpcbind restart
service apache2 restart
service ssh restart
service acpid restart
service udev-mtab restart
service udev restart
service cron restart
service atd restart
service rsyslog restart
service exim4 restart

These processes do not seem to have an associated init script to restart them:
bash:   
        18015   /bin/bash
root@xdev:~#  

8- Now, you have to choices:
- Restart Carefully all the services!
- Reboot the Server

Happy Patching! :P

Second Choice: Upgrade libc6 performing Dist-Upgrade


First, let's check the version of glibc on your GNU/Debian Linux Distribution:

ximena@xdev:~$ ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u6) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

GHOST vulnerability check

You can test or reproduce the bug using the following C Script:

/* ghosttest.c:  GHOST vulnerability tester */
/* Credit: http://www.openwall.com/lists/oss-security/2015/01/27/9 */
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

Compile it and run it as follows:

ximena@xdev:~$ gcc ghosttest.c -o ghosttest
ximena@xdev:~$ ./ghosttest

Sample outputs from patched Debian Wheezy 7.8 Server:

not vulnerable

Sample outputs from unpatched Debian Wheezy 7.6 Server:

vulnerable

How do list packages/applications depends upon vulnerable Glibc?

Type the following lsof command:

ximena@xdev:~$ lsof | grep libc | awk '{print $1}' | sort | uniq

Sample outputs from my Debian Linux v7.x:

awk
bash
dbus-daem
dbus-laun
gconfd-2
gmain
grep
lsof
sort
ssh
uniq
/usr/bin/

Fix the GHOST vulnerability on a Debian Linux

Type the following apt-get command as the root user:

ximena@xdev:~$ sudo apt-get clean
ximena@xdev:~$ sudo apt-get update
ximena@xdev:~$ sudo apt-get dist-upgrade

Finally, reboot Debian Linux server by typing the following command:

ximena@xdev:~$ sudo reboot

How can I verify that my Linux system no longer vulnerable after the reboot?

Method #1: The easiest way to check vulnerability is to run the following command to verify that you are running an updated version of Glibc:

ximena@xdev:~$ ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u7) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Method #2: Run the Script given in the previous section called GHOST vulnerability check.

I Hope that helps! :)

Thursday, January 29, 2015

HOWTO Upgrade HP iLO Firmware under a Linux System

There are two Methods to Upgrade the iLO (HP Integrated Lights-Out) on the HP Proliant Servers:

1- From the Web Interface
2- From the Command Line (on a Linux Server)

1- Upgrade iLO from the Web Interface:

Once you are logged in the iLO, follow this steps (in this example iLO 3):

1. First we will take note of the current iLO Version:

Information -> Overview ->
iLO Firmware Version  1.55 Jan 24 2013

2. Then we will go for the Upgrade:

Administration -> iLO Firmware ->
Select the file (.bin) to upgrade and click on the button "Upload"
The image will be uploaded to the iLO and then it will begin the "Flashing" of the iLO itself.

Notes to have in mind and don't panic:
- iLO connection will be reset during the Firmware Upgrade, so don't panic.
- Once the flashing is done, reload your page and clear your browser cache if needed, and then login again to the iLO.
- The Upgrade of Vesions of iLO3 below 1.10 won't work when upgrading directly to 1.70 or 1.80. First you will need to upgrade to iLO3 Version 1.28, and then you can continue with the flashing of the newest iLO3 Version.

3. Now we will check again our Firmware Version:
Information -> Overview ->
iLO Firmware Version 1.80 Jul 11 2014

And... Happy Successfull Firware Upgrade! :P


2- Upgrade iLO from the Command Line:

There is also a good and niche way to upgrade the iLO of your server from the command line.

1. Let's check first the iLO FW Version:

root@xdev:~# hponcfg | grep Firmware
Firmware Revision = 1.26 Device type = iLO 3 Driver name = hpilo
root@xdev:~# 

2. Now you will need to download the script ".scexe" and then do the following:

root@xdev:~# chmod u+x CP018561.scexe
root@xdev:~# ./CP018561.scexe 

FLASH_iLO3 v1.09 for Linux (Jan 23 2013)
(C) Copyright 2002-2013 Hewlett-Packard Development Company, L.P.
Firmware image: ilo3_155.bin
Current iLO 3 firmware version  1.26; Serial number ILOUSE116ND7G      

Component XML file: CP018561.xml
CP018561.xml reports firmware version 1.55
This operation will update the firmware on the
iLO 3 in this server with version 1.55.
Continue (y/N)?y
Current firmware is 1.26 (Aug 26 2011 )
Firmware image is 0x801664(8394340) bytes
Committing to flash part...        
******** DO NOT INTERRUPT! ********
Flashing completed.                                   
Attempting to reset device.      
Succeeded.
***** iLO 3 reboot in progress (may take up to 60 seconds.)
***** Please ignore console messages, if any.
iLO 3 reboot completed.
root@xdev:~#

3. Now we will check again the Firmware Version after the Upgrade:
root@xdev:~# hponcfg | grep Firmware
Firmware Revision = 1.55 Device type = iLO 3 Driver name = hpilo
root@xdev:~# 

And that should be all! :)

Latest iLO Versions:

Name
Servers
Latest Firmware
Comments
iLOProLiant G2, G3, and G4 servers1.96, released 30 April 2014
iLO 2ProLiant G5 and G6 servers, model numbers 300 and higher2.25, released 14 April 2014Issued to fix a Heartbleed-related issue
iLO 3ProLiant G7 servers1.80, released 9 September 2014
iLO 4ProLiant Gen8 servers2.02, released 6 October 2014
Source: http://en.wikipedia.org/wiki/HP_Integrated_Lights-Out

Where to download the files?


iLO2:
ILO2-v222-CP021566.scexe
ILO2-v225.bin

iLO3:
iLO3-v180-CP022551.scexe
iLO3-v180.bin

iLO4:
ILO4-v200-CP017981.scexe

If you need any other file, leave a comment and I will upload it! :)