Prerequisites

Before starting with the tutorial, make sure you are logged in as a user with sudo privileges.

Disable FirewallD

To disable firewalld on your system follow these steps:

1. Type the following command to stop the FirewallD service:sudo systemctl stop firewalld
2. Disable the FirewallD service to start automatically on system boot:sudo systemctl disable firewalld
3. Mask the FirewallD service to prevent it from being started by another services:sudo systemctl mask --now firewalld

Install and Enable Iptables

Perform the following steps to install Iptables on a CentOS 7 system:

1. Run the following command to install the iptables-service package from the CentOS repositories:sudo yum install iptables-services
2. Once the package is installed start the Iptables service:sudo systemctl start iptablessudo systemctl start ip6tables
3. Enable the Iptables service to start automatically on system boot:sudo systemctl enable iptablessudo systemctl enable ip6tables
4. Check the iptables service status with:sudo systemctl status iptablessudo systemctl status ip6tables
5. To check the current iptables rules use the following commands:sudo iptables -nvLsudo ip6tables -nvLBy default only the SSH port 22 is open. The output should look something like this:Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source destination
   5400 6736K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
   0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
   2 148 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
   3 180 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
   0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

   Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source destination
   0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

   Chain OUTPUT (policy ACCEPT 4298 packets, 295K bytes)
pkts bytes target prot opt in out source destination

At this point, you have successfully enabled the iptables service and you can start building your firewall. The changes will persist after a reboot.

Conclusion

In this tutorial, you learned how to disable the FirewallD service and install iptables.

If you have any questions or remarks, please leave a comment below.

If the server has cPanel , we recommend you install ClamAV first, as maldet will use the ClamAV scan engine. ClamAV installation instructions are available here.

You will need to be logged in as root to the server over SSH.

1 – Install maldet

cd /usr/local/src/ && wget http://www.rfxn.com/downloads/maldetect-current.tar.gz && tar -xzvf maldetect-current.tar.gz && cd maldetect-* && sh install.sh

This will automatically install a cronjob inside /etc/cron.daily/maldet so a daily scan will be run for local cPanel or Plesk accounts.
2 – Make sure to update to the latest version and virus signatures:

maldet -d && maldet -u

3 – Run the first scan manually

To scan a specific user’s home directory, run the following command:

maldet -a /home/user

To launch a background scan for all user’s public_html and public_ftp in all home directories, run the following command:

maldet -b –scan-all /home?/?/public_?

(We also recommend you to scan /tmp and /dev/shm/)

4 – Verify the scan report

We recommend you to always read the scan reports before doing a quarantine. You will also be able to identify infected websites for further actions.

List all scan reports time and SCANID:

maldet –report list

Show a specific report details :

maldet –report SCANID

Show all scan details from log file:

grep “{scan}” /usr/local/maldetect/event_log

5 – Clean the malicious files

By default the quarantine is disabled. You will have to launch it manually.

maldet -q SCANID

6 – (optional) Automatically quarantine detected malware

Please review these configuration variables in /usr/local/maldetect/conf.maldet
variable     value     description
quar_hits     number     if the number is different than 0, enables automatic quarantine

7- (optional) Configure scan reports e-mail alerts

Maldet can send you and email alert each time it detects malware. Please review these configuration variables in /usr/local/maldetect/conf.maldet
variable     value     description
email_alert     1 or 0     enable or disable e-mail alerts
email_addr      e-mail address      target e-mail for notifications, should be put in quotes like: “myuser@mydomain.com”

More information is available: /usr/local/maldetect/conf.maldet or https://www.rfxn.com/projects/linux-malware-detect/

cp /etc/localtime /root/old.timezone
rm /etc/localtime
ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime

Verify new settings by typing the following two commands:

date
ls -l /etc/localtime

Thats it

cd /path/to/your/folder/nikeshshakya
sed -i ‘s/original/new/g’ file.txt
Explanation:

s = the substitute command
original = a regular expression describing the word to replace (or just the word itself)
new = the text to replace it with
g = global (i.e. replace all and not just the first occurrence)
file.txt = the file name

Or to make replace on all files on folder
cd /path/to/your/folder/nikeshshakya
sed -i ‘s/foo/bar/g’ *

CREATE USER 'nikesh'@'localhost' IDENTIFIED BY 'password';

Sadly, at this point newuser has no permissions to do anything with the databases. In fact, if newuser even tries to login (with the password, password), they will not be able to reach the MySQL shell.

Therefore, the first thing to do is to create new database and provide the user with access to that database.

create database nikeshdb;

GRANT ALL PRIVILEGES ON nikeshdb.* TO 'nikeshshk'@'localhost';

The asterisks in this command refer to table that they can access—this specific command allows to the user to read, edit, execute and perform all tasks across all the databases and tables.
Once you have finalized the permissions that you want to set up for your new users, always be sure to reload all the privileges.

FLUSH PRIVILEGES;

Your changes will now be in effect.

How To Grant Different User Permissions
Here is a short list of other common possible permissions that users can enjoy.

ALL PRIVILEGES- as we saw previously, this would allow a MySQL user all access to a designated database (or if no database is selected, across the system)
CREATE- allows them to create new tables or databases
DROP- allows them to them to delete tables or databases
DELETE- allows them to delete rows from tables
INSERT- allows them to insert rows into tables
SELECT- allows them to use the Select command to read through databases
UPDATE- allow them to update table rows
GRANT OPTION- allows them to grant or remove other users' privileges
To provide a specific user with a permission, you can use this framework:

GRANT [type of permission] ON [database name].[table name] TO ‘[username]’@'localhost’;
If you want to give them access to any database or to any table, make sure to put an asterisk (*) in the place of the database name or table name.

Each time you update or change a permission be sure to use the Flush Privileges command.

If you need to revoke a permission, the structure is almost identical to granting it:

REVOKE [type of permission] ON [database name].[table name] FROM ‘[username]’@‘localhost’;
Just as you can delete databases with DROP, you can use DROP to delete a user altogether:

DROP USER ‘demo’@‘localhost’;
To test out your new user, log out by typing

quit
and log back in with this command in terminal:

mysql -u [username]-p

sudo a2enmod ssl

Create new directory for the self signed certificate

sudo mkdir /etc/apache2/ssl

Create the self signed certificate and the server key that protects it, and placing both of them into the new directory

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/owncloud.key -out /etc/apache2/ssl/owncloud.crt

Now we setup the certificate

sudo nano /etc/apache2/sites-available/default-ssl.conf

The lines that need changing are the following

ServerName 192.168.1.11:443
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/owncloud.crt
SSLCertificateKeyFile /etc/apache2/ssl/owncloud.key

Activate the new vhost

sudo a2ensite default-ssl

Restart apache

sudo service apache2 restart

You can do the following steps in front of your Ubuntu 9.04 Server or remote access it via OpenSSH.

For OpenSSH, your Ubuntu 9.04 Server is at 192.168.0.10 :

ssh 192.168.0.10 -l nikesh

Step 1 :

The avoid someone to list your files on your Apache directory, you should do the following step.

sudo nano /etc/apache2/sites-available/default

Add a minus “-” in the front of “Indexes” and it will looking like this :

    Options -Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all

Step 2 :

To enable the rewrite module of Apache.

sudo a2enmod rewrite

To avoid Cross-Site-Tracing attack. Add the following lines within ” ” :

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* – [F]

Step 3 :

To avoid HTTP DoS, DDoS or Brute Force attack, you should install this module.

sudo apt-get install libapache2-mod-evasive

Step 4 :

To screen out bad URL requests, such as /etc/shadow or MySQL injection and etc. You should install mod_security module. If you installed a amd64 (64-bit) version of Ubuntu Server, please replaced i386 with amd64 for the following commands.

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/libapache-mod-security_2.5.9-1_i386.deb

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/mod-security-common_2.5.9-1_all.deb

sudo dpkg -i libapache-mod-security_2.5.9-1_i386.deb mod-security-common_2.5.9-1_all.deb

Step 5 :

Do not allow any Apache and Ubuntu Server information to be print on the error pages.

sudo nano /etc/apache2/conf.d/security

Change the following lines as the following :

ServerToken Prod
ServerSignature Off

Step 6 :

Now, it is time to harden the PHP.

sudo nano /etc/php5/apache2/php.ini

Change the following lines as the following :

display_errors = Off
log_errors = On
allow_url_fopen = Off
safe_mode = On
expose_php = Off
enable_dl = Off
disable_functions = system, show_source, symlink, exec, dl, shell_exec, passthru, phpinfo, escapeshellarg, escapeshellcmd

Step 7 :

Final step is to restart Apache server.

sudo /etc/init.d/apache2 restart

Step 8 :

sudo nano /etc/sysctl.conf
Uncomment the following line and make it look like this.

#Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

Make the change active.

sudo /sbin/sysctl -p

That’s all. See you!

The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorized remote users to assign Bash environment variables. Examples of exploitable systems include the following:

• Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
• Certain DHCP clients
• OpenSSH servers that use the ForceCommand capability
• Various network-exposed services that use Bash

A detailed description of the bug can be found at CVE-2014-6271 and CVE-2014-7169.

Because the Shellshock vulnerability is very widespread–even more so than the OpenSSL Heartbleed bug–and particularly easy to exploit, it is highly recommended that affected systems are properly updated to fix or mitigate the vulnerability as soon as possible. We will show you how to test if your machines are vulnerable and, if they are, how to update Bash to remove the vulnerability.

Note: (Sept. 25, 2014 – 6:00pm EST) At the time of writing, only an “incomplete fix” for the vulnerability has been released. As such, it is recommended to update your machines that run Bash immediately, and check back for updates and a complete fix.

Check System Vulnerability

On each of your systems that run Bash, you may check for Shellshock vulnerability by running the following command at the bash prompt:

env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

The highlighted echo Bash is vulnerable! portion of the command represents where a remote attacker could inject malicious code; arbitrary code following a function definition within an environment variable assignment. Therefore, if you see the following output, your version of Bash is vulnerable and should be updated:

Bash is vulnerable!
Bash Test

Otherwise, if your output does not include the simulated attacker’s payload, i.e. “Bash is vulnerable” is not printed as output, your version of bash is not vulnerable. It may look something like this:

bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test

If your version of Bash is vulnerable, read on to learn how to update Bash and fix the vulnerability.

Test Remote Sites

If you simply want to test if websites or specific CGI scripts are vulnerable, use this link:‘ShellShock’ Bash Vulnerability CVE-2014-6271 Test Tool.

Simply enter the URL of the website or CGI script you want to test in the appropriate form and submit.

Fix Vulnerability: Update Bash

The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash. The following subsections cover updating Bash on various Linux distributions, including Ubuntu, Debian, CentOS, Red Hat, and Fedora.

Note: (Sept. 25, 2014 – 6:00pm EST) At the time of writing, only an “incomplete fix” for the vulnerability has been released. As such, it is recommended to update your machines that run Bash immediately, and check back for updates and a complete fix.

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via apt-get:

sudo apt-get update && sudo apt-get install --only-upgrade bash

Now check your system vulnerability again by running the command in the previous section (Check System Vulnerability).

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

Now check your system vulnerability again by running the command in the previous section (Check System Vulnerability).

Conclusion

Be sure to update all of your affected servers to the latest version of Bash!

The new change, in addition to the search box getting a prominent spot just under the site description, also takes advantage of auto-complete when people type something into the search box.

The new search box is available for both desktop and mobile searches.  Here it is for desktop:

Here is the mobile version of the new search box.

Google provides documentation so webmasters can enable this so any searches done within the sitelinks search box will direct people right to the results page on your site.  You need to have a working search engine on your site, however you can also use Google’s Custom Search Engine.

Webmasters also need to add the correct schema.org markup to their page, which can befound here.

There also are a list of recommended practices for webmasters in order to use this feature correctly.

Site-wide configurations

• Set a preferred canonical URL for your domain’s homepage using the rel=”canonical” link element on all variants of the homepage. This helps Google Search choose the correct URL for your markup.
• Prevent crawling of your site’s search results pages with robots.txt. See more in our Webmaster Guidelines.
• Make sure that your server supports UTF-8 character encoding.

• Markup guidelines
  • Put the markup on the homepage of your site. It is not necessary for the markup to be repeated on other pages of your site.
  • We recommend JSON-LD. Alternatively, you can use microdata.
  • Specify only one URL search pattern for the target. We are experimenting with multiple pattern support, so if you have feedback or use cases for multiple target support, let us know in our Webmaster Central Help Forum.

Google does not currently have a testing tool for this specifically, however I expect we will see it added to Google Webmaster Tools in the near future.

I expect this feature will become popular as it gives webmasters the ability to drive traffic to specific pages that a user might be searching for, while eliminating a step in order to get them there.  And of course, it gives a website listing in the Google search results even more real estate on the Google results page, something that can easily be used to edge competitors even lower on the page of search results.

If you have a wav file (in what format?) you can convert it using the sox program.

– Raw linear, signed 16 bit, mono, 8000 Hz (.slin)

    sox file.wav -t raw -r 8000 -c 1 -w -s file.slin

– Raw mu-law, mono, 8000 Hz (.mulaw or .u)

    sox file.wav -t raw -r 8000 -c 1 -b 8 -U file.mulaw

– Raw A-law, mono, 8000 Hz (.alaw or .A)

    sox file.wav -t raw -r 8000 -c 1 -b 8 -A file.alaw

– Raw GSM, mono, 8000 Hz (.gsm)

    sox file.wav -t raw -r 8000 -c 1 -b 8 -g file.gsm
    (not all versions of sox support this conversion)

– SUN/SGI audio/basic file, mono 8000 Hz (.au) containing:

    - Signed linear
        sox file.wav -r 8000 -c 1 -w -s file.au
    - alaw
        sox file.wav -r 8000 -c 1 -b 8 -A file.au
    - mulaw
        sox file.wav -r 8000 -c 1 -b 8 -U file.au

In addition basic format “conversion” if needed:

– WAV into RAW (tested with an A-law, mono, 8000 Hz riff wavefile)

    sox file.wav file.raw

The SUN/SGI formats have the advantage of being easily playable in a Web browser and it also preserves the format information.

The output format should always be mono, 8 kHz as that is required for telephony.

Converting into WAV files

If you have a mono 8kHz raw data file you can convert it into wave file by using sox

– Raw A-law, mono, 8000 Hz (.alaw or .A)

    sox -t raw -r 8000 -A -b 8 -c 1 file.alaw file.wav

– mulaw, mono 8000 Hz (.mulaw)

    sox -t raw -r 8000 -U -b 8 -c 1 file.mulaw test.wav