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!

Making use of a second drive for extra space? Here’s a quick run-down:

1) Make sure you know which disk is being formatted. First, second, and third drives will be /dev/sda, /dev/sdb, and /dev/sdc respectively. Check this with fdisk -l

[03:50:04] [root@virt ~]# fdisk -l

Disk /dev/sda: 34.3 GB, 34359738368 bytes
255 heads, 63 sectors/track, 4177 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        4177    33447330   8e  Linux LVM

Disk /dev/sdb: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdb doesn't contain a valid partition table

2) You can see that /dev/sdb (our second hard drive) does not have any partitions. We will need to create a partition(s) on the drive and then make a file system on it, then mount it. Let’s write partitions to the drive using fdisk /dev/sdb:

[03:53:01] [root@virt ~]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

Command (m for help): m
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Command (m for help):

3) As you can see from the help menu (by using the command “m”) we want to add a new partition. Using the defaults will use the entire disk. After it’s created, you will want to use the command “w” to “write table to disk and exit”.

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1044, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-1044, default 1044): 
Using default value 1044

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[03:54:58] [root@virt ~]#

4) Now you will notice that the output of fdisk -l /dev/sdb shows a partition as /dev/sdb1:

[03:57:08] [root@virt ~]# fdisk -l /dev/sdb

Disk /dev/sdb: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        1044     8385898+  83  Linux

5) Now we need to create a file system on it. I’ve always used ext3 for general use/purposes. You’ll want to use the command mkfs -t ext3 /dev/sdb1 as shown here:

[03:58:38] [root@virt ~]# mkfs -t ext3 /dev/sdb1
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1048576 inodes, 2096474 blocks
104823 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648
64 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

6) Great, now we have a single partitioned secondary drive using ext3 file system. Now you want to create a directory to mount it in; lets just use “/drive2″. You’ll need to use the command mount -t [filesystem] [source] [mount directory] to mount it.

[03:59:50] [root@virt ~]# mount -t ext3 /dev/sdb1 /drive2/

7) Now you’ll notice, via df, that the drive is mounted:

[03:59:57] [root@virt ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       28G  1.4G   25G   6% /
/dev/sda1              99M   19M   76M  20% /boot
tmpfs                1014M     0 1014M   0% /dev/shm
/dev/sdb1             7.9G  147M  7.4G   2% /drive2

8) Last step – you want to make sure the drive automatically mounts itself when the server boots/reboots. You’ll need to add the following line to your /etc/fstab file:

/dev/sdb1  /drive2  ext3  defaults 0 0

.

All done!

1. Login to the server via SSH using as root ID.
2. Ensure that you’re at home directory of root. The open up the .bash_profile for editing using vi by typing one of the following commands at command shell line:vi .bash_profile
3. Scroll down to the end of the file and add the following line:

   echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d"(" -f2 | cut -d")" -f1`"user@nikeshshk.com.np
   

   Replace user@nikeshshk.com.np with the actual email account address that you want to the root access alert notification been sent to. Note that you can change the text contains in the email alert too. The text starting with first ALERT is written as email body, and you can add in other info such as host name or change the wordings. The second Alert is the email title which you can change to your own too.

Now logout and login again as root, you should receive an email alert at your inbox. The security trick should works on most popular flavor of Linux such as RedHat, CentOS, Ubuntu, FreeBSD and etc.

CREATE TABLE [dbo].[ATTENDANCE](
[EMPLOYEE_ID] [varchar](50) NOT NULL,
[ATTENDANCE_DATE] [date] NOT NULL
) ON [PRIMARY]

Now insert some data into this table.

INSERT INTO dbo.ATTENDANCE (EMPLOYEE_ID,ATTENDANCE_DATE)VALUES
('A001',CONVERT(DATETIME,'01-01-11',5))
INSERT INTO dbo.ATTENDANCE (EMPLOYEE_ID,ATTENDANCE_DATE)VALUES
('A001',CONVERT(DATETIME,'01-01-11',5))
INSERT INTO dbo.ATTENDANCE (EMPLOYEE_ID,ATTENDANCE_DATE)VALUES
('A002',CONVERT(DATETIME,'01-01-11',5))
INSERT INTO dbo.ATTENDANCE (EMPLOYEE_ID,ATTENDANCE_DATE)VALUES
('A002',CONVERT(DATETIME,'01-01-11',5))
INSERT INTO dbo.ATTENDANCE (EMPLOYEE_ID,ATTENDANCE_DATE)VALUES
('A002',CONVERT(DATETIME,'01-01-11',5))
INSERT INTO dbo.ATTENDANCE (EMPLOYEE_ID,ATTENDANCE_DATE)VALUES
('A003',CONVERT(DATETIME,'01-01-11',5))

After inserting the data, check the data of the below table. If we grouped the employee_id and attendance_date, then A001 and A002 become duplicates.
EMPLOYEE_ID ATTENDANCE_DATE
A001 2011-01-01
A001 2011-01-01
A002 2011-01-01
A002 2011-01-01
A002 2011-01-01
A003 2011-01-01

So how can we delete those duplicate data?
Solution

First, insert an identity column in that table by using the following code:

ALTER TABLE dbo.ATTENDANCE ADD AUTOID INT IDENTITY(1,1)

Now the table data will be like the following table:
EMPLOYEE_ID ATTENDANCE_DATE AUTOID
A001 2011-01-01 1
A001 2011-01-01 2
A002 2011-01-01 3
A002 2011-01-01 4
A002 2011-01-01 5
A003 2011-01-01 6

Check the AUTOID column. Now we will start playing the game with this column.

Now use the following code to find out the duplicate rows that exist in the table.

SELECT * FROM dbo.ATTENDANCE WHERE AUTOID NOT IN (SELECT MIN(AUTOID) FROM dbo.ATTENDANCE GROUP BY EMPLOYEE_ID,ATTENDANCE_DATE)

The above code will give us the following result:
EMPLOYEE_ID ATTENDANCE_DATE AUTOID
A001 2011-01-01 2
A002 2011-01-01 4
A002 2011-01-01 5

Ultimately, these are the duplicate rows which we want to delete to resolve the issue. Use the following code to resolve it.

DELETE FROM dbo.ATTENDANCE WHERE AUTOID NOT IN (SELECT MIN(AUTOID) FROM dbo.ATTENDANCE GROUP BY EMPLOYEE_ID,ATTENDANCE_DATE)

Now check the data. No duplicate rows exist in the table.

Is it too complicated? I dont think so

ls -lah /home/username/public_html/pathtofile
lsattr /home/username/public_html/pathtofile


The first command will show the file and ownership permissions. If they are 000 or root:root, the root user should still be able to remove the file regardless with this command:

cd /home/username/public_html/pathtofolder
rm filename

People can really get into trouble by running rm commands without ensuring they are at the correct directory path for the removal.

Next, the “lsattr” command above, the second one, will show if there are any attributes set on the file. If you see a -i on the lsattr command, then run this command to unset that attribute:

chattr -i /home/username/public_html/pathtofile

This will remove that immutable file attribute. What immutable does would be preventing changing and removing a file. If the file has that set on it, even the root user cannot remove the file and this is my suspicion on what might be happening if you haven’t been able to remove it even as the root user in root SSH.

$ find /home/user/demo -type f -print

To find all files in /home/user/demo directory with permission 777, enter:

$ find /home/user/demo -type f -perm 777 -print

Finally, apply new permission using the -exec option as follows:

$ find /home/user/demo -type f -perm 777 -print -exec chmod 755 {} \;

To select directories and subdirectories use the following syntax:

$ find /home/user/demo -type d -perm 777 -print -exec chmod 755 {} \;

@echo off

command1
REM wait for 10 seconds before executing command2
timeout /t 10
command2