Virtual Box and Alt/Tab Keys




I use virtual box for all my testing activities. It comes too often that I have a virtual box VM window open & I want to switch to my host machine to see some stuff like tutorials etc.. If you press the alt+tab combination it just works inside the VM & doesn't switches to host machine. In these scenarios you can press the host key once ( not hold it ) & then whatever you press goes to host machine. So in general where host key is the default Right Ctrl, just press Right Ctrl once & now press the alt+tab & it will switch you out to host machine. This is really helpful when you have the VM windows open or you're working on seamless mode.

Hope it help others too.
Read more ...

Set date and time in Linux


There are few ways to set the date and time on Linux command line. In order to do this, you must login as root and execute the following methods as follow:
For you to remember the syntax, issue the command “date” first
[root@linuxtechtips ~]# date
Mon Aug 20 18:30:29 SGT 2012
Let say you want to change it to Sept 6, 2012, 3pm, just follow the pattern above
[root@linuxtechtips ~]# date 090615002012
Thu Sep  6 15:00:00 SGT 2012
where as:

09 = month (September)
06 = day
15 = hour
00 = min
2012 = year

Now it’s set, as simple as that:

[root@linuxtechtips ~]# date
Thu Sep  6 15:00:01 SGT 2012

Another example, you want it to change to 20th of December, 2012, 10:45pm
[root@linuxtechtips ~]# date 122022452012
Thu Dec 20 22:45:00 SGT 2012
Viola!!!
[root@linuxtechtips ~]# date

Thu Dec 20 22:45:03 SGT 2012

Now if you want to challenge yourself, then you can use this as well:

Using our example date above, use the date command with –set or -s options

[root@linuxtechtips ~]# date -s "6 Sept 2012 15:00:00"
Thu Sep  6 15:00:00 SGT 2012
Extra tip: To set the hardware clock to the current system time, use:
[root@linuxtechtips ~]# hwclock  --systohc
If the other way around, to set the system time from the hardware clock
[root@linuxtechtips ~]# hwclock --hctosys


Read more ...

Install and Configure Config Server Firewall (CSF) on Ubuntu Linux


Introduction

Config Server Firewall (or CSF) is a free and advanced firewall for most Linux distributions. In addition to the basic functionality of a firewall – filtering packets – CSF includes other security features, such as login/intrusion/flood detections. CSF includes UI integration for cPanel, DirectAdmin and Webmin, but this tutorial only covers the command line usage. CSF is able to recognize many attacks, such as port scans, SYN floods, and login brute force attacks on many services. It is configured to temporarily block clients who are detected to be attacking the cloud server.

The full list of supported operating systems and features can be found on ConfigServer's website.

This tutorial is written for Debian based distro, such as Debian and Ubuntu but should work on RHEL/CentOS also. The commands should be executed with root permissions, by logging in as root, or initiating a root shell with the following command if sudo is installed:

sudo su
Features

Config Server Firewall offers a wide range of protections for your Server.

Login authentication failure daemon:
CSF checks the logs for failed login attempts at regular time interval, and is able to recognize most unauthorized attempts to gain access to your cloud server. You can define the desired action CSF takes and after how many attempts in the configuration file.

The following applications are supported by this feature:

·         Courier imap, Dovecot, uw-imap, Kerio
·         openSSH
·         cPanel, WHM, Webmail (cPanel servers only)
·         Pure-ftpd, vsftpd, Proftpd
·         Password protected web pages (htpasswd)
·         Mod_security failures (v1 and v2)
·         Suhosin failures
·         Exim SMTP AUTH
In addition to these, you are able define your own login files with regular expression matching. This can be helpful if you have an application which logs failed logins, but does block the user after specific number of attempts.

Process tracking
CSF can be configured to track processes in order to detect suspicious processes or open network ports, and send an email to the system administrator if any is detected. This may help you to identify and stop a possible exploit on your Server.

Directory watching
Directory watching monitors the /temp and other relevant folders for malicious scripts, and sends an email to the system administrator when one is detected.

Messenger service
Enabling this feature allows CSF to send a more informative message to the client when a block is applied. This feature has both pros and cons. On one hand, enabling it provides more information to the client, and thus may cause less frustration for instance in case of failed logins. On the other hand, this provides more information, which might make it easier for an attacker to attack your Server.

Port flood protection
This setting provides protection against port flood attacks, such as denial of service (DoS) attacks. You may specify the amount of allowed connections on each port within time period of your liking. Enabling this feature is recommended, as it may possibly prevent an attacker forcing your services down. You should pay attention to what limits you set, as too restrictive settings will drop connections from normal clients. Then again, too permissive settings may allow an attacker to succeed in a flood attack.

Port knocking
Port knocking allows clients to establish connections a server with no ports open. The server allows clients connect to the main ports only after a successful port knock sequence. You may find this useful if you offer services which are available to only limited audience.


Connection limit protection
This feature can be used to limit the number concurrent of active connections from an IP address to each port. When properly configured, this may prevent abuses on the server, such as DoS attacks. 

Port/IP address redirection
CSF can be configured to redirect connections to an IP/port to another IP/port. Note: After redirection, the source address of the client will be the server's IP address. This is not an equivalent to network address translation (NAT).

UI integration
In addition to command line interface, CSF also offers UI integration for cPanel and Webmin. If you are not familiar with Linux command line, you might find this feature helpful.

IP block lists
This feature allows CSF to download lists of blocked IP addresses automatically from sources defined by you.


Installing ConfigServer Firewall

Step 1: Downloading

Config Server Firewall is not currently available in Debian or Ubuntu repositories, and has to be downloaded from the ConfigServer's website.
This will download CSF to your current working directory.
Step 2: Uncompressing

The downloaded file is a compressed from of tar package, and has to be uncompressed and extracted before it can be used.
tar -xzf csf.tgz
Step 3: Installing

If you are using another firewall configuration scripts, such as UFW, you should disable it before proceeding. Iptables rules are automatically removed.

UFW can be disabled by running the following command:

ufw disable

Now it is time to execute the CSF's installer script.

cd csf
sh install.sh

The firewall is now installed, but you should check if the required iptables modules are available.

perl /usr/local/csf/bin/csftest.pl

The firewall will work if no fatal errors are reported.

Note: Your IP address was added to the whitelist if possible. In addition, the SSH port has been opened automatically, even if it uses custom port. The firewall was also configured to have testing mode enabled, which means that the iptables rules will be automatically removed five minutes after starting CSF. This should be disabled once you know that your configuration works, and you will not be locked out.

Basic Configuration

CSF can be configured by editing its configuration file csf.conf in /etc/csf:
nano /etc/csf/csf.conf
The changes can be applied with command:
csf -r
Step 1: Configuring ports

The less access there is to your Server, the more secure your server is. However, not all ports can be closed as the clients must be able to use your services. 

The ports opened by default are the following:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"

TCP_OUT = "20,21,22,25,53,80,110,113,443"

UDP_IN = "20,21,53"

UDP_OUT = "20,21,53,113,123"
Services using the open ports:



·         Port 20: FTP data transfer
·         Port 21: FTP control
·         Port 22: Secure shell (SSH)
·         Port 25: Simple mail transfer protocol (SMTP)
·         Port 53: Domain name system (DNS)
·         Port 80: Hypertext transfer protocol (HTTP)
·         Port 110: Post office protocol v3 (POP3)
·         Port 113: Authentication service/identification protocol
·         Port 123: Network time protocol (NTP)
·         Port 143: Internet message access protocol (IMAP)
·         Port 443: Hypertext transfer protocol over SSL/TLS (HTTPS)
·         Port 465: URL Rendesvous Directory for SSM (Cisco)
·         Port 587: E-mail message submission (SMTP)
·         Port 993: Internet message access protocol over SSL (IMAPS)
·         Port 995: Post office protocol 3 over TLS/SSL (POP3S)
It is possible that you are not using all of these services, so you can close the ports that are not used. I would recommend closing all ports (removing port number form the list), and then adding the ports you need.

Below are port sets that should be opened if you are running the listed service:

On any server:

TCP_IN: 22,53
TCP_OUT: 22,53,80,113,443
UPD_IN: 53
UPD_OUT: 53,113,123
Apache:
TCP_IN: 80,443
FTP server:
TCP_IN: 20,21
TCP_OUT: 20,21
UPD_IN: 20,21
UPD_OUT:20,21
Mail server:
TCP_IN: 25,110,143,587,993,995
TCP_OUT: 25,110
MySQL server (if remote access is required)
TCP_IN: 3306
TCP_OUT: 3306
Note: If you are using IPv6 for your services, you should also configure TCP6_IN, TCP6_OUT, UPD6_IN, and UPD6_OUT similarly to how IPv4 ports were configured earlier.

You can find a comprehensive list of TCP and UDP ports on Wikipedia. You should open the ports of all the services you use.

Step 2: Additional settings

CSF offers a vast number of different options in its configuration files. Some of the most commonly used settings are explained below.

ICMP_IN
Setting ICMP_IN to 1 allows ping to your server and 0 refuses are such requests. If you are hosting any public services, it is recommended to allow ICMP requests, as these can be used to determine whether or not your service is available.

ICMP_IN_LIMIT
Sets the number of ICMP (ping) requests allowed from one IP address within a specified amount of time. There is usually no need to change the default value (1/s)

DENY_IP_LIMIT
Sets the number of blocked IP addresses CSF keeps track of. It is recommended to limit the number of denied IP addresses as having too many blocks may slow down the server performance.

DENY_TEMP_IP_LIMIT
Same as above, but for temporary IP address blocks.

PACKET_FILTER
Filter invalid, unwanted and illegal packets.

SYNFLOOD, SUNFLOOD_RATE and SYNFLOOD_BURST
This offers protection against SYN flood attacks. This slows down the initialization of every connection, so you should enable this only if you know that your server is under attack.

CONNLIMIT
Limits the number of concurrent active connections on port.

Value:

22;5;443;20
would allow 5 concurrent connections on port 22 and 20 concurrent connections on port 443.

PORTFLOOD
Limits the number of connections per time interval that new connections can be made to specific ports. Value:

22;tcp;5;250
would limit block the IP address if more than 5 connections are established on port 22 using TCP protocol within 250 seconds. The block is removed once 250 seconds have passed after the last packet sent by the client to this port. You may add more ports by separating them by commas like described below.
port1;protocol1;connection_count1;time1,port2;protocol2;connection_count2;time2

More settings
CSF offers a wide range of settings which are not covered in this tutorial. The default values are generally good, and can be used on almost any server. The default settings are configured to prevent most flood attacks, port scans and unauthorized access attempts.

If you would, however, like to adjust the configuration in more detail, please read the comments in /etc/csf/csf.conf and edit them as you like. 


Step 3: Applying the Changes

Whenever you are altering the settings in csf.conf, you should save the files and restart CSF in order for the changes to take effect. Once you are ready with the configuration, close the file by pressing Ctrl + X. When you are asked whether to save the changes or not, press Y to save the changes.

After this, you should apply the changes by restarting CSF with command:

csf -r

If everything went like planned, and you are still able to access the server, open the configuration file once more:

nano /etc/csf/csf.conf
and change setting TESTING at the beginning of the configuration file to 0 as shown below:
TESTING = "0"

Save the file, and apply the changes with command:

csf -r
Blocking and Allowing IP Addresses

One of the most basic features of a firewall is the ability to block certain IP addresses. You may deny (blacklist), allow (whitelist) or ignore IP addresses by editing the configuration files csf.deny, csf.allow and csf.ignore.

Blocking IP addresses
If you would like to block an IP address or range, open csf.deny.

nano /etc/csf/csf.deny
Blocked IP addresses or ranges all reserve one line in csf.deny file. If you would like to block IP address 1.2.3.4 as well as IP range 2.3.*.*, you should add the following lines to the file:
1.2.3.4
IP ranges are represented using the CIDR notation

Allowing IP addresses
If you would like an IP address or range to be excluded from all blocks and filters, you may add them to csf.allow file. Please note that allowed IP addresses are allowed even if they are explicitly blocked in csf.deny file.

Allowing IP addresses works similarly to blocking them. The only difference is that you should edit /etc/csf/csf.allow instead of csf.deny.

nano /etc/csf/csf.allow
Ignoring IP addresses
CSF also offers ability to exclude IP addresses from the firewall filters. IP addresses in csf.ignore will bypass the firewall filters, and can only be blocked if listed in csf.deny file.

nano /etc/csf/csf.ignore
In order to changes take effect, you should restart CSF after editing any of the files described above with command:
csf -r


Read more ...

Set Up Apache Virtual Hosts on CentOS 6


About Virtual Hosts

Virtual Hosts are used to run more than one domain off of a single IP address. This is especially useful to people who need to run several sites off of one virtual private server. The sites display different information to the visitors, depending on with which the users accessed the site.There is no limit to the number of virtual hosts that can be added to a VPS.



Set Up
The steps in this tutorial require the user to have root privileges. You can see how to set that up in the Initial Server Setup in steps 3 and 4. Furthermore, if I reference the user in a step, I’ll use the name www. You can implement whatever username suits you. 

Additionally, you need to have apache already installed and running on your virtual server 
If this is not the case, you can download it with this command:

yum install httpd



Step One— Create a New Directory

The first step in creating a virtual host is to a create a directory where we will keep the new website’s information. 

This location will be your Document Root in the Apache virtual configuration file later on. By adding a -p to the line of code, the command automatically generates all the parents for the new directory.

mkdir -p /var/www/example.com/public_html

You will need to designate an actual DNS approved domain, or an IP address, to test that a virtual host is working. In this tutorial we will use example.com as a placeholder for a correct domain name. 

However, should you want to use an unapproved domain name to test the process you will find information on how to make it work on your local computer in Step Six. 



Step Two—Grant Permissions

We need to grant ownership of the directory to the user, instead of just keeping it on the root system.
chown -R www:www /var/www/example.com/public_html

Additionally, it is important to make sure that everyone will be able to read our new files.

chmod 755 /var/www

Now you are all done with permissions.



Step Three— Create the Page

We need to create a new file called index.html within our configurations directory.
vi /var/www/example.com/public_html/index.html

We can add some text to the file so we will have something to look at when the IP redirects to the virtual host.

<html>
  <head>
    <title>www.example.com</title>
  </head>
  <body>
    <h1>Success: You Have Set Up a Virtual Host</h1>
  </body>
</html>

Save and Exit



Step Four—Turn on Virtual Hosts

The next step is to enter into the apache configuration file itself.
vi /etc/httpd/conf/httpd.conf

There are a few lines to look for.
Make sure that your text matches what you see below.

#Listen 12.34.56.78:80
Listen 80

Scroll down to the very bottom of the document to the section called Virtual Hosts.

NameVirtualHost *:80
#
# NOTE: NameVirtualHost cannot be used without a port specifier
# (e.g. :80) if mod_ssl is being used, due to the nature of the
# SSL protocol.
#   

#   
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#
<VirtualHost *:80>
     ServerAdmin webmaster@example.com
     DocumentRoot /var/www/example.com/public_html
     ServerName www.example.com
     ServerAlias example.com
     ErrorLog /var/www/example.com/error.log
     CustomLog /var/www/example.com/requests.log
</VirtualHost>

The most important lines to focus on are the lines that say NameVirtualHost, Virtual Host, Document Root, and Server Name. Let’s take these one at a time. 

- Uncomment (remove the number sign) NameVirtualHost without making any changes. The star means that any IP address going through port 80 will be a virtual host. As your system probably only has one IP address this is not an issue—however, if you prefer, you can replace the star with your IP address.

- You can leave the rest of the number marks in place until you reach the line <VirtualHost *:80> . Uncomment everything from there through <VirtualHost>.

- Leave <VirtualHost *:80> as is—its details must match with those in the NameVirtual Host section. If you replaced the star with your IP address in that section, be sure to do the same here. 

- Document Root is key! For this section, write in the extension of the new directory created in Step One. If the document root is incorrect or absent you will not be able to set up the virtual host.

- Server Name is another important piece of information, containing the virtual host’s domain name (eg. www.example.com). Make sure that you spell the domain out in full; we will put in any alternate possibilities in the next line.

- ServerAlias is a new line in the config file that is not there by default. Adding it will allow you to list a few variants of the domain name, for example without the www in the front. 




The rest of the lines in this section are not required to set up a virtual host. However, it is still helpful to know what they do. 

- Server admin asks for the webmaster’s email. 

- The Error Logs and Custom Logs keep track of any issues with the server. The error log covers issues that arise while maintaining the server, and the custom log tracks server requests. You can set up a custom location for these processes.

- Make sure that <VirtualHost> is uncommented; then save and exit.



Step Five—Restart Apache

We’ve made a lot of the changes to the configuration. However, they will not take effect until Apache is restarted. 
First stop all apache processes:

apachectl -k stop

Then start up apache once again.

/etc/init.d/httpd start

You may see the following error:

Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

The message is just a warning, and you will be able to access your virtual host without any further issues.



Optional Step Six—Setting Up the Local Hosts

If you have pointed your domain name to your virtual private server’s IP address you can skip this step—you do not need to set up local hosts. Your virtual hosts should work. However, if want to try out your new virtual hosts without having to connect to an actual domain name, you can set up local hosts on your computer alone. 

For this step, make sure you are on the computer itself, not your server. 

To proceed with this step you need to know your computer’s administrative password, otherwise you will be required to use an actual domain name to test the virtual hosts.

If you are on a Mac or Linux, access the root user (su) on the computer and open up your hosts file:

nano /etc/hosts

If you are on a Windows Computer, you can find the directions to alter the host file on the Microsoft site

You can add the local hosts details to this file, as seen in the example below. As long as that line is there, directing your browser toward, say, example.com will give you all the virtual host details for the corresponding IP address.

# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost

#Virtual Hosts
12.34.56.789    www.example.com

However, it may be a good idea to delete these made up addresses out of the local hosts folder when you are done to avoid any future confusion. 



Step Seven—RESULTS: See Your Virtual Host in Action

Once you have finished setting up your virtual host, you can see how it looks online. Type your ip address into the browser (ie. http://12.34.56.789) 

Good Job!



Adding More Virtual Hosts

To create additional virtual hosts, you can just repeat the process above, being careful to set up a new document root with the appropriate new domain name each time. Then just copy and paste the new Virtual Host information into the Apache Config file, as shown below
<VirtualHost *:80>
     ServerAdmin webmaster@example.com
     DocumentRoot /var/www/example.com/public_html
     ServerName www.example.com
     ServerAlias example.com
     ErrorLog /etc/var/www/example.com/error.log
     CustomLog /var/www/example.com/requests.log
</VirtualHost>
<VirtualHost *:80>
     ServerAdmin webmaster@example.org
     DocumentRoot /var/www/example.org/public_html
     ServerName www.example.org
     ServerAlias example.org
     ErrorLog /var/www/example.org/error.log
     CustomLog /var/www/example.orgrequests.log
</VirtualHost>



See More:-

Once you have set up your virtual hosts, you can proceed to Create a SSL Certificate for your site

Read more ...

Email me @

linux@outlook.in

Get Kernel

Follow by Email