Secunia ofrece un servicio gratuito que puede resultar muy útil para mantener correctamente parcheado y actualizado todo el software de nuestra máquina. Ofrece la posibilidad de realizar un análisis símplemente accediendo a la web y descargando un applet (cuya firma es verificada correctamente).
Secunia analiza los programas instalados y detecta los que se encuentran desactualizados y por tanto pueden resultar inseguros. Nos facilita también información sobre la vulnerabilidad concreta a la que está expuesta la versión oboleta del software instalado.
Nos permite además descargarnos (de nuevo, de forma gratuita) el software a nuestra máquina para instalarlo, y realizar así un análisis más exhaustivo. Al finalizar el análisis, nos presenta un informe en el que nos detalla las alertas de cada software instalado junto con la versión vulnerable de cada programa, además de un enlace directo a la actualización recomendada correspondiente.
Secunia Software Inspector
28.3.08
Secunia Software Inspector
25.3.08
SPA (Single Packet Authorization) con fwknop
En este artículo se pretende hacer una introducción al concepto de ‘port knocking’ (técnica que se puede usar como complemento para securizar servicios que se encuentren detrás de un firewall) y más concretamente a una de sus variantes, ‘Single Packet Authorization’ (SPA), mediante un ejemplo práctico guiado paso a paso utilizando fwknop, una implementación de SPA de código abierto, bajo sistemas linux.
Introducción a Port Knocking
En informática, port knocking es un método utilizado para abrir puertos en un firewall mediante un conjunto de intentos de conexión lanzados sobre puertos cerrados. Cuando en el servidor se recibe la secuencia correcta de conexión, las reglas del firewall son modificadas dinámicamente para permitir al host que envió los paquetes conectar a un puerto/s específico/s.
El principal objetivo de port knocking es prevenir escaneos de puertos a un determinado equipo para evitar potenciales ataques a servicios vulnerables. Esto se consigue ya que, a menos que se envíe la secuencia de knocks correcta, los puertos aparecerán como cerrados para cualquiera que lance un escaneo sobre el equipo. Un 'port knocking' es similar a un handshake y consiste en una serie de paquetes TCP, UDP o incluso ICMP dirigidos cada uno a un puerto concreto en la máquina destino. La complejidad del 'knock' puede ir desde una simple lista de paquetes protocolo-puerto hasta un complejo hash encriptado controlado según IP origen y/u otros factores.
Ejemplo: Un demonio sshd configurado por defecto escuchará en el puerto 22. Configuramos el firewall para que cierre el puerto 22 y elegimos como secuencia de 'knocks' la sucesión TCP-100, UDP-200, TCP-300 que habilitará el puerto 22 en la máquina. El puerto permanecerá cerrado hasta que un usuario intente inicializar conexiones TCP y UDP hacia los puertos 100, 200 y 300 en ese mismo orden. En este caso, el puerto se abrirá durante un intervalo de tiempo determinado. En caso contrario, el usuario recibirá un paquete RST/ACK cuando inicialice conexiones TCP hacia el puerto22.
Pero Port Knocking tiene algunas debilidades:
Seguir Leyendo...
- Un atacante que no conozca la secuencia de 'knocks', mediante fuerza bruta, podría llegar a obtener la secuencia requerida para habilitar un determinado servicio.
- Monitorizando las comunicaciones, un atacante podría intentar detectar una secuencia de puertos para reproducirla posteriormente contra el servidor para conseguir acceso al servicio protegido.
- Las secuencias de port knock pueden ser encriptadas y existen diversas implementaciones que se pueden encontrar en www.portknocking.org. Pero cada paquete enviado puede contener sólo dos bytes de información debido al tamaño de 16 bits que tienen los campos de los puertos en las cabeceras TCP y UDP. Por tanto, para enviar una secuencia cifrada, utilizando por ejemplo un algoritmo simétrico de 128 bits, una secuencia de port knock estaría formada por 128/16=8 paquetes. Aquí nos encontramos con un posible problema de entrega desordenada de paquetes ya que en este caso no hay una conexión cliente-servidor (tipo TCP). Se puede añadir un retardo de medio segundo para evitar este problema, y en este caso el tiempo de entrega de la secuencia llegaría a 4 segundos. Pero si se decide utilizar algoritmos de cifrado asimétricos, la cantidad de bits a enviar es más grande y el tiempo de entrega de estos paquete se vuelve excesivo e inviable. Esto puede resultar una gran desventaja del port knocking.
Conclusión: Port knocking provee algunas ventajas que aumentan las seguridad, pero también tiene algunas limitaciones serias que hay que tener en cuenta. SPA (Single Packet Authorization) es un protocolo relativamente nuevo que mantiene los beneficios del port knocking pero soluciona algunas de las limitaciones del mismo.
Las primeras noticias que se tuvo de la implementación de SPA surgieron en Mayo de 2005 como una parte de un software llamado fwknop www.cipherdyne.org/fwknop.
Descripción de SPA (Single Packet Authorization)
SPA es una variante del port knocking donde sólo un 'knock' es necesario para validar la petición. Éste 'knock' consiste en un paquete encriptado.
SPA ofrece una arquitectura similar a la del port cknocking:
Pero aquí es donde acaban las similitudes.
La principal ventaja que ofrece SPA es que la cantidad de información que puede ser incluída en el paquete sólo se encuentra limitada por el MTU. Esta ventaja permite que mediante SPA se pueda incluir en el paquete no sólo información de acceso, sino también por ejemplo, comandos que sean ejecutados en el sevidor SPA.
En definitiva, SPA provee un nivel de seguridad similar al port knocking en términos de proteger un servicio con un filtrado de paquetes en un sistema con una política por defecto de INPUT a DROP. En este entorno, cualquiera que realice un escaneo a la máquina no sería capaz de detectar si un servicio está realmente activo en ella, lo cual dificulta la explotación de muchas vulnerabilidades. SPA ofrece una solución elegante las limitaciones del port knocking.
Vamos a ver mediante un ejemplo práctico, cómo utilizar fwknop en modo Single Packet Authorization para proteger y ofrecer acceso al demonio OpenSSH.
- fwknop define el siguiente formato de paquete en la capa de aplicación:
Una vez que el cliente fwknop contruye el paquete con los campos arriba indicados, el paquete entero es encriptado usando un algoritmo de clave simétrica (128 bits) o asimétrica (utilizando GnuPG con una longitud de clave de 1024 - 4096 ). Por defecto, el cliente enviará un paquete UDP al puerto 62201, aunque esto se puede modificar fácilmente (mediante el uso del parámetro --Server-port)
A continuación se muestra un ejemplo de instalación, configuración y prueba de fwknop:
Tendremos que tener instalado GnuPG tanto en el servidor como en el cliente.
- Instalamos el servidor OpenSSH
# apt-get install openssh-server
- Instalamos los requisitos para fwknop:
# apt-get install build-essential libpcap-dev mailx
- Instalamos fwknop en el servidor:
En este caso, hemos instalado la versión 1.9.2 del 12 de Marzo de 2008
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0
# sudo ./install.pl
- Nos hace una serie de preguntas a las cuales se ha contestado lo siguiente:In which mode will fwknop be executed on the local system?
(client/[server]): server
Which of the following data acquistion methods would you like to use?
([pcap], file_pcap, ulogd, syslogd, syslog-ng): pcap
Which network interface would you like fwknop to sniff packets from? eth0
Enable fwknop at boot time ([y]/n)? y
- Podemos añadir fwknop al arranque del sistema:
# update-rc.d fwknop defaults 20
- Instalamos fwknop en el cliente:
# apt-get install build-essential libpcap-dev mailx# wget http://www.cipherdyne.org/fwknop/download/fwknop-1.9.2.tar.gz (12 Mar 2008)
# tar zxvf fwknop-1.9.0.tar.gz
# cd fwknop-1.9.0
# sudo ./install.pl
En este caso, contestamos con las mismas respuestas excepto que indicamos que se instale como cliente.
- Generamos par de claves en el cliente:# gpg --gen-key
- Nosotros elegimos las siguientes opciones:
- Obtenemos:pub 1024D/A174FC70 2008-03-24
uid Server fwknop
sub 2048g/3220AE91 2008-03-24
- Exportamos la clave a un fichero# gpg -a --export A174FC70 > fwknop-client.asc
- Generamos par de claves en el servidor:# gpg --gen-key
- Obtenemos:
pub 1024D/D417D41A 2008-03-09
uid Server fwknop
sub 2048g/F5F02C2B 2008-03-09
- Exportamos la clave a un fichero:# gpg -a --export D417D41A > fwknop-server.asc
Copiamos los ficheros respectivos en las máquinas e importamos las claves.
- Importamos la clave del servidor en el cliente:# gpg --import fwknop-server.asc
# gpg --sign-key sf@sf.com
- Importamos la clave del cliente en el servidor:# gpg --import fwknop-client.asc
# gpg --sign-key cf@cf.com
- Finalizando la instalación:
- Editamos /etc/fwknop/access.conf:
SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_HOME_DIR: /root/.gnupg;
GPG_DECRYPT_ID: D417D41A;
GPG_DECRYPT_PW: password para la llave D417D41A;
GPG_REMOTE_ID: A174FC70;
FW_ACCESS_TIMEOUT: 30;
- Iniciamos fwknop:# /etc/init.d/fwknop start
- Prueba de funcionamiento:
- Ejemplo de sintaxis:
fwknop -a 'puertos' --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -s -D SERVER_IP
- Probamos con:# fwknop -a 'tcp/22' --gpg-recip D417D41A --gpg-sign A174FC70 -s -D 192.168.6.137
- Si todo ha ido bien, el servidor añade la entrada correspondiente a iptables. Ésta se mantendrá durante 60 segundos, después de los cuales se eliminará automáticamente.
En este caso, nos crea una regla que permite a la IP 192.168.6.137 conexiones tcp al puerto 22.
- Podemos comprobar que todo ha ido bien consultando los logs en el servidor SPA:# tail -f /var/log/syslog | grep fwknop
- Y cuando se acabe el tiempo disponible para realizar la conexión:
- Podemos consultar las reglas iptables en tiempo real con:# watch -n1 iptables -L -n
NOTA:
fwknop crea una nueva una nueva cadena en iptables llamada FWKNOP_INPUT y la cadena INPUT hace referencia a ésta.
En el servidor probamos poniendo la política INPUT del iptables por defecto a DROP pero no la cadena OUTPUT. Hay que tener en cuenta que fwknop, por defecto, sólo añade reglas a FWKNOP_INPUT. También se puede habilitar en fwknop.conf para que se cree utilice la cadena
FWKNOP_OUTPUT y así se creará reglas para permitir tráfico OUTPUT.
- Para que se mantenga la conexión SSH que hayamos establecido durante el tiempo permitido, tendremos que tener en iptables una regla que permita las conexiones ya establecidas. Si no, la conexión quedará cortada cuando fwknop elimine la regla correspondiente. En nuestro caso, hemos añadido:
# iptables -A INPUT -p tcp -i eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT
Referencias:
http://www.hispasec.com/unaaldia/3382
http://www.cipherdyne.org/fwknop/
http://mscoder.org/en/haking/articles_html.html
https://help.ubuntu.com/community/SinglePacketAuthorization
17.3.08
FreeRADIUS + MySQL
FreeRADIUS + MySQL
Gestión de usuarios
En el siguiente manual, vamos a ver cómo utilizar el gestor de bases de datos MySQL para administrar usuarios y grupos de usuarios de un servidor de autenticación RADIUS.
Instalamos mysql
# apt-get install mysql mysql-sever-4.1
# apt-get install freeradius-mysql
Creamos la base de datos para utilizar con radius:
mysql> create database radius;
mysql> grant all privileges on radius.* to radius@localhost;
mysql> set password for radius@localhost = old_password('radius');
Ejecutamos el script para generar tablas y demás:
primero descomprimimos en /usr/share/doc/freeradius/examples/mysql.sql
# gzip -d mysql.sql.gz
# mysql -u root -p radius < /usr/share/doc/freeradius/examples/mysql.sql
Creamos un usuario para ver si funciona:
Seguir Leyendo...
Las tablas que usa RADIUS para la gestión de usuarios son las siguientes:
usergroup: Aquí se define a qué grupo pertenece cada usuario.
Campos:
radcheck: Aquí se definen las contraseñas de cada usuario.
Campos:
radreply: En esta tabla se definen los atributos sobre la conexión y sesión de los usuarios; por ejemplo, IP asignada y tiempo de espera máximo. En nuestro caso, permitimos que se asignen los de DEFAULT contenidos en el archivo ‘users’; por lo tanto, no insertamos nada en la tabla.
radgroupreply: Similar a radcheck pero permite establecer atributos a un grupo de usuarios completo.
Campos:
Nosotros sólo hicimos uso de uno, el tipo de autenticación: ‘Auth-Type’.
Op. Es el operador que se usará para la comprobación. Para nosotros ‘:=’.
Value. El valor del atributo. Nuestro Auth-Type es ‘EAP’.
Creamos usuario usuario_admin en el grupo admin:
mysql> insert into usergroup values ('usuario_admin','admin','');
Añadimos la contraseña para el usuario admin:
mysql> insert into radcheck values ('','usuario_admin','Password','==','[password]');
Añadimos el atributo local al grupo admin: (no es necesario)
mysql> insert into radgroupcheck values ('','admin','Auth-Type',':=','local');
Esteblecemos atributos del grupo admin
mysql> insert into radgroupreply values ('', 'admin', 'Framed-Protocol', ':=', 'PPP');
mysql> insert into radgroupreply values ('', 'admin', 'Service-Type', ':=', 'Framed-User');
mysql> insert into radgroupreply values ('', 'admin', 'Framed-Compression', ':=', 'Van-Jacobsen-TCP-IP')
Configuramos RADIUS para que gestione los ususarios con MySQL:
Editamos /usr/local/etc/raddb/clients.conf y configuramos las IPs o subrredes desde las que se aceptarán peticiones. En este caso, además de localhost, se aceptarán peticiones de un AP con IP 192.168.6.1:
client 127.0.0.1{
ipaddr = 127.0.0.1
secret = secretradius
shorname = AP
nastype = other
}
client 192.168.6.1{
ipaddr = 192.168.6.1
secret = secretradius
netmask = 32
shortname = windows
nastype = other
}
Ahora editamos /usr/local/etc/raddb/clients.conf para indicar a RADIUS IP del servidor MySQL, usuario y password:
# Connect info
server = "localhost"
login = "radius"
password = "password_basededatos"
# Database table configuration
radius_db = "radius"
A continuación editamos /usr/local/etc/raddb/sites-avaliable/default y terminamos de configurar los parámetros necesarios:
authorize {
preprocess
chap
mschap
suffix
eap
sql
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
}
preacct {
preprocess
acct_unique
suffix
}
accounting {
detail
radutmp
sql
}
session {
radutmp
sql
}
post-auth {
sql
}
pre-proxy {
}
post-proxy {
eap
}
Si el servidor mysql está en otro host, en /etc/mysql/my.cnf parcheamos la linea bind-address=127.0.0.1
(Al arrancar el servicio radiusd -X me daba error con el puerto 1812 y he tenido que detener los servicios smb)
A mí me ha dado error en una tabla y he tenido que modificar las columnas de la tabla radpostauth:
mysql> alter table radpostauth change user username varchar(64);
mysql> alter table radpostauth change date authdate timestamp;
En el sql.conf he desparcheado el parámetro read_groups y lo he puesto a "no" porque me daba error con una tabla que no existía que hacía referencia a los grupos
Para exportar/importar bade de datos (por si hicera falta):
Para exportar la base de datos radius:
# mysqldump -u [user] -p --opt [nombre_db] > fichero.sql
Para importarla:
Primero la creamos
# mysql -u [user] -p
mysql> create database radius;
mysql> \q
# mysql -u [user] -p [nombre_db] <>
Podemos instalar phpmyadmin para gestionar MySQL
# apt-get install phpmyadmin
Yo he tenido un problema con la configuración y he tenido que hacer lo siguiente:
He cambiado el fichero /var/www/phpmyadmin/config.inc.php porque me daba un error de blowfish, lo que he hecho es cambiarlo por config.sample.inc.php y en este último he borrado el valor del parámetro "controluser" y el de "controlpass" y los he dejado vacíos.
Así ya me ha funcionado.
Podremos instalar phpmyadmin para gestionar via web MySQL y poder administrar los usuarios más fácilmente:
# apt-get install phpmyadmin
Nos muestra un asistente durante la instalación para configurar phpmyadmin automáticamente. Primero nos pregunta qué servidor web esatmos utilizando, en nuestro caso indicamos apache2 (aunque es altamente recomendable utilizar apache-ssl).
Indicamos el usuario para el sitema de configuración ("admin" por defecto) e indicamos la contraseña.
Reiniciamos apache y accedemos desde un navegador a https://[ip_servidor]/phpmyadmin
Cuando accedemos, podremos encontrarnos con un error que nos dice que necesitamos configurar una clave secreta blowfish (algoritmo de cifrado simétrico que utiliza una passprhase para encriptar el password)
En realida lo que tenemos que hacer es modificar los permisos de los ficheros:
/etc/phpmyadmin/blowfish_secret.inc.php
/etc/phpmyadmin/htpasswd.setup
Es recomendable cambiar la passphrase que viene por defecto ya que por defecto les asigna el grupo www-data y nosotros usamos el usuario y grupo httpd:
# chown root:httpd blowfish_secret.inc.php
# chown root:httpd htpasswd.setup
Ya podemos acceder con un usuario que tenga privilegios en la base de datos. Por ej. root.
Ahora desde phpmyadmin podremos añadir usuarios.
Sólo hay que añadir un registro en usergroup y otro en radcheck por cada usuario (ver imagen).
14.3.08
Instalación y configuración de SNORT en sistemas basados en Debian
SNORT es un sistema open source de detección de intrusos (IDS) y un sistema de prevención de intrusos (IPS) capaz de realizar análisis en tiempo real de tráfico en redes IP. Actualmente se encuentra desarrollo por parte de Sourcefire.
SNORT realiza análisis de portocolos y es usado habitualmente para boquear o detectar gran variedad de ataques y pruebas como buffer overflows, escaneos de puertos, ataques a aplicaciones web, intentos de OS fingerpirnting, etc.
Este manual, es una adaptación del documento "11 step guide to build a Debian based Intrusion
Detection Sensor (IDS) with Snort 2.4.5 or Snort 2.6" que se puede encontrar en www.snort.org
Solución basada en Snort+MySQL+PHP+BASE+Apache-SSL.
Se ha utilizado una versión estable Debian 2.6.
Instalamos todos los paquetes necesarios para esta guía:
# apt-get update
# apt-get install ssh
# apt-get install apache-ssl apache-common libapache-mod-php4 \
mysql-server mysql-common mysql-client php4-mysql \
libnet1 libnet1-dev libpcre3 libpcre3-dev autoconf automake1.9 \
libpcap0.8 libpcap0.8-dev libmysqlclient15-dev \
php4-gd php4-pear libphp-adodb vim gcc make \
php4-cli libtool libssl-dev gcc-4.1 g++
Al instlar el apache-ssl nos pedirá los parámetros para configurar el certificado que usará.
A continuación se nos sugiere instalar el firewall lokkit por su sencillez. Obviamos este paso.
Descargamos e instalamos SNORT:
Seguir Leyendo...
Instalamos en este caso la versión 2.8.0.1 (28 de Noviembre de 2007)
La última versión estable a día 12 de Marzo es 2.8.0.2 (19 de Febrero de 2008) y la podemos descargar desde: http://www.snort.org/dl/current/snort-2.8.0.2.tar.gz
# cd /usr/local/src
# wget http://snort.org/dl/old/snort-2.8.0.1.tar.gz
# tar xvzf snort-2.8.0.1.tar.gz
# cd snort-2.8.0.1
# ./configure --with-mysql --enable-dynamicplugin
# make
# make install
Instalamos y configuramos las reglas:
Las reglas VRT (Sourcefire Vulnerability Research Team), son las reglas que desarrolla el equipo de soporte de SNORT. Hay tres tipos de reglas VRT que podremos encontrar en el portal www.snort.org.
Descargamos las reglas para la versión 2.8 (tipo 2 :)) en http://www.snort.org/pub-bin/downloads.cgi
Nos registramos y generamos un oink-code -> ...64188359a0f2248... para poder descargarlas.
En este caso las hemos descargado en el directorio /root:
# cd /etc/snort
# mv /root/snortrules-snapshot-2.8.0.1.tar.gz .
# tar xvzf snortrules-snapshot-2.8.0.1.tar.gz MD5 -> 61b7818176609e8753bb10b98ae9a820
# cp /usr/local/src/snort-2.8.0.1/etc/*.conf* .
# cp /usr/local/src/snort-2.8.0.1/etc/*.map .
Configuramos /etc/snort/snort.conf:
var RULE_PATH /etc/snort/rules
var HOME_NET 192.168.1.0/24
var EXTERNAL_NET !$HOME_NET
Podemos crear una regla sencilla para comprobar... (ToDo)
Levantamos snort con:
# /usr/local/bin/snort -Dq -u snort -g snort -c /etc/snort/snort.conf
-c fichero de configuración
-D Ejecuta Snort en modo demonio
-g Indica el grupo (elimina privilegios de root a Snort después de terminar su inicialización)
-q Modo Quiet. No muestra información de inicialización ni banner.
Si tenemos apache2 previamente instalado, podemos tener problemas entre el apache2 y apache-ssl
Configuramos MYSQL:
Ponemos password a root de mysql si no lo tiene ya:
# mysqladmin -u root password "password"
Iniciamos mysql:
# mysql -u root -p
Creamos la BD snort:
mysql> create database snort;
Creamos un usuario "snort" en la BD y le asignamos permisos:
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;
Le asignamos un password.
mysql> SET PASSWORD FOR snort@localhost=PASSWORD('password');
Ejecutamos el script que creará las tablas de la BD snort:
# cd /usr/local/src/snort-2.8.0.1/schemas
# mysql -u root -p <>
Configuramos snort para que utilice mysql:
Editamos /etc/snort/snort.conf y buscamos, descomentamos y configuramos la linea:
output database: log, mysql, user=snort password=mipass dbname=snort host=localhost
Reiniciamos snort
# kill -9 pid
Hacemos un escaneo a la máquina con nmap por ej. y comprobamos que ha guardado algún evento con:
# mysql -u root -p -D snort -e "select count(*) from event"
Configuramos apache-ssl:
Si tenemos apache2 instalado, deberemos eliminarlo del arranque.
Para ésto, podemos poner:
# update-rc.d -f apache2 remove
Editamos /etc/apache-ssl/httpd.conf
Buscamos y descomentamos:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Editamos /etc/php4/apache/php.ini y descomentamos:
extension=mysql.so
Reiniciamos apache:
/etc/init.d/apache-ssl restart
Instalamos BASE (Basic Analysis and Security Engine. Front-end web para analizar alertas del snort):
# cd /var/www
# rm index.html (opcional)
# wget http://internap.dl.sourceforge.net/sourceforge/secureideas/base-1.2.5.tar.gz
# tar xvzf base-1.2.5.tar.gz
# mv base-1.2.5 base
# chmod 777 base
Abrimos un navegador y escribimos en la barra de direcciones https://[ip_servidor]/base
Pulsamos continue, elegimos idioma y ponemos como path del adodb -> /usr/share/php/adodb
Pulsamos "continue".
Introducimos los siguientes parámetros:
Database Name: snort
Database Host: localhost
Database Port: (en blanco para puerto por defecto)
Database User Name: snort
Database Password: pass
Pulsamos "continue":
Introducimos usuario -> root y su contraseña, y nada más (tampoco marco el check).
Pulsamos "continue":
Pulsamos sobre el botón "create baseag" y nos informa de si se ha creado todo correctamente.
Pulsamos "Ir al paso 5"
Y ya lo tenemos funcionando...
Cambiamos permisos al directorio base:
# chmod 755 /var/www/base
Para que funcionen las gráficas:
Cambiamos el siguiente enlace:
# rm /etc/alternatives/php
# ln -s /usr/bin/php4 /etc/alternatives/php
Ejecutamos:
# pear config-set preferred_state alpha
Editamos /etc/php4/cli/php.ini y descomentamos:
extension=gd.so
Ejecutamos:
# pear install Image_Color
# pear install Image_Canvas
# pear install Image_Graph
Reiniciamos apache-ssl.
Barnyard (programa para procesar logs de eventos de forma unificada, mejora el rendimiento de snort y proporciona tolerancia a fallos en caso de caída de la BBDD)
En este caso no lo instalamos.
Pasando del banyard
Configuramos actualizaciones de las reglas:
Descargamos e instalamos oinkmaster para que haga actualizaciones automáticas de las reglas:
# cd /usr/local/src
# wget http://internap.dl.sourceforge.net/sourceforge/oinkmaster/oinkmaster-2.0.tar.gz
# tar xvzf oinkmaster-2.0.tar.gz
# cd oinkmaster-2.0
# cp oinkmaster.pl /usr/local/bin
# mkdir /usr/local/etc
# cp oinkmaster.conf /usr/local/etc
Editamos /usr/local/etc/oinkmaster.conf y nos vamos a la linea:
#Example for Snort-current...
Y descomentamos la siguiente linea:
url = http://www.snort.org/pub-bin/oinkmaster.cgi/oinkcode/filename
Sustituimos [b]oinkcode[/b] por uno válido: ...64188359a0f22...
A continuación hacemos:
# mkdir /tmp/oinktest
# /usr/local/bin/oinkmaster.pl -o /tmp/oinktest
Si todo va bien nos descargará más reglas, las desempaquetará e instalará...
Podemos añadir una copia de seguridad de las reglas antes de instalarlas con la opción -b (sin probar)
# mkdir /tmp/OINKBACK por ej
# /usr/local/bin/oinkmaster.pl -o /tmp/oinktest -b /tmp/OINKBACK
Ésto, hará una copia de las reglas en OINKBACK antes de instalar las nuevas.
Creamos el script de inicio de SNORT:
Creamos y editamos /etc/init.d/snort
Añadimos al fichero lo siguiente:
#!/bin/bash
/sbin/ifconfig eth0 up
/usr/local/bin/snort -Dq -u snort -g snort -c /etc/snort/snort.conf -i eth1
Lo hacemos ejecutable:
#chmod +x /etc/init.d/snort-barn
Utilizamos update-rc.d will para crear los enlaces en los directorios rc?.d:#update-rc.d snort defaults 95
Reiniciamos y comprobamos que todo funciona correctamente
FINE