A quick update from a previous post for setting Metasploit on Fedora 21, the latest version.

It is mainly a copy and paste, except for a few typo fixes and some changes on the Ruby part. The good news is that Metasploit was recently ported to Ruby 2.x, so we don’t need anymore the rvm stuff anymore, which makes the process much simpler.

Preparing Postgresql

Install:

 yum -y install postgresql-server postgresql-devel

Initiate a new “cluster” and connect to the sql client through the postgres user:

# as root:
postgresql-setup initdb
systemctl start postgresql.service
su postgres
psql

Inside the psql console, create the new Metasploit user and its database:

create user msf;
alter user msf with encrypted password 'super password';
create database msfdb;
grant all privileges on database msfdb to msf;
\q

Then, we will tell to Postgres how to accept local connections. ident necessitates an system account, trust means no password for any local account and md5 stands for a classic password authentication, which we will prefer.
Back to a root terminal, add this line inside /var/lib/pgsql/data/pg_hba.conf and beware that the order is important:

# IPv4 local connections:
host msfdb msf 127.0.0.1/32 md5
host all all 127.0.0.1/32 ident

Then we can restart the service and check with psql that the credentials are working:

systemctl restart postgresql.service
psql -U msf msfdb -h localhost
\q

Setting Ruby

Metasploit runs well with Ruby 1.9.3, so we will install this version and switch to it using rbenv.
rbenv does a nice job at managing several version of ruby next to each other, installing dependancies (as OpenSSL) and setting PATH:

# as root:
yum install ruby rubygems ruby-devel rubygem-bundler

Getting and running Metasploit

Install:

# as root in e.g. /opt
git clone https://github.com/rapid7/metasploit-framework.git msf
cd msf
yum -y install libpcap-devel sqlite-devel
./msfupdate

The installation of ruby modules will take a while. Then, configure the database by creating config/database.yml:

production:
    adapter: postgresql
    database: msfdb
    username: msf
    password: 
    host: 127.0.0.1
    port: 5432
    pool: 75
    timeout: 5

Launch it and have fun :

# as root
./msfconsole
# check connection to the database
db_status

You may want to add a cron entry in /etc/crontab to get regular updates (though it may break from time to time due to broken dependencies, so you are advised to check it sometimes):

# msfupdate every 2 hours
0 */2 * * * root /opt/msf/msfupdate 2>&1

As I started to use Fedora 20 at work – by the way, a solid distro with all security features enabled, I had the bad surprise to get similar issues to those on OS X.
Again, we will have to face the joy of dependencies! Fedora provides Ruby 2.0 by default, so firing msfconsole would fail with many openssl warnings, ending with:

/usr/share/ruby/openssl/cipher.rb:61:in `': superclass mismatch for class Cipher (TypeError)
from /usr/share/ruby/openssl/cipher.rb:22:in `'
from /usr/share/ruby/openssl/cipher.rb:21:in `'
from /usr/share/ruby/openssl.rb:20:in `require'
from /usr/share/ruby/openssl.rb:20:in `'
from /opt/pentest/exploit/msf/lib/msf/ui/console/driver.rb:144:in `require'
from /opt/pentest/exploit/msf/lib/msf/ui/console/driver.rb:144:in `initialize'
from ./msfconsole:148:in `new'
from ./msfconsole:148:in `'

While the installation steps are globally the same than on Mac, there are some specific issues with rbenv and Postgresql.

Preparing Postgresql

Install:

 yum -y install postgresql-server postgresql-devel

Initiate a new “cluster” and connect to the sql client through the postgres user:

# as root:
postgresql-setup initdb
systemctl restart postgresql.service
su postgres psql

Inside the psql console, create the new Metasploit user and its database:

create user msf;
alter user msf with encrypted password 'super password';
create database msfdb;
grant all privileges on database msfdb to msf;
\q

Then, we will tell to Postgres how to accept local connections. ident necessitates an system account, trust means no password for any local account and md5 stands for a classic password authentication, which we will prefer.
Add this line inside /var/lib/pgsql/data/pg_hba.conf and beware that the order is important:

# IPv4 local connections:
host msfdb msf 127.0.0.1/32 md5
host all all 127.0.0.1/32 ident

Then we can restart the service and check with psql that the credentials are working:

systemctl restart postgresql.service
psql -U msf msfdb -h localhost
\q

Setting Ruby

Metasploit runs well with Ruby 1.9.3, so we will install this version and switch to it using rbenv.
rbenv does a nice job at managing several version of ruby next to each other, installing dependancies (as OpenSSL) and setting PATH:

# as root:
# download and install rbenv
\curl -sSL https://get.rvm.io | bash
rvm install ruby-1.9.3 --autolibs=packages
rvm use ruby-1.9.3
# checking, should obviously return ruby 1.9.3
ruby --version

Getting and running Metasploit

Install:

# as root in e.g. /opt
git clone https://github.com/rapid7/metasploit-framework.git msf
cd msf
yum -y install rubygem-bundler libpcap-devel
bundle install

Configure the database creating config/database.yml:

production:
    adapter: postgresql
    database: msfdb
    username: msf
    password: 
    host: 127.0.0.1
    port: 5432
    pool: 75
    timeout: 5

Launch it and have fun :

ln -s /opt/msf/msf* /usr/local/bin
sudo -i msfconsole
# as root
./msfconsole
# check connection to the database
db_status

Note that the -i option of sudo is mandatory, as it resets the environment for security purposes. That way it will get the environment of the target user, root, which should be just fine if you set rbenv with that user.

UPDATE 02/27/2014: I had some issues starting Metasploit with sudo and I actually failed to find a satisfying solution. I am now just launching it as root and in its work directory.

It is recommended to add a cron entry in /etc/crontab for regular updates:

# msfupdate every 2 hours
0 */2 * * * root /opt/msf/msfupdate 2>&1

My intention was to have everything on the RAID volume, including /boot, so that if a disk crash, I still can boot on the second one.
That’s the way I think it should work anyway, despite the number of tutorials or forum posts advising not to do so.

The openSUSE partitionner, during the installation process, warned me that having /boot on the RAID 1 array may not work with grub.
And indeed, at the end of the installation, I could not be able to set grub properly :

• the installer seemed to be lost, writing wrong devices in the various grub config file like menu.lst and grub.conf
• I tried to use the manual edition mode offered by the installer, but either because I missed something or there is a bug somewhere, I could never save my modifications.

Conclusion : there was a no go.

I became curious to see how a few other distributions could handle it.

At first, I thought they would all fail, because I have always found the openSUSE installer to be the best out there.

So I took a Debian Lenny CD, which is my second favorite distribution, and looked at it. The Debian installer is straightforward, but the partionner has always lacked of flexibility. It is fine when you are doing something pretty standard, but you get quickly limited when you want to do something more complicated.
There, no way to have /boot on a RAID volume, and the interface was really painful to use. Any mistake almost oblige you for sure to restart all from scratch.

Then, I looked at Fedora 11… without expecting much. The last time I tried it on a machine, it just froze every time it read the disk configuration.
But… surprise ! All I wanted was supported out of the box. The partionner was as pleasant to use as the one of openSUSE, and setting grub on /dev/md0 was just a matter of checking a box.

I have been quite impressed this time and Fedora will stay on this machine for a while.

I haven’t tested openSUSE 11.2 yet because the purpose of this machine is to be a server, so I care about stability.

But I will, and I wish it can support this feature also, or that it will be the case some day.