Tuesday, 10 June 2014

Enable Telnet and FTP Services for Root user

Enabling Telnet and FTP Services
Linux is configured to run the Telnet and FTP server, but by default, these services are not enabled. To enable the telnet these service, login to the server as the root userid and edit the files:
In this file, find the line for disable and change it from the value "yes" to "no".
After changing the above value(s), you will need to restart the xinetd deamon. As the root userid, type the following command:
  % /etc/init.d/xinetd reload
Starting with the Fedora Core 1 release, the FTP server (wu-ftpd) is no longer available with xinetd. It has been replaced with vsftp and can be started from /etc/init.d/vsftpd as in the following:
# /etc/init.d/vsftpd start
If you want the vsftpd service to start and stop when recycling the machine, you can create the following symbolic links:
# ln -s /etc/init.d/vsftpd /etc/rc3.d/S56vsftpd
# ln -s /etc/init.d/vsftpd /etc/rc4.d/S56vsftpd
# ln -s /etc/init.d/vsftpd /etc/rc5.d/S56vsftpd
Allowing Root Logins to Telnet and FTP Services Now before getting into the details of how to configure Red Hat Linux for root logins, keep in mind that this is VERY BAD security. Make sure that you NEVER configure your production servers for this type of login. Configure Telnet for root logins
Simply edit the file /etc/securetty and add the following to the end of the file:
pts/0
pts/1
pts/2
pts/3
pts/4
pts/5
pts/6
pts/7
pts/8
pts/9
This will allow up to 10 telnet sessions to the server as root.

Thursday, 17 April 2014

OpenSSL CVE-2014-0160 Heartbleed bug and Red Hat Enterprise Linux

OpenSSL CVE-2014-0160 Heartbleed bug and Red Hat Enterprise Linux

Issue

  • Does CVE-2014-0160 affect Red Hat Enterprise Linux?
  • Need fix for openssl heartbleed bug
  • What versions of Red Hat Enterprise Linux are affected by openssl heartbleed vulnerability?
  • Do we have a list of packages/services we ship with RHEL that need a restart after OpenSSL has been updated?

Environment

  • Red Hat Enterprise Linux 7 Release Candidate (RC) not affected
  • Red Hat Enterprise Linux 7 Beta affected
  • Red Hat Enterprise Linux 6 affected
  • Red Hat Enterprise Linux 5 not affected
  • Red Hat Enterprise Linux 4 not affected
  • For other affected products, refer to https://access.redhat.com/site/announcements/781953

Resolution

Step 1: Determine if RHEL system is vulnerable to flaw described in CVE-2014-0160

  • Red Hat Enterprise Linux 7 Release Candidate (RC)
    • Red Hat Enterprise Linux 7 RC include OpenSSL version openssl-1.0.1e-34.el7 which includes a fix backported from openssl-1.0.1g
  • Red Hat Enterprise Linux 7 Beta
    • OpenSSL versions openssl-1.0.1e-33.el7 and earlier include a flawed libssl.so library vulnerable to the issue
    • To determine openssl version, use the command: rpm -q openssl
    • Version openssl-1.0.1e-34.el7 included a fix backported from openssl-1.0.1g
    • See footnote for considerations specific to RHEL 7 Beta1
  • Red Hat Enterprise Linux 6
    • OpenSSL versions openssl-1.0.1e-15 through openssl-1.0.1e-16.el6_5.4 include a flawed libssl.so library vulnerable to the issue
    • The first affected version shipped with RHEL 6.5 (RHEL 6.4 and older shipped with the unaffected openssl-1.0.0 series)
      • Systems which report as RHEL 6.0 - 6.3 could still have been updated to a newer [vulnerable] openssl-1.0.1 series package
    • To determine openssl version, use the command: rpm -q openssl
    • Version openssl-1.0.1e-16.el6_5.7 included a fix backported from openssl-1.0.1g
  • Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 4
    • Vulnerable OpenSSL 1.0.1 series versions never shipped in RHEL 5 or earlier

Optional Step 2: Look for and/or query processes which are using the vulnerable libssl library


Step 3: Upgrade the openssl package

  • Red Hat Enterprise Linux 7 Beta
    • Update to openssl-1.0.1e-34.el7 (which corrected the flaw) or later
  • Red Hat Enterprise Linux 6
    • Update to openssl-1.0.1e-16.el6_5.7 (which corrected the flaw, as described in RHSA-2014:0376) or later
  • As always, registered systems with internet access (or any RHEL 7 Beta system, or systems connected to Satellites, etc) can be updated via yum, e.g.:
    • yum update openssl
  • Otherwise, use a connected system to download the package or download the package directly from the Customer Portal2
    • After that, transfer the package to the system in question and install it manually with yum, e.g.:
      • yum update <path-to-openssl*rpm>

Step 4: After updating openssl, restart all processes using the flawed libssl.so3

  • The safest & simplest thing to do: perform a system reboot
  • Alternatively: use the commands from Optional Step 2 to determine which processes need to be restarted and then act accordingly

Optional Step 5: Re-scan updated systems with one of the Heartbleed Detector tools


Optional Step 6: Take additional remediation steps as desired

  • Official statement from Red Hat Security Response Team:
    Red Hat is not aware of any public exploit being used in the wild for this issue prior to the date of disclosure. However, a number of public exploits were published shortly after the issue was disclosed.4 These exploits could lead to the disclosure of information handled by applications using OpenSSL, including private keys, session tokens, and data submitted by users, which could include authentication credentials. It is recommended that you assess the risk this could pose to your systems, and perform additional remediation as you deem appropriate.

Root Cause

  • Official statement from Security Advisory RHSA-2014:0376:
    An information disclosure flaw was found in the way OpenSSL handled TLS and
    DTLS Heartbeat Extension packets. A malicious TLS or DTLS client or server
    could send a specially crafted TLS or DTLS Heartbeat packet to disclose a
    limited portion of memory per request from a connected client or server.
    Note that the disclosed portions of memory could potentially include
    sensitive information such as private keys. (CVE-2014-0160)
  • For links to more detail, see the entry for CVE-2014-0160 in Red Hat's CVE Database

Thursday, 10 April 2014

Linux Boot Process

Press the power button on your system, and after few moments you see the Linux login prompt.

Have you ever wondered what happens behind the scenes from the time you press the power button until the Linux login prompt appears?

The following are the 6 high level stages of a typical Linux boot process.


1. BIOS

  • BIOS stands for Basic Input/Output System
  • Performs some system integrity checks
  • Searches, loads, and executes the boot loader program.
  • It looks for boot loader in floppy, cd-rom, or hard drive. You can press a key (typically F12 of F2, but it depends on your system) during the BIOS startup to change the boot sequence.
  • Once the boot loader program is detected and loaded into the memory, BIOS gives the control to it.
  • So, in simple terms BIOS loads and executes the MBR boot loader.

2. MBR

  • MBR stands for Master Boot Record.
  • It is located in the 1st sector of the bootable disk. Typically /dev/hda, or /dev/sda
  • MBR is less than 512 bytes in size. This has three components 1) primary boot loader info in 1st 446 bytes 2) partition table info in next 64 bytes 3) mbr validation check in last 2 bytes.
  • It contains information about GRUB (or LILO in old systems).
  • So, in simple terms MBR loads and executes the GRUB boot loader.

3. GRUB

  • GRUB stands for Grand Unified Bootloader.
  • If you have multiple kernel images installed on your system, you can choose which one to be executed.
  • GRUB displays a splash screen, waits for few seconds, if you don’t enter anything, it loads the default kernel image as specified in the grub configuration file.
  • GRUB has the knowledge of the filesystem (the older Linux loader LILO didn’t understand filesystem).
  • Grub configuration file is /boot/grub/grub.conf (/etc/grub.conf is a link to this). The following is sample grub.conf of CentOS.

    #boot=/dev/sda
    default=0
    timeout=5
    splashimage=(hd0,0)/boot/grub/splash.xpm.gz
    hiddenmenu
    title CentOS (2.6.18-194.el5PAE)
              root (hd0,0)
              kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
              initrd /boot/initrd-2.6.18-194.el5PAE.img
     
  • As you notice from the above info, it contains kernel and initrd image.
  • So, in simple terms GRUB just loads and executes Kernel and initrd images.

4. Kernel

  • Mounts the root file system as specified in the “root=” in grub.conf
  • Kernel executes the /sbin/init program
  • Since init was the 1st program to be executed by Linux Kernel, it has the process id (PID) of 1. Do a ‘ps -ef | grep init’ and check the pid.
  • initrd stands for Initial RAM Disk.
  • initrd is used by kernel as temporary root file system until kernel is booted and the real root file system is mounted. It also contains necessary drivers compiled inside, which helps it to access the hard drive partitions, and other hardware.

5. Init

  • Looks at the /etc/inittab file to decide the Linux run level.
  • Following are the available run levels
    • 0 – halt
    • 1 – Single user mode
    • 2 – Multiuser, without NFS
    • 3 – Full multiuser mode
    • 4 – unused
    • 5 – X11
    • 6 – reboot
  • Init identifies the default initlevel from /etc/inittab and uses that to load all appropriate program.
  • Execute ‘grep initdefault /etc/inittab’ on your system to identify the default run level
  • If you want to get into trouble, you can set the default run level to 0 or 6. Since you know what 0 and 6 means, probably you might not do that.
  • Typically you would set the default run level to either 3 or 5.

6. Runlevel programs

  • When the Linux system is booting up, you might see various services getting started. For example, it might say “starting sendmail …. OK”. Those are the runlevel programs, executed from the run level directory as defined by your run level.
  • Depending on your default init level setting, the system will execute the programs from one of the following directories.
    • Run level 0 – /etc/rc.d/rc0.d/
    • Run level 1 – /etc/rc.d/rc1.d/
    • Run level 2 – /etc/rc.d/rc2.d/
    • Run level 3 – /etc/rc.d/rc3.d/
    • Run level 4 – /etc/rc.d/rc4.d/
    • Run level 5 – /etc/rc.d/rc5.d/
    • Run level 6 – /etc/rc.d/rc6.d/
  • Please note that there are also symbolic links available for these directory under /etc directly. So, /etc/rc0.d is linked to /etc/rc.d/rc0.d.
  • Under the /etc/rc.d/rc*.d/ directories, you would see programs that start with S and K.
  • Programs starts with S are used during startup. S for startup.
  • Programs starts with K are used during shutdown. K for kill.
  • There are numbers right next to S and K in the program names. Those are the sequence number in which the programs should be started or killed.
  • For example, S12syslog is to start the syslog deamon, which has the sequence number of 12. S80sendmail is to start the sendmail daemon, which has the sequence number of 80. So, syslog program will be started before sendmail.
There you have it. That is what happens during the Linux boot process.

Wednesday, 2 April 2014

Unlock Linux accounts which are locked by PAM_tally2

pam_tally2 module is used to lock user accounts after certain number of failed ssh login attempts made to the system. This module keeps the count of attempted accesses and too many failed attempts.

pam_tally2 module comes in two parts, one is pam_tally2.so and another is pam_tally2. It is based on PAM module and can be used to examine and manipulate the counter file. It can display user login attempts counts, set counts on individual basis, unlock all user counts.


By default, pam_tally2 module is already installed on the most of the Linux distributions and it is controlled by PAM package itself. This article demonstrates on how to lock and unlock SSH accounts after reaching a certain failed number of login attempts.


How to Lock and Unlock User Accounts

Use ‘/etc/pam.d/password-auth‘ configuration file to configure login attempts accesses.
Open this file and add the following AUTH configuration line to it at beginning of the ‘auth‘ section.
 
auth        required      pam_tally2.so  file=/var/log/tallylog deny=3 even_deny_root unlock_time=1200

Next, add the following line to ‘account‘ section.
 
account     required      pam_tally2.so
Parameters
  1. file=/var/log/tallylog – Default log file is used to keep login counts.
  2. deny=3 – Deny access after 3 attempts and lock down user.
  3. even_deny_root – Policy is also apply to root user.
  4. unlock_time=1200 – Account will be locked till 20 Min. (remove this parameters if you want to lock down permanently till manually unlock.)
Once you’ve done with above configuration, now try to attempt 3 failed login attempts to server using any ‘username‘. After you made more than 3 attempts you will get the following message.
 
[root@tecmint ~]# ssh tecmint@172.16.25.126
tecmint@172.16.25.126's password:
Permission denied, please try again.
tecmint@172.16.25.126's password:
Permission denied, please try again.
tecmint@172.16.25.126's password:
Account locked due to 4 failed logins
Account locked due to 5 failed logins
Last login: Mon Apr 22 21:21:06 2013 from 172.16.16.52

Now, verify or check the counter that user attempts with the following command.
[root@tecmint ~]# pam_tally2 --user=tecmint
Login           Failures  Latest    failure     From
tecmint              5    04/22/13  21:22:37    172.16.16.52

How to reset or unlock the user account to enable access again.
 
[root@tecmint pam.d]# pam_tally2 --user=tecmint --reset
Login           Failures  Latest    failure     From
tecmint             5     04/22/13  17:10:42    172.16.16.52

Verify login attempt is reset or unlocked
 
[root@tecmint pam.d]# pam_tally2 --user=tecmint
Login           Failures   Latest   failure     From
tecmint            0

The PAM module is part of all Linux distribution and configuration provided about should work on all Linux distribution. Do ‘man pam_tally2‘ from the command line to know more about it.

Wednesday, 26 February 2014

Red Hat Linux Static Routing Configuration

Red Hat Linux Static Routing Configuration



I've two network interface connected to two different routers as follows:
 
[a] eth0 LAN network 10.0.0.0/8 - gateway IP - 10.8.2.65
[b] eth1 ISP assigned network 202.54.22.128/28 - gateway IP - 202.54.22.129

I can only ping to public server but not to another servers inside LAN? I'm not able to route traffic via 10.8.2.65. How do I configure static routing under Red Hat Enterprise Linux 5.x or CentOS Linux 5.2?

A. Under Red Hat you need to define static routing using route command. The configuration is stored under /etc/sysconfig/network-scripts/route-eth0 for eth0 interface.

Update route using route command

Type the following command:
# route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.8.2.65 eth0
# route -n

Create static routing file

The drawback of abive 'route' command is that, when RHEL reboots it will forget static routes. So store them in configuration file:

echo '10.0.0.0/8 via 10.8.2.65' >> /etc/sysconfig/network-scripts/route-eth0

Restart networking:
 
# service network restart

Verify new changes:
 
# route -n
# ping 10.8.2.65
# ping 10.8.2.10
# ping google.com
# traceroute google.com
# traceroute 10.8.2.10

Further readings:

  • man pages ip, route command

Wednesday, 12 February 2014

Configuring rsyslog

Configuring rsyslog on the Centralized Logging Server

The steps in this procedure must be followed on the system that you intend to use as your centralized logging sever. All steps in this procedure must be run while logged in as the root user.
  1. Configure SELinux to allow rsyslog traffic.
    # semanage -a -t syslogd_port_t -p udp 514
  2. Configure the iptables firewall to allow rsyslog traffic.
    1. Open the /etc/sysconfig/iptables file in a text editor.
    2. Add an INPUT rule allowing UDP traffic on port 514 to the file. The new rule must appear before any INPUT rules that REJECT traffic.
      -A INPUT -m state --state NEW -m udp -p udp --dport 514 -j ACCEPT
    3. Save the changes to the /etc/sysconfig/iptables file.
    4. Restart the iptables service for the firewall changes to take effect.
      # service iptables restart
  3. Open the /etc/rsyslog.conf file in a text editor.
    1. Add this line to the file, defining the location logs will be saved to:
      $template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
      
      authpriv.*   ?TmplAuth
      *.info,mail.none,authpriv.none,cron.none   ?TmplMsg
    2. Remove the comment character (#) from the beginning of these lines in the file:
      #$ModLoad imudp
      #$UDPServerRun 514
    Save the changes to the /etc/rsyslog.conf file.
Your centralized log server is now configured to receive and store log files from the other systems in your environment.

Setup Rsyslog

How to Setup Rsyslog Remote Logging on Linux (Central Log Server)

by Lakshmanan Ganapathy on January 25, 2012
Every Linux distribution have some kind of logging mechanism that records all the system activities. A while back we provided a list of 20 log files that are stored under /var/log that you might be helpful during troubleshooting. These logs are very critical for sysadmin for troubleshooting purpose.
The following are the three common methods to log a message:
  1. Logging on the same server: Messages get written into the local hard drive/local database
  2. Logging on a remote server: Many systems forward their logs over the network to a central log server. On the central log server, the messages from various systems are written to the local hard drive/database.
  3. Relay logging: Branch ‘A’ and Branch ‘B’ logs the messages on 2 different servers. These server in-turn logs the message to the ‘Head Office’.

Rsyslog is the default logging program on several Linux distributions including Debian and Red Hat based systems. Apart from implementing the syslog protocol, rsyslog adds additional features such as content-based filtering. This also uses TCP for transporting, and provides lot of configuration options.
This article explains how to implement the method 2 mentioned above. i.e This explains how to setup a central logging server, and send logs from individual servers to the central logging server.
This setup will help you to analyze the log files of all the servers in your infrastructure from a central log server.

Installation

Rsyslog comes as the default logging program in Debian Distribution and Red Hat based systems. If you system doesn’t have rsyslog, install it as shown below depending on your distro.
apt-get install rsyslog rsyslog-doc
(or)
yum install rsyslog rsyslog-doc
Rsyslog configurations are stored in /etc/ryslog.conf file and the files under /etc/rsyslog.d/ directory.

Configuration Structure

Before understanding how to setup the central logging sever, it is good to understand the configuration structure of rsyslog.
Rsyslog configuration files are structed in the following manner
  1. Modules
  2. Configuration Directives
  3. Rule line

Modules

Rsyslog has a modular architecture. It enables functionalities to be added dynamically through these modules. The modules are categorized as:
  • Input Modules – Used to gather messages from various sources
  • Output Modules – Used to write the messages to various places ( file, socket etc.. )
  • Parser Modules – Used to parse the message content
Please note that there are also other categories of modules available. This is to give an overview of what modules can do.

Configuration Directives

All configuration directives must be specified one per line and must start with dollar sign ($). It affects the rules.

Rule line

Every rule line consists of two fields, a ‘selector field’ and an ‘action field’. The selector field is divided into two, ‘facilities & priorities’. Action specifies what action must be taken for the matched rule.

A Sample Configuration

######################
 MODULES
######################

$ModLoad imuxsock
$ModLoad imklog

######################
 Directives
######################
# Set the default permissions for all log files. 

$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755

######################
 RULES
######################
mail.info /var/log/mail.info
mail.warn /var/log/mail.warn
mail.err /var/log/mail.err
daemon.* /var/log/daemon.log
Note: 10 Examples for Viewing Huge Log Files in Linux might be helpful when you are manipulating log files.

Templates

Templates are a very important features provided by rsyslog. It allows the user to log the messages in their desirable format. It can also be used to create dynamic file names to log the messages. In case of database logging, the templates are used to convert the message into a proper SQL statement.
A sample template will look like:
$template mytemplate “Text-Before %msg% Text-After\n”
The above template will log the message “This is hello from rsyslog” as:
Text-Before This is hello from rsyslog Text-After
We will see how to use the template for generate the log files dynamically.

Central Logging Server

The above sections should have given an overview about rsyslog and how to configure it. Now we will move on to setup a central logging system.
For our discussion we will have server IP as “192.168.1.1” for the central log server, where all the log messages from client should be forwarded.
Add the following lines to the rsyslog.conf of the central log server servers (In this example, the following line was added on the log server with ip-address 192.168.1.1):
 
# provides support for local system logging
$ModLoad imuxsock 

# provides kernel logging support (previously done by rklogd)
$ModLoad imklog

# provides UDP syslog reception. For TCP, load imtcp.
$ModLoad imudp

# For TCP, InputServerRun 514
$UDPServerRun 514

# This one is the template to generate the log filename dynamically, depending on the client's IP address.
$template FILENAME,"/var/log/%fromhost-ip%/syslog.log"

# Log all messages to the dynamically formed file. Now each clients log (192.168.1.2, 192.168.1.3,etc...), will be under a separate directory which is formed by the template FILENAME.
*.* ?FILENAME
 
 
After adding the above lines to the rsyslog.conf, restart the rsyslog process. Now the rsyslog server will be ready to accept messages.
 
 
# service rsyslog restart
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]


Add the following lines to the rsyslog.conf on the individual client machines that should send their log messages to the central server.
 
$ModLoad imuxsock

$ModLoad imklog

# Provides UDP forwarding. The IP is the server's IP address
*.* @192.168.1.1:514 

# Provides TCP forwarding. But the current server runs on UDP
# *.* @@192.168.1.1:514

Restart the rsyslog process on the clients. Now the rsyslog central server (In this example, 192.168.1.1) will receive all the log messages from the configured clients and each client’s log will be placed under a separate directory.