Pages

Saturday, September 21, 2013

Add more space to /tmp in cPanel server.

The following could help you to increase more space in /tmp.

You need to make alternation in the file /scripts/securetmp

#vi /scripts/securetmp

Find the entry my $tmpdsksize under Global Variables as follows:
# Global Variables
my $tmpdsksize = 512000; # Must be larger than 250000

Change the value for that particular entry to desired size.

Then make sure that no processes are using /tmp using the command, lsof /tmp

Please stop the service /etc/init.d/mysql stop. Also delete the file, /usr/tmpDSK if it exists by rm -rf /usr/tmpDSK

Then

umount /tmp

Run the script

#/scripts/securetmp

Then you will asked for some confirmation steps.

“Would you like to secure /tmp at boot time?” Press y

“Would you like to secure /tmp now?” Press y

Eventually you can see the upgraded space to /tmp in server :)

 

//////////////////////////////////////////////

1.) Stop MySql service and process kill the tailwatchd process.

[root@server ~]# /etc/init.d/mysqld stop
Stopping MySQL: [ OK ]
[root@server ~]# pstree -p | grep tailwatchd
Find the tailwatchd process id and kill it
[root@server ~]# kill -9 2522
2.) Take a backup of /tmp as /tmp.bak

[root@server ~]#cp -prf /tmp /tmp.bak
3.) Create a 2GB file in the avaliable freespace

[root@server ~]# dd if=/dev/zero of=/usr/tmpDSK bs=1024k count=2048
2048Ʈ records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 73.6908 seconds, 29.1 MB/s
[root@server~]# du -sch /usr/tmpDSK
2.1G /usr/tmpDSK
2.1G total
4.) Assign ext3 filesystem to the file

[root@server~]# mkfs -t ext3 /usr/tmpDSK
mke2fs 1.39 (29-May񮖦)
/usr/tmpDSK is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
262144 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=0
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
5.) Check the file system type:-

[root@server ~]# file /usr/tmpDSK
/usr/tmpDSK: Linux rev 1.0 ext3 filesystem data (large files)
Note:-

You may also use the following comands for making ext3 file system on a file:

[root@server ~]# mkfs.ext3 /usr/tmpDSK
[root@server ~]# mke2fs /usr/tmpDSK
6.) Unmount /tmp partition

[root@server ~]# umount /tmp
7.) Mount the new /tmp filesystem with noexec

[root@server ~]# mount -o loop,noexec,nosuid,rw /usr/tmpDSK /tmp
8.) Set the correct permission for /tmp

[root@server ~]# install -d –mode=1777 /tmp
[root@antg ~]# ls -ld /tmp
drwxrwxrwt 3 root root 4096 Feb 6 08:42 /tmp
( you may use the command chmod 1777 /tmp for doing the same )

[root@server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda9 28G 6.4G 20G 25% /
/dev/sda8 99M 10M 84M 11% /boot
tmpfs 500M 0 500M 0% /dev/shm
/usr/tmpDSK 2.0G 68M 1.9G 4% /tmp
9.)Restore the content of old /tmp.bkp directory

[root@server ~]# cp -rpf /tmp.bak/* /tmp
10.) Restart the mysql and tailwathchd services.

[root@server ~]# /etc/init.d/mysql start
[root@server ~]# /scripts/restartsrv_tailwatchd
11.)Edit the fstab and replace /tmp entry line with :-

/usr/tmpDSK /tmp ext3 loop,noexec,nosuid,rw 0 0
12.) Mount all filesystems

[root@server~]# mount -a
Check it now:-

[root@server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda9 28G 6.4G 20G 25% /
/dev/sda8 ɃM 10M 84M 11% /boot
tmpfs 500M 0 500M 0% /dev/shm
/usr/tmpDSK 2.0G 68M 1.9G 4% /tmp

really hope this little tutoral can help you:)

 

 

Wednesday, September 18, 2013

How to monitor file access on Linux with "auditd"

For critical servers and sensitive data, keeping an eye on who accesses or changes files is essential for security. The Linux Audit System, with its auditd daemon, helps you do just that. It monitors system calls and logs them, providing a detailed trail of file activity.


INSTALLING AUDITD

auditd is available in the package repositories for most Linux distributions.

  • Debian, Ubuntu, Linux Mint:

    sudo apt-get install auditd

    On these systems, auditd usually starts automatically on boot after installation.

  • Fedora, CentOS, RHEL:

    sudo yum install audit

    To ensure auditd starts automatically on boot for these distributions:

    sudo chkconfig auditd on

CONFIGURING AUDITD

You can configure auditd using the auditctl command-line utility or by editing its configuration file, /etc/audit/audit.rules. This guide focuses on editing the configuration file.

  • Edit the Configuration File:

    sudo vi /etc/audit/audit.rules
  • Example Configuration (/etc/audit/audit.rules):

    # First rule - delete all existing rules
    -D
    
    # Increase buffer size for busy systems to prevent lost events
    -b 1024
    
    # Monitor when files or directories are deleted (unlink and rmdir system calls)
    -a exit,always -S unlink -S rmdir
    
    # Monitor file open attempts by a specific Linux User ID (UID 1001)
    -a exit,always -S open -F loginuid=1001
    
    # Monitor write-access and changes to file properties (permissions) for critical files
    -w /etc/group -p wa
    -w /etc/passwd -p wa
    -w /etc/shadow -p wa
    -w /etc/sudoers -p wa
    
    # Monitor read-access to a specific sensitive directory
    -w /etc/secret_directory -p r
    
    # Lock the audit configuration to prevent unauthorized modifications until reboot
    -e 2
    
    • -D: Clears all previous rules.

    • -b 1024: Sets the buffer size. Increase this for active systems to avoid missing events.

    • -a exit,always -S <syscall>: Monitors specific system calls.

    • -F loginuid=<UID>: Filters events by the user ID logged in.

    • -w <path> -p <permissions>: Sets a watch on a file or directory.

      • w: write access

      • a: attribute change (e.g., permissions)

      • r: read access

    • -e 2: Puts auditd into immutable mode, preventing rule changes until reboot.

  • Restart Auditd: After making changes to /etc/audit/audit.rules, restart the service for them to take effect.

    sudo service auditd restart

ANALYZING AUDIT LOGS

auditd logs its findings to /var/log/audit/audit.log. The ausearch command-line tool is used to query these logs.

  • Check File Access: To see if /etc/passwd has been accessed or modified:

    sudo ausearch -f /etc/passwd

    The output will show details like the time, type of event, user, process, and system call involved. For example, you might see an entry indicating chmod was applied to /etc/passwd by root.

  • Check Directory Access: To see if /etc/secret_directory has been accessed:

    sudo ausearch -f /etc/secret_directory

    This will show events like ls commands being run within that directory by a specific UID.


IMMUTABLE MODE AND RULE MODIFICATION

If you set auditd to immutable mode (-e 2), you cannot modify the rules and restart the service without a reboot.

  • Error Message in Immutable Mode:

    Error deleting rule (Operation not permitted)
    The audit system is in immutable mode, no rules loaded
    
  • To Modify Rules in Immutable Mode:

    1. Edit /etc/audit/audit.rules.

    2. Reboot your machine. The new rules will be loaded upon restart.


LOG ROTATION

Audit logs can grow large quickly. It's recommended to enable daily log rotation.

  • Rotate Audit Logs Daily (for cronjob):

    sudo service auditd rotate

    You can add this command to a daily cron job to ensure logs are rotated regularly, preventing the /var/log/audit directory from filling up.

Wednesday, September 4, 2013

Resetting Your SSH Port Through WHM

Your SSH (Secure Shell) port is like a specific door on your server that allows secure remote access. Sometimes, you might need to change or reset it, for example, after a security configuration change or to resolve connection issues.


WHY RESET YOUR SSH PORT?

  • Security: If you've made changes to your SSH configuration (like changing the default port), resetting the service ensures those changes take effect.

  • Troubleshooting: Sometimes, a simple restart can resolve minor connection glitches.


HOW TO RESET YOUR SSH PORT VIA WHM

This process leverages WHM's built-in tools to safely restart the SSH service.

  1. Log in to WHM:

    • Open your web browser.

    • Go to http://your_server_ip:2086 (replace your_server_ip with your server's actual IP address).

    • Enter your WHM username and password.

  2. Access the SSH Reset Tool:

    • Once logged into WHM, browse directly to the following URL: http://your_server_ip:2086/scripts2/doautofixer?autofix=safesshrestart

    • Make sure to replace your_server_ip with your server's actual IP address.

  3. Confirmation:

    • After navigating to the URL, WHM will attempt to safely restart the SSH service.

    • You should see a message indicating the status of the operation, usually confirming that the SSH service has been restarted or reloaded.


IMPORTANT CONSIDERATIONS

  • Server IP: Always ensure you replace your_server_ip with the correct IP address of your server.

  • WHM Access: You need administrative access to WHM to perform this action.

  • SSH Configuration: This process primarily restarts the SSH service to apply existing configuration changes. It does not change the SSH port itself. To change the SSH port, you would typically edit the sshd_config file and then use this method to restart the service.

SSH - Securing

SSH (Secure Shell) is a powerful tool for remote access, but like any door to your system, it needs to be properly secured. This guide explains key configurations to make your SSH server more robust and protect against common threats.


UPGRADING TO SSHV2 FOR BETTER SECURITY

SSH comes in two main versions: SSH1 and SSH2. SSH2 is the more modern and secure choice, offering better encryption and protection against vulnerabilities. Always aim to use SSH2.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. 

Find the line Protocol and ensure it's set to: Protocol 2


TRACKING ACTIVITY WITH VERBOSE LOGGING

Knowing who logs in and out of your system is crucial for security. Verbose logging provides detailed records, which are invaluable if you ever need to investigate a security incident.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. 

Find the line LogLevel and set it to: LogLevel VERBOSE


DISABLING X11 FORWARDING (IF NOT NEEDED)

X11 Forwarding allows you to run graphical applications remotely over SSH. While convenient, it can also create security risks. If you don't need graphical access, it's safer to disable it.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line X11Forwarding and set it to: X11Forwarding no


LIMITING LOGIN ATTEMPTS (MAXAUTHTRIES)

To protect against "brute force" attacks, where attackers try many passwords, you can limit the number of times someone can attempt to log in. This significantly reduces the chances of a successful attack.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line MaxAuthTries and set it to a low number, such as: MaxAuthTries 4


IGNORING OLD AUTHENTICATION FILES (IGNORERHOSTS)

Older systems sometimes used .rhosts or .shosts files for authentication. These methods are less secure. Disabling them forces users to rely on more secure password or key-based authentication.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line IgnoreRhosts and set it to: IgnoreRhosts yes


DISABLING HOST-BASED AUTHENTICATION

Host-based authentication is another older method that can be risky. Disabling it ensures that SSH relies on more secure public key or password-based authentication.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line HostbasedAuthentication and set it to: HostbasedAuthentication no


PREVENTING DIRECT ROOT LOGIN (PERMITROOTLOGIN)

Logging in directly as the 'root' user (the super-administrator) is generally discouraged. Instead, log in with a regular user account and then use tools like sudo or su to gain root privileges. This creates a clearer audit trail and enhances security.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line PermitRootLogin and set it to: PermitRootLogin no


BLOCKING EMPTY PASSWORDS (PERMITEMPTYPASSWORDS)

Accounts without passwords are a massive security risk. Ensure your SSH server is configured to prevent anyone from logging in with an empty password.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line PermitEmptyPasswords and set it to: PermitEmptyPasswords no


LIMITING USER ENVIRONMENT SETTINGS (PERMITUSERENVIRONMENT)

Allowing users to set certain environment variables through SSH could potentially be misused to bypass security. It's safer to disable this feature.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Find the line PermitUserEnvironment and set it to: PermitUserEnvironment no


USING STRONG ENCRYPTION (CIPHERS)

Ciphers are the algorithms that encrypt your SSH communication. Using strong, modern ciphers like aes128-ctr, aes192-ctr, and aes256-ctr helps protect against eavesdropping and "man-in-the-middle" attacks.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. 

Find the line Ciphers and set it to: Ciphers aes128-ctr,aes192-ctr,aes256-ctr


SETTING IDLE SESSION TIMEOUTS

Leaving SSH sessions open indefinitely can be a security risk. Setting a timeout automatically disconnects idle sessions, preventing unauthorized access if a workstation is left unattended.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. 

Find the lines ClientAliveInterval and ClientAliveCountMax and 

set them to: ClientAliveInterval 300 (5 minutes) ClientAliveCountMax 0 (disconnect after interval without response)


RESTRICTING ACCESS TO SPECIFIC USERS AND GROUPS

You can precisely control who can access your system via SSH. This is a critical security measure to limit potential entry points.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. Use one or more of these parameters:

  • AllowUsers <username1> <username2> (only specified users can log in)

  • AllowGroups <groupname1> <groupname2> (only users in specified groups can log in)

  • DenyUsers <username1> <username2> (specified users cannot log in)

  • DenyGroups <groupname1> <groupname2> (users in specified groups cannot log in)


DISPLAYING A LOGIN BANNER

A login banner displays a message to users before they authenticate. This can be used to provide legal notices or warnings.

HOW TO CONFIGURE: Edit the /etc/ssh/sshd_config file. 

Create a text file (e.g., /etc/issue.net) with your desired message. Set the Banner parameter to the path of your banner file: Banner /etc/issue.net


SECURING SSH CONFIGURATION FILE PERMISSIONS

The sshd_config file contains sensitive settings, so it must be protected. Only the root user should own it, and it should only be writable by root.

HOW TO CONFIGURE: From the command line, 

run: 

# chown root:root /etc/ssh/sshd_config 

# chmod 644 /etc/ssh/sshd_config

Tuesday, September 3, 2013

No apache MPM package installed - debian/ubuntu

Guide to Reinstalling Apache2 with PHP5 Support

If you're working on a legacy server or application that requires Apache2 with the mpm-prefork module and PHP5, the following sequence of commands and their purposes can help you manage the installation and configuration process. This workflow is common when troubleshooting or restoring old PHP5-based web applications.

1. Purge and Reinstall Apache2 MPM Prefork

bash
apt-get purge apache2-mpm-prefork apt-get install apache2-mpm-prefork
  • Purpose: Removes the current installation of the apache2-mpm-prefork module and reinstalls it. This is sometimes necessary if the module is corrupted or if you need to reset its configuration. On Debian-based systems, only one MPM (Multi-Processing Module) can be active at a time.

2. Stop Nginx and Start Apache2

bash
/etc/init.d/nginx stop service apache2 start
  • Purpose: Stops the Nginx service to avoid port conflicts (usually on port 80), then starts the Apache2 service. This is essential if both web servers are installed on the same machine, as they cannot both bind to the same port simultaneously.

3. Restore PHP5 Module Configurations

bash
cp -arp /root/apache2/mods-available/php5* /etc/apache2/mods-available/ cp -arp /root/apache2/mods-enabled/php5* /etc/apache2/mods-enabled/
  • Purpose: Copies backup PHP5 module configuration files back to their respective directories. This is often required if these files were lost or overwritten during package changes or upgrades. The mods-available directory contains all available modules, while mods-enabled contains symlinks to the modules currently enabled for Apache.

4. Restart Apache2

bash
service apache2 start
  • Purpose: Ensures Apache2 is running with the new or restored module configurations. Use this after restoring module files to apply changes.

5. Install PHP5 Apache Module

bash
apt-get install libapache2-mod-php5
  • Purpose: Installs the PHP5 module for Apache2, allowing Apache to interpret PHP scripts. Note that on modern systems, this package is obsolete and may not be available in default repositories. For Ubuntu 16.04 and later, PHP7 is the default, and you may need to use a third-party PPA to install PHP5.