Category: Administration

Test server download speeds

June 24, 2015 The Geek Decoder No Comments Administration, Networking

Server connections speeds are a function of a variety of variables. The server’s connection speed to the Internet, all processes that are simultaneously trying to connect (uploads and downloads share the total speed available), the overall health of the Internet and the connection capability of the off-site computer, which is also limited by the same factors.
Linux

You can test the download speed of a Linux server by downloading a very large file and watching the speed.

# cd /tmp

500 MB

# wget --output-document=/dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip

or

# wget --output-document=/dev/null http://cachefly.cachefly.net/100mb.test

Windows

http://speedtest.net

filesystem checks and settings on CentOS

April 4, 2015 The Geek Decoder No Comments Administration

Normally on CentOS the file system check is in the fstab file.

If all you want to do is avoid an fsck, adding the -f option to shutdown should help with that. 

[bash]

# shutdown -f

[/bash]

The other option is you can manually make it skip fsck checks at boot by updating the 6th field in your /etc/fstab:


# /dev/sda2  /  ext3  defaults,errors=remount-ro 0       1

This is the similar to what most fstabs will have 1 means that it should be checked and is a root file system, 2 means it should be checked but will be done in parallel with other file systems and 0 means skip checking

Other ways to configure and check the settings:

On CentOS, edit /etc/sysconfig/autofsck (or create it if it doesn’t exist) with the following content.


# sudo vi /etc/sysconfig/autofsck
AUTOFSCK_DEF_CHECK=yes

If the filesystem is large, you can force filesystem checks on a regular basis, instead of every boot time. In order to do so, first find out the filesystem configuration with tune2fs command. The following command line shows the current values of filesystem related parameters. Note that /dev/sda1 is the partition where the filesystem superblock is located.


# sudo tune2fs -l /dev/sda1 


Disk identifier: 0x00000000

[root@cloud1 log]# tune2fs -l /dev/sda1
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /boot
Filesystem UUID:          3f3d720d-781c-402f-8599-94a97f7a824f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              128016
Block count:              512000
Reserved block count:     25600
Free blocks:              394486
Free inodes:              127963
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2032
Inode blocks per group:   254
Flex block group size:    16
Filesystem created:       Fri Jan 23 19:06:50 2015
Last mount time:          Sun Mar 29 12:10:18 2015
Last write time:          Sun Mar 29 12:10:18 2015
Mount count:              8
Maximum mount count:      -1
Last checked:             Fri Jan 23 19:06:50 2015
Check interval:           0 (<none>)
Lifetime writes:          108 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      ea055f98-4239-40e2-a8a7-0dae21287819
Journal backup:           inode blocks

From tune2fs output, you can see not only the filesystem state (clean or not), but also parameters that are related to filesystem checks. “Maximum mount count” parameter is the number of mounts after which the filesystem check gets triggered. “Check interval” parameter shows the maximum time between two filesystem checks. On most Linux distros, these parameters are not set by default, meaning no regular filesystem checks are occurring.

To force filesystem check for every 30 mounts, run the following command.


# sudo tune2fs -c 30 /dev/sda1

To force filesystem check for every 3 months, use the command below.


# sudo tune2fs -i 3m /dev/sda1

Now verify that newly added filesystem check conditions are set properly.


#sudo tune2fs -l /dev/sda1



. . .
Last mount time:          n/a
Last write time:          Fri Mar 14 22:29:24 2014
Mount count:              20
Maximum mount count:      30
Last checked:             Mon Mar  3 20:55:08 2014
Check interval:           7776000 (3 months)
Next check after:         Sun Jun  1 21:55:08 2014

Force One-Time Filesystem Check on the Next Reboot

If you want to trigger one-time filesystem check on your next reboot, you can use this command.


# sudo touch /forcefsck

Once you create an empty file named forcefsck in the top directory (/) like above, it will force filesystem check the next time you boot up. After successful booting, /forcefsck will automatically be removed.

Install rkhunter on CentOS 6.6

March 3, 2015 The Geek Decoder No Comments Administration, RKHunter, Security

Rootkit Hunter (rkhunter) is a Unix-based tool that scans for rootkits, backdoors and possible local exploits. Rootkits are self-hiding toolkits secretly installed by a malicious intruder to allow that user to gain access to the server. Rootkit Hunter offers protection by comparing SHA-1 hashes of important files with known good ones in a online database as well as:

MD5 hash compare
Look for default files used by rootkits
Wrong file permissions for binaries
Look for suspected strings in LKM and KLD modules
Look for hidden files
Optional scan within plaintext and binary files

yum install rkhunter

Check the version

# rkhunter --versioncheck
Rootkit Hunter version 1.4.2

Checking rkhunter version...
  This version  : 1.4.2
  Latest version: 1.4.2

Manual Scan

# rkhunter -c

Or,

# rkhunter -c -l /var/log/rkhunter.log

Automate Rootkit Hunter

Rkhunter can be setup to run checks every day so that we always have up-to-date information about intrusions. This can be accomplished by creating a cronjob.
2.1 Create Cron File

Create the run-file in the following location (RHEL based distributions only):

#nano -w /etc/cron.daily/rkhunter.sh

Install into shell script

#!/bin/sh
(
/usr/bin/rkhunter --versioncheck
/usr/bin/rkhunter --update
/usr/bin/rkhunter --cronjob --report-warnings-only
) | /bin/mail -s 'rkhunter Daily Scan Report (ServerNameHere)' your@email.here

Set Execute Permissions

Set execute permission on the file you have just created:

# chmod 755 /etc/cron.daily/rkhunter.sh

The cron utility will run once daily, and if a threat is detected, the rkhunter command itself will email our user to alert them. If no problems were found, no email will be received.

Rootkit Hunter configuration

The configuration file for rkhunter can be found at:

# /etc/rkhunter.conf

SSHD Root Logon

The parameter ALLOW_SSH_ROOT_USER tells rkhunter whether or not the root user is allowed to ssh into the system. This is unset by default in the rkhunter.conf file. Rkhunter will complain about this on every run. If you have disabled root login, you should set this parameter to “no”.

ALLOW_SSH_ROOT_USER=no

If you need root login over SSH, you should change this parameter to “yes” so that rkhunter can check this and will mark this setting as valid:

ALLOW_SSH_ROOT_USER=yes

Security practices recommend disabling root login.

Update rkhunter

To check the currently installed version enter the following:

# rkhunter --versioncheck

Run the updater by issuing the following command:

# rkhunter --update

With our database files refreshed, we need to tell rkhunter to check the current values and store them as known-good values:

# rkhunter --propupd