Friday, January 22, 2016

How to setup a intermediate compatible SSL website with LetsEncrypt certificate

https://www.howtoforge.com/tutorial/how-to-setup-intermediate-compatible-ssl-website-with-letsencrypt-certificate

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit.
The key principles behind Let’s Encrypt are:
  • Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
  • Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
  • Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
  • Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
  • Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
  • Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.
(source: https://letsencrypt.org/about/)

Intro:

First, we have to mention about some dark sides of Let's Encrypt service. However great the idea of free public and open certificate authority is, it brings also many troubles for us. Developers have tried to make the system of obtaining certificates as simple as possible, but it still requires a higher skill of server administering. Therefore, many of developers like the one from ISPConfig (http://www.ispconfig.org/) have implemented this solution directly into their. This brings people more effective deployment and supervision over the whole system much easier and flexible.

Real complication:

Many people have decided to implement Let's Encrypt into their production sites. I find this still a very bad idea to be done without being very (but really very) careful. Let's Encrypt brings you freedom but also limits you in using the certificate with SHA-256 RSA Encryption. Support for SHA-2 has improved over the last few years. Most browsers, platforms, mail clients and mobile devices already support SHA-2. However, some older operating systems such as Windows XP pre-SP3 do not support SHA-2 encryption. Many organizations will be able to convert to SHA-2 without running into user experience issues, and many may want to encourage users running older, less secure systems to upgrade.
In this tutorial, we are going to deal with this incompatibility in a simple, but still nasty way.

Prerequisites:

  • Apache version 2.4 and higher
  • OpenSSL version 1.0.1e and higher
  • Apache mod_rewrite enabled

The whole idea:

As mentioned before, there are still devices incompatible with SHA-256 signature in the Internet. When I was forced to deploy an SSL to some websites, I had to decide from two options:
  1. Using Let's Encrypt having it for free but not for all
  2. Buying a certificate with 128 bit signature
Well, still the option no. 1 was the only way as it was promised to customer long days ago (:

No more theory:

I hope I have explained the needed and now we can deal with the unsupported viewers of our website. There are many people using Windows XP machines with SP2 and lower (Yes, there are still plenty of them). So we have to filter these people.
In your “/etc/apache2/sites-available/your_domain.com.conf” add following on the end of the file:
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !(NT\ 5) [NC]
RewriteRule ^(.*) https:// your_domain.com [R]
RewriteCond gets a string from http header of the guest accessing your page. You can simply check yours and find more information here: http://www.useragentstring.com/
The condition we used tells us something like “if string doesn't contain 'NT 5'” then RewriteRule executes/applies the rule of redirecting [R] to https variant of your domain, NT 5 is a OS version string for Windows XP devices.
If you don't use this redirection, incompatible users won't be able to access your https website.
I have to warn you this solution is not 100% perfect as some of guest doesn't have to provide you relevant or real information. I have worked with AWstats to figure out what rate of unknown systems are accessing my page and it is about 1.3%, so pretty few requests. If you want to deal with unknown operating systems to ensure their compatibility, you can add unknown in the condition as well (RewriteCond %{HTTP_USER_AGENT} !(NT\ 5|unknown) [NC]).
AWstats:
Awstats graphic.
After successfully “non-redirecting” your incompatible visitors (keeping them in http insecure world) you can focus on https side.

HTTPS configuration:

Now we assume you already assigned the certificate to your web server and also enabled it.
In your vhost config file again, add following:
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:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-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:!KRB5-DES-CBC3-SHA 
SSLProtocol All -SSLv2 -SSLv3 
SSLCompression off 
SSLHonorCipherOrder On 
The CipherSuite used here is a bit longer than usual. It's for better compatibility. You can get your own from: https://cipherli.st/ or https://mozilla.github.io/server-side-tls/ssl-config-generator/
I must again mention, you wont ever get a perfect configuration to meet the high security policy and also compatibility. You should find a compromise.
After using these settings, you can test your server configuration and compatibility at: https://www.ssllabs.com/ssltest/index.html
You are going to find a long list of compatible devices and the incompatible ones, also some more information to point you for your own “perfect” solution.

What Is Fork Bomb And How Can You Prevent This Danger?

http://www.unixmen.com/fork-bomb-can-prevent-danger

If you are not thrilled with the real bomb, you can try typing this  :(){ :|:& };:  on your Linux terminal to crash your computer. you do not need to be the root user to do that. That string is known as the Fork bomb. Before you get to know how that works, it would be better to know what a fork bomb does exactly.

WHAT IS A FORK BOMB?
Fork_bomb
The name sounds Fork bomb does not throw dining forks at you, when you executing the strings in terminal. In terms of nixology (Linux & Unix) the word fork means, to create a new process.Similarly, when you create a new process using ‘fork’ (actually a function that can be called on Linux/Unix-like machines), the new process is created from the image of the original one and is basically a inherited copy of the parent process.
A fork bomb will calls the fork function indefinitely and rapidly in no time, thus exhausting all system resources. It comes in the category of Denial of Service attack due to its nature of quickly ripping up system resources and making it unusable within a very short span of time.
All these special characters stands with their unique functionality in *nix operating system. Fork bomb actually associated with the concept of recursion in bash script by using functions in it.
Syntax of function in bash,

function_name()

{
Commands
}
HOW FORK BOMB WORKS?
In this case ‘:’ colon is the function name then followed by ‘()’ parentheses and curly brace ‘{‘ to open a function, then the definition of ‘:|:&’ tells the bash  to launch the ‘:’ function and ‘|’ pipe its output to the same function ‘:’ and send the process to the background defined by ‘&’, so that it can’t be killed by hitting “Ctrl + C”. Then the close curly brace ‘}’ followed by ‘:;’ which points the function again to keep the process recursive.
To launch the bomb, all you need to do is just to copy or type   :(){ :|:& };:   this code in Terminal and hit Enter. Your session will get slow down to hell in matter of seconds and you will be left with no option but to go with warm reset. The actual time in which your system will succumb to paralysis depends on the speed of your processor, number of processing cores available and the amount of RAM installed. Even though the size of swap partition is also a factor, if it starts getting used by the bomb, the system would typically take long enough to respond for you.
Before we proceed further let me make sure that Fork bomb is not a property of Linux, the technique of creating new processes does work on Windows as well and also the same problem can be raised in other system programming languages such as C or C++, for your instance  compile the following code and execute it, you will come to know that.

FORK BOMB IN C
#include
int main(void) {
    for(;;)
    fork();
    return 0;
}


HOW TO PROTECT FROM FORK BOMB? Fork bombs hang the system by creating a ‘N’ number of processes. The worst part is that one does not even need to be the super user to launch a fork bomb. To shield your system from Fork bomb ensure that you are limiting the number of processes to the local users where they could create, you can limit around 1000 to 4000 process for the local users to create. Generally a user could work about 200-300 process at same time. However for people who do a lot of multitasking, 1000 might be little less.
Understanding /etc/security/limits.conf file!
Each line describes a limit for a user in the form:

Where:

  • can be:
    • an user name
    • a group name, with @group syntax
    • the wildcard *, for default entry
    • the wildcard %, can be also used with %group syntax, for maxlogin limit
  • can have the two values:
    • “soft” for enforcing the soft limits
    • “hard” for enforcing hard limits
  • can be one of the following:
    • core – limits the core file size (KB)
  • can be one of the following:
    • core – limits the core file size (KB)
    • data – max data size (KB)
    • fsize – maximum filesize (KB)
    • memlock – max locked-in-memory address space (KB)
    • nofile – max number of open files
    • rss – max resident set size (KB)
    • stack – max stack size (KB)
    • cpu – max CPU time (MIN)
    • nproc – max number of processes
    • as – address space limit
    • maxlogins – max number of logins for this user
    • maxsyslogins – max number of logins on the system
    • priority – the priority to run user process with
    • locks – max number of file locks the user can hold
    • sigpending – max number of pending signals
    • msgqueue – max memory used by POSIX message queues (bytes)
    • nice – max nice priority allowed to raise to
    • rtprio – max realtime priority
    • chroot – change root to directory (Debian-specific)
To limit the number of processes according to the users, you can open the file /etc/security/limits.conf and add the following line at the bottom:

mohammad hard nproc 4000

This will keep the the specified user account to restrict more than 4000 processes. Save the file and reboot the system and try with launching the Fork bomb. System should prevent the crash and withstand the attack now!
If a Fork bomb has already been launched and the restrictions for number of processes are active, you can login as root and kill all the bash processes to terminate the fork bomb. In case if a Fork bomb script is activated by a local user and you haven’t restrict the number of processes to that particular user, but still your CPU left with little time to clear the Fork bomb.
You should not use the following command to kill the script.

$killall -9 Script_Name

This will not work due the nature of a fork bomb. The reason is the killall does not hold a lock on the process table so each one that is killed a new one takes its place in the process table. Also you will not be able to run a killall due to the shell forking off another shell to run the killall.
Instead you can run these command to stop Fork bomb,

$ exec killall -9 ScritName

$ exec killall STOP ScriptName
NOTE :
This Restrictions will have no effect on the root user or any process with the CAP_SYS_ADMIN or CAP_SYS_RESOURCE capabilities are not affected by this kind of limitation on a Linux based system.
Hope you enjoyed the article , make me happy with your comments if you have any questions :-)

How to reset the password in an LXC container

http://ask.xmodulo.com/reset-password-lxc-container.html

Question: I created an LXC container, but I cannot log in to the container as I forgot the default user's password and the root password. How can I reset the password on an LXC container?
When you create an LXC container, it will have the default username/password set up. The default username/password will vary depending on which LXC template was used to create the container. For example, Debian LXC will have the default username/password set to root/root. Fedora LXC will have the root password set as expired, so it can be set on the first login. Ubuntu LXC will have ubuntu/ubuntu as the default username/password. For any pre-built container images downloaded from third-party repositories, their default username/password will also be image-specific.
If you do not know the default username/password of your LXC container, there is an easy way to find the default username and reset its password.
First of all, make sure to stop the LXC container before proceeding.
$ sudo lxc-stop -n

Find the Default User of an LXC Container

To find the default username created in an LXC container, open the /etc/passwd of the container, which can be found at /var/lib/lxc//rootfs/etc/passwd of the LXC host. In the passwd file of the container, look for "login-enabled" users, which have "/bin/bash" (or something similar) listed as their login shell. Any of such usernames can be the default username of the container. For example, in the screenshot below, the usernames "ubuntu" or "sdn" are login-enabled.

Any username which has "/usr/sbin/nologin" or "/bin/false" as its login shell is login-disabled.

Reset the User Password in an LXC Container

To reset the password of any login-enabled username, you can modify /etc/shadow file of the container, which can be fount at /var/lib/lxc//rootfs/etc/shadow of the LXC host. In Linux, the /etc/shadow file stores one-way encrypted passwords (password hashes) of user accounts. Each line in /etc/shadow is formatted as strings concatenated with ":" delimeter. The first two strings represent a username and its encrypted password.
::16728:0:99999:7:::

If the password field is set to '!' or '*', it means the user account is locked for access or completely disabled for login.
To reset the password of any login-enabled username, all you have to do is to remove the password hash of the username and leave the ":" delimeter only. For example, for username "sdn", change:
sdn:$6$OJWSjfOg$KCCCySxj97qUtv0eFVXQgNf.j1YPCp1ahnmLMu5n/VzcshQgPfiasWq4mNzjbPcOrabmTgrRNB29e7P7vGFh1:16631:0:99999:7:::
to:
sdn::16631:0:99999:7:::
Similarly, to reset the root password, simply delete the password hash of the root.
root::16631:0:99999:7:::
With the password field set to empty, you will be able to login to the user account without any password from the console. Now start the container, and verify password-less console login.
Don't forget to set a new password using passwd after successful login.