Tag Archives: rhel

Change the default SSH port and alter SELinux context to match

Security through obscurity is not something one would generally recommend. But to thwart the effort of automated scanners changing the default OpenSSH port will yield you less pain in every day life. This will not fend off directed attacks or nullify vulnerabilities or bad security design.

Should you see an error message such as

shd[14221]: error: Bind to port 9898 on 192.168.0.50 failed: Permission denied

it indicates that the system prevented the daemon to bind that port. Most likely SELinux.

The instructions provided will be valid on Fedora 14/15, CentOS 6, RHEL 6, Scientific Linux 6 and newer versions.

To change the default SSH port you need to do the following.

  • Stop the SSH daemon
  • Alter the /etc/ssh/sshd_config with your new port
  • Alter the SELinux context with semanage
  • Start the SSH daemon

Stop the SSH daemon

# service sshd stop

Alter the /etc/ssh/sshd_config with your new port

Alter the configuration file with your favorite editor, in my case “nano”.

# nano /etc/ssh/sshd_config

Alter the port configuration parameter change the following line

Port 22

to

Port 9898

Alter the SELinux context with semanage

# semanage port -a -t ssh_port_t -p tcp 9898

Initially you would think the following would work. But it will not. For it to work you would have to alter the policy in the selinux-policy package, rebuild and install it. So skip it, but now you know why.

# semanage port -d -t ssh_port_t -p tcp 22

Start the SSH daemon

# service sshd start

// CrashMAG

Change the default MySQL data directory with SELinux enabled

This is a short article that explains how you change the default MySQL data directory and adjust SELinux to account for the changes. The article assumes that you’re running either RHEL, CentOS, Scientific Linux or Fedora with SELinux enabled. This works with the most recent EL (6.2) version.

We’ll be doing this in the following order.

  • Stopping the MySQL server
  • Create a new data directory and move the content from the old data directory
  • Correct the MySQL configuration file
  • Adjust SELinux parameters to accept our new change
  • Starting the MySQL server

Stopping the MySQL server

# service mysqld stop

Create a new data diretory and move the content from the old one

Creating a new data directory

# mkdir /srv/mysql/
# chown mysql:mysql /srv/mysql

Moving the original data files

 # mv /var/lib/mysql/* /srv/mysql/

Correct the MySQL configuration file

Edit the my.cnf file for your distribution. In my example it’s located in the /etc/mysql/ directory. RHEL/CentOS/Scientific Linux put the my.cnf file directly in /etc by default.

# nano /etc/mysql/my.cnf

Change

datadir=/var/lib/mysql

to

datadir=/srv/mysql

and

socket=/var/lib/mysql/mysql.sock

to

socket=/srv/mysql/mysql.sock

and save the file.

Adjust SELinux parameters to accept our new change

Should the following command output “Permissive” or “Disabled” then you may skip the details for SELinux.

# getenforce

Run the semanage command to add a context mapping for /srv/mysql.

# semanage fcontext -a -t mysqld_db_t "/srv/mysql(/.*)?"

Now use the restorecon command to apply this context mapping to the running system.

# restorecon -Rv /srv/mysql

Starting the MySQL server

# service mysqld start

Verifying access and connectivity

$ mysql -u root -p
mysql> show databases;

If this is working, you’re up and running. Should you get a message that says

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’

then add the following to your /etc/my.cnf

[client]
socket = /srv/mysql/mysql.sock

Optionally you can just use

$ mysql -u root -p --protocol tcp

to avoid connecting via the socket.

// CrashMAG

Self-signed certificate for Apache

These instructions are distribution agnostic. However I used CentOS during my tests, so file paths will match that of CentOS, RHEL, Scientific Linux and Fedora. For any other distribution you’ll have to look that up yourself.

The tools required are OpenSSL, Apache and mod_ssl for Apache. To accomplish this I had to run

# yum install mod_ssl

on my CentOS 5.6 box. Which already had Apache up and running.

Setting up a self-signed certificate using certificate and key

Generate your key and certificate

Most of these parameters explain themselves, see beneath for those who do not.

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout website.key -out website.crt

-nodes
don’t encrypt the output key
-x509
output a x509 structure instead of a cert. req.

Copy the key and certificate

# cp website.key website.crt /etc/httpd/conf/

Set permissions and ownership on your key and certificate

This way nobody except root has read access.

chmod 440 /etc/httpd/conf/website.key /etc/httpd/conf/website.crt
chown root:root /etc/httpd/conf/website.key /etc/httpd/conf/website.crt

Alter the apache configuration file, also known as httpd.conf

Edit /etc/httpd/conf/httpd.conf with your favorite text editor, in my case, nano. Add the following text at the bottom of the file.

      <VirtualHost *:443>
        SSLEngine on
        # Change the next two lines according to where you've actually
        # stored the certificate and key files.
        SSLCertificateFile /etc/httpd/conf/website.crt
	SSLCertificateKeyFile /etc/httpd/conf/apache2/website.key

        ServerName domain.tld
        SSLOptions StrictRequire
        SSLProtocol all -SSLv2

        DocumentRoot /path/to/ssl/enabled/site
        <Directory /path/to/ssl/enabled/site/>
          SSLRequireSSL
          Order Deny,Allow
          Allow from All
        </Directory>
      </VirtualHost>

StrictRequire
This forces forbidden access when SSLRequireSSL or SSLRequire successfully decided that access should be forbidden. Usually the default is that in the case where a “Satisfy any” directive is used, and other access restrictions are passed, denial of access due to SSLRequireSSL or SSLRequire is overridden (because that’s how the Apache Satisfy mechanism should work.) But for strict access restriction you can use SSLRequireSSL and/or SSLRequire in combination with an “SSLOptions +StrictRequire”. Then an additional “Satisfy Any” has no chance once mod_ssl has decided to deny access.

Enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2

Setting up a self-signed certificate with the certificate and key in one file

Generate your key and certificate

Most of these parameters explain themselves, see beneath for those who do not.

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout website.pem -out website.pem

-nodes
don’t encrypt the output key
-x509
output a x509 structure instead of a cert. req.

Copy the key and certificate

# cp website.pem  /etc/httpd/conf/

Set permissions and ownership on your key and certificate

This way nobody except root has read access.

chmod 440 /etc/httpd/conf/website.pem
chown root:root /etc/httpd/conf/website.pem

Alter the apache configuration file, also known as httpd.conf

Edit /etc/httpd/conf/httpd.conf with your favorite text editor, in my case, nano. Add the following text at the bottom of the file.

      <VirtualHost *:443>
        SSLEngine on
        # Change the next line according to where you've actually
        # stored the certificate and key file.
        SSLCertificateFile /etc/httpd/conf/website.pem

        ServerName domain.tld
        SSLOptions StrictRequire
        SSLProtocol all -SSLv2

        DocumentRoot /path/to/ssl/enabled/site
        <Directory /path/to/ssl/enabled/site/>
          SSLRequireSSL
          Order Deny,Allow
          Allow from All
        </Directory>
      </VirtualHost>

StrictRequire
This forces forbidden access when SSLRequireSSL or SSLRequire successfully decided that access should be forbidden. Usually the default is that in the case where a “Satisfy any” directive is used, and other access restrictions are passed, denial of access due to SSLRequireSSL or SSLRequire is overridden (because that’s how the Apache Satisfy mechanism should work.) But for strict access restriction you can use SSLRequireSSL and/or SSLRequire in combination with an “SSLOptions +StrictRequire”. Then an additional “Satisfy Any” has no chance once mod_ssl has decided to deny access.

Enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2

// CrashMAG

View information about your BIOS from Linux using dmidecode

To get at this information we will use a utility called “dmidecode”. dmidecode is a tool for dumping a computer’s DMI (some say SMBIOS) table contents in a human-readable format.

On CentOS/RHEL/Fedora you may run the following to install it.

# yum install dmidecode

On Arch Linux you may run

# pacman -S dmidecode

The following examples will allow you to see a few important parts of information such as;

  • The manufacturer of your motherboard
  • What type of motherboard you have
  • The version of the BIOS running on your motherboard

To view the manufacturer and what type of motherboard you have, run the following

dmidecode --type system

Example

# dmidecode 2.11
SMBIOS 2.4 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: Gigabyte Technology Co., Ltd.
        Product Name: GA-MA78G-DS3H
        Version:
        Serial Number:
        UUID: 4E2F4100-0000-0000-0000-0000FFFFFFFF
        Wake-up Type: Power Switch
        SKU Number:
        Family:

Handle 0x0034, DMI type 32, 11 bytes
System Boot Information
        Status: No errors detected

To view the version of your BIOS you may run the following

#dmidecode --type bios

Example

# dmidecode 2.11
SMBIOS 2.4 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: Award Software International, Inc.
        Version: FA
        Release Date: 09/19/2008
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 1024 kB
        Characteristics:
                ISA is supported
                PCI is supported
                PNP is supported
                APM is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                BIOS ROM is socketed
                EDD is supported
                5.25"/360 kB floppy services are supported (int 13h)
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                3.5"/2.88 MB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                AGP is supported
                LS-120 boot is supported
                ATAPI Zip drive boot is supported
                BIOS boot specification is supported
                Targeted content distribution is supported

Handle 0x0029, DMI type 13, 22 bytes
BIOS Language Information
        Language Description Format: Long
        Installable Languages: 3
                n|US|iso8859-1
                n|US|iso8859-1
                r|CA|iso8859-1
        Currently Installed Language: n|US|iso8859-1

There’s also additional options to use with dmidecode. You probably also want to try the following to get an idea of what type of information you can get your hands on.

#dmidecode --type keyword
Valid type keywords are:
  bios
  system
  baseboard
  chassis
  processor
  memory
  cache
  connector
  slot

// CrashMAG

Resetting the root/postgres password for PostgreSQL

The following is required to reset the root/postgres user password for PostgreSQL. The distribution used in my example is CentOS 5.5 and PostgreSQL 8.4.

Note: By default there’s no password for the postgres user.

In step 2 and 5 you will most likely not be using “ident” but rather “password” or “md5”.

1. Shut down PostgreSQL

# service postgresql stop

2. Reset the authentication mechanism (assuming defaults are already being used)

Edit the /usr/lib/pgsql/data/pg_hba.conf file

# nano /usr/lib/pgsql/data/pg_hba.conf

Navigate down to the line that says

local all all ident

Edit it to

local all postgres trust

And now save the file.

3. Start PostgreSQL

# service postgresql start

4. Log in and change the password

# su - postgres
$ psql -d template1 -U postgres
alter user postgres with password 'new_password';

Or alternatively do it all in one go with the following command

> psql -U postgres template1 -c "alter user postgres with password 'new_password';"

5. Reverse the actions you did in step 2

Edit the /usr/lib/pgsql/data/pg_hba.conf file

# nano /usr/lib/pgsql/data/pg_hba.conf

Navigate down to the line that says

local all all trust

Edit it to

local all postgres ident

And now save the file.

6. Start PostgreSQL

# service postgresql start

Success!

// CrashMAG

Changing the default PostgreSQL data folder (PGDATA)

Installing the PostgreSQL server on RHEL, CentOS, Scientific Linux or Fedora installs the PostgreSQL databases and configuration files in “/var/lib/pgsql/data”.

This may or may not be desirable. Let’s assume for a moment you have a separately crafted partition for PostgreSQL to use, let’s say a RAID10 volume. You’d want to change this.

Change the defaults

Use your favorite text editor, in my case nano to create the following file (must be the same as the name of the service)

# nano /etc/sysconfig/pgsql/postgresql

Add the following

PGDATA=/postgresql/data

Optionally you can also add the following to change the default port (example is the default port)

PGPORT=5432

Adjusting SELinux to permit the new data folder (pgdata) location

Should the following command output “Permissive” or “Disabled” then you may skip the details for SELinux.

# getenforce

Run the semanage command to add a context mapping for /opt/postgresql and any other directories/files within it.

# semanage fcontext -a -t postgresql_db_t "/postgresql/data(/.*)?"

Now use the restorecon command to apply this context mapping to the running system

# restorecon -Rv /postgresql/data

Starting PostgreSQL

# chkconfig --levels 345 postgresql on
# service postgresql initdb
# service postgresql start

You’re all set to go! Keep in mind that PostgreSQL listens to ‘localhost’ by default. To change this you need to alter the “listen_address” parameter in “/var/lib/pgsql/data/postgresql.conf” (change will require restart).

// CrashMAG

RHEL/Centos 5 minimal installation

There’s no option during the CentOS 5 install, for a minimal installation. The purpose is quite simple, to keep the attack surface as small as possible.

A minimal installation is performed by doing the following

  • During the category/task selection, deselect all package categories, and choose the “Customize now” option at the bottom of screen.
  • During the customized package selection, deselect everything ( including the Base group ).

This will yield you 234 packages with the Centos 5.5 installation media. I’ve attached a .txt file containing all the packages for your leisure.

Link: installed-packages

// CrashMAG

Guide and hardning tips for RHEL/CentOS 5 from NSA

As I was looking to see if NSA had updated their guides for RHEL 6 and it turns out they haven’t. I decided it would be a good idea to post about them to give them some better coverage.

This is just a small tip of free and useful information in regards to securing your RHEL/CentOS installation. A lot of the information is general in nature and can therefore be applied to any Linux distribution. It’s definitely worth your time.

I take no credit, the credit goes to NSA for creating the documents to begin with.

Guide to the Secure Configuration of Red Hat Enterprise Linux 5
www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Red Hat Linux 5 Hardening Tips
www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf

I just love how just about every section starts with “Disable ‘insert your service here’ if possible…” 😉

// CrashMAG

Setting up sSMTP with GMail

Let me introduce you to the “extremely simple MTA to get mail off the system to a mailhub”. Particularly useful when you don’t want systems to have a full blown MTA installed. Such as Postfix, Exim or Sendmail. I find ssmtp extremely helpful on standalone servers that use Logwatch.

Getting this up and running requires 4 steps.

  • Installing SSMTP
  • Configuring SSMTP
  • Changing the MTA on your system
  • Testing

Installing the daemon, ssmtp.

Use your favorite package manager, in my example I’ll be using YUM. (Fedora/CentOS/RHEL/Scientific Linux). For Centos/RHEL/Scientific Linux 5.5 or 5.6 you need access to the EPEL repository to install sSMTP. Add EPEL to your system using the following command.

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

You can find eventual new links from http://download.fedora.redhat.com/pub/epel/5/i386/repoview/epel-release.html

yum install ssmtp

Configuring SSMTP

Edit /etc/ssmtp/ssmtp.conf with your favorite text editor. I’ll be using nano.

nano /etc/ssmtp/ssmtp.conf

Remove all the entries and replace it with the ones beneath.

root=insert_your_email_address here
mailhub=smtp.gmail.com:587
UseTLS=YES
UseSTARTTLS=YES
AuthUser=your_gmail_username_which_you'll_be_using_to_send
AuthPass=password

Changing the MTA

For CentOS/Fedora/RHEL

alternatives --config mta

Press the number that equals /usr/sbin/sendmail.ssmtp and you’re done.

Testing

I’m testing this using the verbose mode just to be able to see the dialogue with the Google SMTP server.

cat random_file | sendmail -v your_email_address

// CrashMAG

Managing /etc with etckeeper and git

The following was done on Fedora 14. Keep in mind that the Etckeeper and git specific actions will be similar on whatever platform you’re on.

Simply put, Etckeeper automatically revisions your /etc folder. Allows you to compare, commit and revert the changes that have been made. It’ll also allow you to restore files, should you be unlucky and delete them. Once etckeeper is installed, it will work together with your package manager and cron to do its work. To manage all this you’ll use the commands that your chosen VCS (Version Control System).

Etckeeper supports Git, Bazaar, Darcs and Mercurial.

Use of Etckeeper

Installation

yum install etckeeper

Initialization

etckeeper init

Initial commit

etckeeper commit "initial commit"

Once this is done, etckeeper will make sure that every time you use the package manager (YUM) changes will be recorded. There are however a few git related commands you should be aware of.

Useful and necessary commands

Note: All of these commands assumes your current path is /etc

Viewing the Git log

git log

Check if there’s any modified files

git status

Complete status overview

git log --stat --summary

Revert a change

git revert 

View changes you haven’t commited yet

git diff

List different commits, each on one line.

git log --pretty=oneline

Revert to latest change-set, discarding changes

git reset --hard

Re-enter commit message

git commit --amend

Have at it folks!

// CrashMAG