Eloy Mier Pérez Site

¿Alguna vez te ha hecho falta configurar un sistema de detección de intrusos en la lan de tu casa o en la oficina?

Pues mas sencillo no puede ser, echa un vistazo…..

This tutorial is based on another howto written by DevilMan, however I didn’t like the idea of manually compiling every package or the use of a GUI to get the software installed. This howto will work on a Gutsy Server or Gutsy desktop. With that said some of this howto is a direct copy from the original.
In this tutorial I will describe how to install and configure Snort (an intrusion detection system (IDS)) from source, BASE (Basic Analysis and Security Engine), MySQL, and Apache2 on Ubuntu 7.10 (Gutsy Gibbon). Snort will assist you in monitoring your network and alert you about possible threats. Snort will output its log files to a MySQL database which BASE will use to display a graphical interface in a web browser.

1. Gain root privileges

It is easiest to do this install as root user.

sudo su -

2. Install some packages

The following will install all the required packages to make this setup work:

apt-get install libpcap0.8-dev libmysqlclient15-dev mysql-client-5.0 mysql-server-5.0 bison flex apache2 libapache2-mod-php5 php5-gd php5-mysql libphp-adodb php-pear libc6-dev g++ gcc pcregrep

3. Get and compile snort

   Download snort and snort rules

   wget http://www.snort.org/dl/current/snort-2.8.0.1.tar.gz

   There are a couple options for rules. The following will download the public rules, however with a quick registration at the snort site you can get more current rules. Your choice but the next command is run the same way with the appropriate URL:

   wget http://snort.org/pub-bin/downloads.cgi/Download/vrt_pr/snortrules-pr-2.4.tar.gz

   Unpack and get them ready for compile

   tar zxvf snort-2.8.0.1.tar.gz

   cd snort-2.8.0.1

   tar zxvf ../snortrules-pr-2.4.tar.gz

   Now compile them

   ./configure -enable-dynamicplugin –with-mysql

   make

   make install

   Keep this directory handy as you can simply run

   make uninstall

   To uninstall snort later if you choose

   Move things into position

   We now need to move the rules and config for snort into position

   mkdir /etc/snort /etc/snort/rules /var/log/snort

   cd /usr/src/snort-2.8.0.1/etc

   cp * /etc/snort/

   cd ../rules

   cp * /etc/snort/rules

The Snort package in the Gutsy repo’s are out of date. So I prefered to download the most current and install that. This is the only thing we will compile from scratch.

The latest version of snort at the time of writing is 2.8.0.1

First let’s go to a working directory:

cd /usr/src/

Open a web browser and navigate to http://www.snort.org/dl right click on the most recent release and copy link location.

4. Configure Snort

We need to modify the snort.conf file to suite our needs.

Open /etc/snort/snort.conf with your favorite text editor (nano, vi, vim, etc.).

# vi /etc/snort/snort.conf

5. Change “var HOME_NET any” to “var HOME_NET 192.168.1.0/24″ (your home network may differ from 192.168.1.0)

   Change “var EXTERNAL_NET any” to “var EXTERNAL_NET !$HOME_NET” (this is stating everything except HOME_NET is external)

   Change “var RULE_PATE ../rules” to “var RULE_PATH /etc/snort/rules”

   Scroll down the list to the section with “# output database: log, mysql, user=”, remove the “#” from in front of this line.

   Change the “user=root” to “user=snort”, change the “password=password” to “password=snort_password”, “dbname=snort”

   Make note of the username, password, and dbname. You will need this information when we set up the Mysql db.

   Save and quit.

6. Setup the Mysql database.

Log into the mysql server.

# mysql -u root -p

Create the snort database. Make sure you change the ’snort_password’ to something else!

mysql> create database snort;

grant all privileges on snort.* to ’snort’@'localhost’ identified by ’snort_password’; mysql> exit

We will use the snort schema for the layout of the database.

# mysql -D snort -u snort -p < /usr/src/snort-2.8.0.1/schemas/create_mysql

NOTE: Use your snort DB user password when prompted.

7. Time to test Snort

In the terminal type:

# snort -c /etc/snort/snort.conf

If everything went well you should see an ascii pig.

To end the test hit ctrl + c.

NOTE: If you get errors you may want to try commenting out lines 97,98 and 452 of /etc/snort/rules/web-misc.rules. This was an issue in the past but doesn’t seem to be anymore.

8. Get and install BASE

Open a web browser and go to http://sourceforge.net/project/showfiles.php?group_id=103348.
Click on download then right click on the newest tar.gz package and select copy link (at the time of writing this is base-1.3.9).
In the terminal type:

cd

wget http://easynews.dl.sourceforge.net/sourceforge/secureideas/base-1.3.9.tar.gz

Now go to your web document root (by default this is /var/www), unpack the tarball and set the permissions needed to configure BASE:

cd /var/www/

tar zxvf ~/base-1.3.9.tar.gz cd .. chmod 757 base-1.3.9

We want to make sure that a couple of Pear modules are activated:

pear install Image_Color

pear install Image_Canvas-alpha

pear install Image_Graph-alpha

9. Set up BASE
   1. Step 1 of 5: Enter the path to ADODB.
      This is /usr/share/php/adodb.
   2. Step 2 of 5: Database type = MySQL, Database name = snort, Database Host = localhost, Database username = snort, Database Password = snort_password
   3. Step 3 of 5: If you want to use authentication enter a username and password here and check the box.
   4. Step 4 of 5: Click on Create BASE AG.
   5. Step 5 of 5: once step 4 is done at the bottom click on Now continue to step 5.

Open a web browser and navigate to http://YOUR.IP.ADDRESS/base-1.3.9/setup.
Click continue on the first page.

Bookmark this page.
Change the permissions back on the /var/www/base-1.3.9 folder.
# chmod 755 /var/www/base-1.3.9

We are done. Congrats!!!

To start Snort in the terminal type (make sure you change eth0 to the right interface for your machine:

# snort -c /etc/snort/snort.conf -i eth0 -D
This starts snort using eth0 interface in a daemon mode.
To make sure it is running you can check with the following command:

# ps aux | grep snort

If it’s running you will see an entry similar to snort -c /etc/snort/snort.conf -i eth0 -D.
If you would like to learn how to write your own Snort rules there is a guide at http://www.snort.org/docs/snort_manual/node16.html.

Good luck.

Otra vez la gente de howtoforge nos sorprenden con un articulo de gran utilidad. Una guía sobre las mejores practicas en cuanto a uso y configuración de ssh.

Recomiendo su lectura aunque la misma sea en perfecto Ingles….

Introduction
Are you using SSH in the best way possible? Have you configured it to be as limited and secure as possible? The goal of this document is to kick in the new year with some best practices for SSH: why you should use them, how to set them up, and how to verify that they are in place.
All of the examples below assume that you are using EnGarde Secure Linux but any modern Linux distribution will do just fine since, as far as I know, everybody ships OpenSSH.

SSHv2 vs. SSHv1

There are numerous benefits to using the latest version of the SSH protocol, version 2, over it’s older counterpart, version 1 and I’m not going into a lot of details on those benefits here – if you’re interested, see the URL in the reference below or Google around. That being said if you don’t have an explicit reason to use the older version 1, you should always be using version 2.
To use SSHv2 by default but permit SSHv1, locate the “Protocol” line in your sshd_config file and change it to:
Protocol 2,1
When doing 2,1 please note that the protocol selection is left up to the client. Most clients will default to v2 and “fall back” to v1, while legacy clients may continue to use v1. To force everybody to use SSHv2, change it to:
Protocol 2
When you make this change don’t forget to generate the appropriate HostKey’s as well! SSHv2 requires the following keys:

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

While SSHv1 requires:
# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key

Once your changes are made, restart the SSH daemon:
# /etc/init.d/sshd restart
[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell Daemon
From another machine, try SSH’ing in. You can use the -v option to see which protocol is being used, and the ‘-oProtocol=’ option to force one or the other – for example, “ssh -v -oProtocol=2 ” would force protocol version 2.

Binding to a Specific Address or Non-Standard Port
If you’re running SSH on an internal, firewalled, workstation then you can probably skip this section, but if you’re running SSH on a firewall or on a machine with two network interfaces, this section is for you.
Out of the box OpenSSH will bind to every available network address; while convenient and suitable for most installations, this is far from optimal. If your machine has two or more interfaces then the odds are that one is “trusted” and the other is “untrusted.” If this is the case, and you don’t need nor want SSH access coming in on the untrusted interface, then you should configure OpenSSH to listen on a specific interface.
To have OpenSSH only bind to your internal interface, 192.168.0.1 in the example below, locate the following line in your sshd_config file:
ListenAddress 0.0.0.0
and change the 0.0.0.0 to 192.168.0.1:
ListenAddress 192.168.0.1

To verify that this change took, restart OpenSSH and look at netstat:
# /etc/init.d/sshd restart
[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell Daemon
# netstat -anp | grep sshd
tcp 0 0 192.168.0.1:22 0.0.0.0:* LISTEN 7868/sshd

As you can see, the sshd daemon is now only listening on 192.168.0.1. SSH requests coming in any other interface will be ignored.
Similarly, you may want to change the port that the SSH daemon binds to. Sometimes there is a functional need for this (ie, your employer blocks outbound 22/tcp) but there is also security-through-obscurity value in this as well. While not providing any real security benefit against a determined attacker, moving the SSH daemon off of port 22 protects you against automated attacks which assume that the daemon is running on port 22.
To have OpenSSH bind to a port other than port 22, 31337 in the example below, locate the following line in your sshd_config file:
Port 22
and change the 22 to 31337:
Port 31337
To verify that this change took, restart OpenSSH and, again, look at netstat:
# netstat -anp | grep sshd
tcp 0 0 192.168.0.1:31337 0.0.0.0:* LISTEN 330/sshd
Finally, to SSH into a host whose SSH daemon is listening on a non-standard port, use the -p option:
ssh -p 31337 user@192.168.0.1

Using TCP Wrappers
TCP Wrappers are used to limit access to TCP services on your machine. If you haven’t heard of TCP Wrappers you’ve probably heard of /etc/hosts.allow and /etc/hosts.deny: these are the two configuration files for TCP Wrappers. In the context of SSH, TCP Wrappers allow you to decide what specific addresses or networks have access to the SSH service.
To use TCP Wrappers with SSH you need to make sure that OpenSSH was built with the -with-tcp-wrappers. This is the case on any modern distribution.
As I indicated earlier, TCP Wrappers are configured by editing the /etc/hosts.deny and /etc/hosts.allow files. Typically you tell hosts.deny to deny everything, then add entries to hosts.allow to permit specific hosts access to specific services.

An example:
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the ‘/usr/sbin/tcpd’ server.
#
ALL: ALL
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the ‘/usr/sbin/tcpd’ server.
#
sshd: 207.46.236. 198.133.219.25

In the example above, access to SSH is limited to the network 207.46.236.0/24 and the address 198.133.219.25. Requests to any other service from any other address are denied by the “ALL: ALL” in hosts.deny. If you try to SSH into a machine and TCP Wrappers denies your access, you’ll see something like this:
ssh_exchange_identification: Connection closed by remote host
This simple configuration change significantly hardens your installation since, with it in place, packets from hostile clients are dropped very early in the TCP session — and before they can do any real damage to a potentially vulnerable daemon.

Public Key Authentication
The last item I will cover is public key authentication. One of the best things you can do to tighten the security of your SSH installation is to disable password authentication and to use public key authentication instead. Password authentication is suboptimal for many reasons, but mostly because people choose bad passwords and attackers routinely try to brute-force passwords. If the systems administrator has chosen a bad password and he’s permitting root logins… game over.
Public key authentication is no silver bullet – similarly, people generate passphrase-less keys or leave ssh-agents running when they shouldn’t – but, in my opinion, it’s a much better bet.
Just about every distribution ships with public key authentication enabled, but begin by making sure it is:
RSAAuthentication yes
PubkeyAuthentication yes
Both of these options default to “yes” and the “RSAAuthentication” option is for SSHv1 and the “PubkeyAuthentication” option is for SSHv2. If you plan on using this authentication method exclusively, while you’re there, you may want to disable password authentication:
PasswordAuthentication no
Before you proceed, make sure you have a terminal open on your target machine. Once you restart the SSH daemon you will no longer be able to log in without a key… which we haven’t generated yet!

Once you’re sure, restart the SSH daemon:
# /etc/init.d/sshd restart
[ SUCCESSFUL ] Secure Shell Daemon
[ SUCCESSFUL ] Secure Shell Daemon

Now, from your desktop, try to SSH in to your target machine:
$ ssh rwm@brainy
Permission denied (publickey,keyboard-interactive).

We’re locked out! This is a good thing. The next step, on your desktop, is to generate a key:
$ ssh-keygen -t dsa -C “Ryan’s SSHv2 DSA Key (Jan 2008)”
Generating public/private dsa key pair.
Enter file in which to save the key (/home/rwm/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): **********
Enter same passphrase again: **********
Your identification has been saved in /home/rwm/.ssh/id_dsa.
Your public key has been saved in /home/rwm/.ssh/id_dsa.pub.
The key fingerprint is:
98:4d:50:ba:ee:8b:79:be:b3:36:75:8a:c2:4a:44:4b Ryan’s SSHv2 DSA Key (Jan 2008)

A few notes on this:

1. You can generate a DSA (-t dsa), RSA (-t rsa), or SSHv1 (-t rsa1) key. In the example above I’m using dsa.
2. I like to put the date I generated the key in the comment (-C) field, that way I can change it out every so often.
3. You’re entering a passphrase, not a password. Use a long string with spaces and punctuation. The longer and more complicated the better!

The command you just ran generated two files – id_dsa, your private key and id_dsa.pub, your public key. It is critical that you keep your private key private, but you can distribute your public key to any machines you would like to access.

Now that you have generated your keys we need to get the public key into the ~/.ssh/authorized_keys file on the target machine. The best way to do this is to copy-and-paste it – begin by concatenating the public key file:
$ cat .ssh/id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAL7p6bsg5kK4ES9BWLPCNABl20iQQB3R0ymaPMHK…
… ds= Ryan’s SSHv2 DSA Key (Jan 2008)

This is a very long string. Make sure you copy all of it and that you do NOT copy the newline character at the end. In other words, copy from the “ssh” to the “2008)”, but not past that.
The next step is to append this key to the end of the ~/.ssh/authorized_keys file on your target machine. Remember that terminal I told you to keep open a few steps ago? Type the following command into it, pasting the key you’ve just copied into the area noted KEY:
echo “KEY” >> ~/.ssh/authorized_keys

For example:
echo “ssh-dss AAAA5kS9BWLPCN…s= Ryan’s SSHv2 DSA Key (Jan 2008)” >> ~/.ssh/authorized_keys
Now, try to SSH in again. If you did this procedure correctly then instead of being denied access, you’ll be prompted for your passphrase:
$ ssh rwm@brainy
Enter passphrase for key ‘/home/rwm/.ssh/id_dsa’:
Last login: Thu Jan 10 14:37:14 2008 from papa.engardelinux.org
[rwm@brainy ~]$
Viola! You’re now logged in using public key authentication instead of password authentication.

In Summary…
SSH is a wonderful tool and is every systems administrators second best friend (Perl, of course, being the first . It allows you to read your email from anywhere, provided you still use a terminal-based mail reader. It allows you to tunnel an xterm or X11 application from your home server to your desktop at work. It provides you a far superior alternative to FTP in SFTP and SCP.
SSH is great but just like any tool, it’s only as good as you use it. I hope that you found value in some of my best practices and if you have any of your own, leave them in the comments!
Before I go, here are some additional resources on SSH:

1. The OpenSSH Project http://www.openssh.com/
2. SSH, The Secure Shell: The Definitive Guide http://www.snailbook.com/
3. Introduction to SSH Versions 1 and 2 http://www.pcs.cnu.edu/%7Embland/ssh_intro/
4. Knock, Knock, Knockin’ on EnGarde’s Door (with FWKNOP) http://www.linuxsecurity.com/content/view/131846/171/