Install Redis in Linux

Prerequisite

$ sudo apt-get update -y
$ sudo apt-get install gcc make -y

Download, extract and compile Redis with:

$ wget http://download.redis.io/releases/redis-4.0.10.tar.gz (latest stable version)
$ tar xzf redis-4.0.10.tar.gz
$ cd redis-4.0.10
$ make

Run Redis:

$ src/redis-server

Run in background

$ src/redis-server &

or

redis-server –daemonize yes

Check if the process started or not:

ps aux | grep redis-server or pgrep redis-server

You can interact with Redis using the built-in client:
$ src/redis-cli

How to run multiple instances of laravel or any sites on the same domain

How to run multiple instances of laravel or any sites on the same domain

Domain requirement would be
Dev Domain: serv1.example.com/dev
Stg Domain: serv1.example.com/stg
Prod Domain: serv1.example.com/prod

<VirtualHost *:80>
ServerName serv1.example.com
DocumentRoot /var/www/html/devsite/public {Replace with the directory name where index.php is placed}

Alias /dev{name after domain name} /var/www/html/devsite/public
<Directory /var/www/html/devsite/public>
<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteBase /dev/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
</Directory>

Alias /stg /var/www/html/stagesite/public
<Directory /var/www/html/stagesite/public>
<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteBase /stg/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
</Directory>

Alias /prod /var/www/html/prodsite/public
<Directory /var/www/html/stagesite/public>
<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteBase /prod/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
</Directory>
ErrorLog logs/dev-error.log
CustomLog logs/dev-access.log common

</VirtualHost>

 

And my .htaccess file would fetch

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

Set Up Master Slave Replication in MySQL

MySQL replication is a process that allows you to easily maintain multiple copies of a MySQL data by having them copied automatically from a master to a slave database.

Setup

If you do not have mysql, you can install it with this command:

sudo apt-get install mysql-server mysql-client

Configure the Master Database

Open up the mysql configuration file on the master server.

sudo vi /etc/mysql/my.cnf

Replace the standard IP address with the IP address of server.

bind-address = 12.34.56.789

The next configuration change refers to the server-id, located in the [mysqld] section. You can choose any number for this spot (it may just be easier to start with 1), but the number must be unique and cannot match any other server-id in your replication group. Make sure this line is uncommented.

server-id = 1

Move on to the log_bin line. This is where the real details of the replication are kept. The slave is going to copy all of the changes that are registered in the log. For this step we simply need to uncomment the line that refers to log_bin:

log_bin = /var/log/mysql/mysql-bin.log (or) mysql-bin

Finally, we need to designate the database that will be replicated on the slave server. You can include more than one database by repeating this line for all of the databases you will need.

binlog_do_db = database_name

After you make all of the changes, go ahead and save and exit out of the configuration file.

Refresh MySQL.

sudo service mysql restart

The next steps will take place in the MySQL shell, itself.

Open up the MySQL shell.

mysql -u root -p

We need to grant privileges to the slave. You can use this line to name your slave and set up their password. The command should be in this format:

GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’%’ IDENTIFIED BY ‘slave_password’;

Follow up with:

FLUSH PRIVILEGES;

In your current tab switch to “database_name”.

USE database_name;

Following that, lock the database to prevent any new changes:

FLUSH TABLES WITH READ LOCK;

Then type in:

SHOW MASTER STATUS;

You will see a table that should look something like this:

mysql> SHOW MASTER STATUS;
+——————+———-+————–+——————+———————————————–+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+——————+———-+————–+——————+———————————————–+
| mysql-bin.000149 | 634 | database_name| | 2e6ff726-0956-11e7-838f-54ee75b21934:1-690205 |
+——————+———-+————–+——————+———————————————–+
1 row in set (0.00 sec)

This is the position from which the slave database will start replicating. Record these numbers, they will come in useful later.

If you make any new changes in the same window, the database will automatically unlock. For this reason, you should open the new tab or window and continue with the next steps there.

Proceeding the with the database still locked, export your database using mysqldump in the new window (make sure you are typing this command in the bash shell, not in MySQL).

mysqldump -u root -p –opt database_name > database_name.sql

Now, returning to your your original window, unlock the databases (making them writeable again). Finish up by exiting the shell.

UNLOCK TABLES;

QUIT;

Now you are all done with the configuration of the the master database.

Configure the Slave Database

Once you have configured the master database. You can put it aside for a while, and we will now begin to configure the slave database.

Log into your slave server, open up the MySQL shell and create the new database that you will be replicating from the master (then exit):

CREATE DATABASE database_name; (master and slave db name should be same)

EXIT;

Import the database that you previously exported from the master database.

mysql -u root -p database_name < /path/to/database_name.sql

Now we need to configure the slave configuration in the same way as we did the master:

sudo vi /etc/mysql/my.cnf

We have to make sure that we have a few things set up in this configuration. The first is the server-id. This number, as mentioned before needs to be unique. Since it is set on the default (still 1), be sure to change it’s something different.

server-id = 2

Following that, make sure that your have the following three criteria appropriately filled out:

relay-log = /var/log/mysql/mysql-relay-bin.log (You will need to add in the relay-log line: it is not there by default. Once you have made all of the necessary changes, save and exit out of the slave configuration file.)

log_bin = /var/log/mysql/mysql-bin.log (or) mysql-bin.log

binlog_do_db = database_name

Restart MySQL once again:

sudo service mysql restart

The next step is to enable the replication from within the MySQL shell.

Open up the the MySQL shell once again and type in the following details, replacing the values to match your information:

CHANGE MASTER TO MASTER_HOST=’Master Host IP’,MASTER_USER=’slave_user’, MASTER_PASSWORD=’slave_password’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS= 634;

MASTER_LOG_FILE=’mysql-bin.000001′ – copy file parameter value from SHOW MASTER STATUS
MASTER_LOG_POS= 634 – copy position parameter value from SHOW MASTER STATUS

This command accomplishes several things at the same time:
It designates the current server as the slave of our master server.
It provides the server the correct login credentials
Last of all, it lets the slave server know where to start replicating from; the master log file and log position come from the numbers we wrote down previously.

Activate the slave server:

START SLAVE;

You be able to see the details of the slave replication by typing in this command. The \G rearranges the text to make it more readable.

SHOW SLAVE STATUS\G;

If there is an issue in connecting, you can try starting slave with a command to skip over it:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

SLAVE START;

If you are getting the below error on slave sync

Got fatal error 1236 from master when reading data from binary log: ‘binlog truncated in the middle of event; consider out of disk space on master;
change MASTER_LOG_POS in my.cnf
MASTER_LOG_POS= 0

or run the below comment in slave db mysql shell

STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_POS = 0;
START SLAVE;
SHOW SLAVE STATUS\G;

Cookie Security: Cookie Not Sent Over SSL

This policy states that any area of the website or web application that contains sensitive information or access to privileged functionality such as remote site administration requires that all cookies are sent via SSL during an SSL session. The URL: ~FullURL~ has failed this policy. If a cookie is marked with the “secure” attribute, it will only be transmitted if the communications channel with the host is a secure one. Currently this means that secure cookies will only be sent to HTTPS (HTTP over SSL) servers. If secure is not specified, a cookie is considered safe to be sent in the clear over unsecured channels.

How to secure the cookie

Place the below code in .htaccess file

#Set Secure cookie

<IfModule mod_headers.c>

Header always edit Set-Cookie (.*) “$1; HTTPOnly; Secure”

</IfModule>

#Set Secure cookie

<IfModule php5_module>

php_value session.cookie_secure 1

</IfModule>

If you have multiple website sharing the same source code and few websites are not protected with SSL then use the below code in site specific settings.php instead of the above configuration.

$conf[‘https’] = TRUE;

ini_set(‘session.cookie_secure’, 1);

Directory traversal

While browsing web pages, most of us expect to see only the pages offered. However sometimes we come upon what looks like a listing of files that we might see in Windows Explorer as opposed to a web page. This is called a directory listing. It is sometimes used to offer files easily on the internet, but if unintended, it can allow an attacker to gain valuable information about your site.

 

How to fix directory traversal ?

Change Options Indexes in your apache configuration file (httpd.conf)

<Directory /home/mywebuser/public_html>

Options Indexes

</Directory>

Update the option ‘Indexes’ as “Options –Indexes”

Cross site scripting

Cross-Site Scripting vulnerabilities were verified as executing code on the web application. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site.

Issue fix:

Verify your input parameters using following methods.

Drupal:

Write the below code in your custom module hook_init method

$query_string = $_GET;

foreach ($query_string as $key => $value) {

$_GET[$key]=filter_xss($value);

}

Also add the below code in .htaccess file to avoid XSS attack

Between <IfModule mod_rewrite.c></IfModule >

#added to avoid the XSS attacks

RewriteCond %{REQUEST_URI} ^(.*?)[\”\’][^/]*$ [NC]

RewriteRule (.*)$ %1 [R=301,L]

Reference Links:

http://stackoverflow.com/questions/1336776/xss-filtering-function-in-php

TRACE method is enabled

HTTP TRACE method is enabled on this web server. In the presence of other cross-domain vulnerabilities in web browsers, sensitive header information could be read from any domains that support the HTTP TRACE method.

Issue Fix:

Add the below lines in your server httpd.conf file to disable the TRACE method, mod_rewrite must be active for these directives to be accepted.

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^TRACE

RewriteRule .* – [F]

 

Reference links: https://publib.boulder.ibm.com/httpserv/ihsdiag/http_trace.html

Browser Mime Sniffing is not disabled

Almost all browsers are designed to use a mime sniffing technique to guess the content type of the HTTP response instead of adhering to the Content-Type specified by the application in specific cases or ignoring the content when no mime type is specified. Inconsistencies introduced by the mime sniffing techniques could allow attackers to conduct Cross-Site Scripting attacks or steal sensitive user data. WebInspect has determined that the application fails to instruct the browser to strictly enforce the Content-Type specification supplied in the response.

Issue fix:

PHP: <?php header(‘X-Content-Type-Options: ‘nosniff’); ?>

Drupal: drupal_add_http_header(‘X-Content-Type-Options’, ‘nosniff’);

Or

Add the Header in .htaccess file in between <IfModule mod_headers.c></IfModule>

Header set X-Content-Type-Options nosniff

Cross-Frame Scripting

Browser vendors have introduced and adopted a policy-based mitigation technique using the X-Frame-Options header.

How to resolve ?

Add X-Frame-Options as SAMEORIGIN in header in case of using current website URL in iframe inside the website or use DENY.

E.g.

PHP: <?php header( ‘X-Frame-Options: SAMEORIGIN’ ); ?>

Drupal: drupal_add_http_header(‘X-Frame-Options’, ‘SAMEORIGIN’);

Or

Add the Header in .htaccess file in between <IfModule mod_headers.c></IfModule>

Header set X-Frame-Options DENY

To avoid click jacking attack add the below code in your JavaScript file

if (top.location != location) {

top.location = self.location;

}

Or

Add the below code in the header of html.tpl.php

<style>html { display:none }</style>

if (self == top) {

document.documentElement.style.display = ‘block’;

} else {

top.location = self.location;

}

Reference Links:

https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
https://drupal.org/node/1006980
http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html