Escrito por Foron el 14 de Noviembre de 2008 y etiquetado como: Seguridad, Sistemas
En mi primer artículo sobre ossec he mostrado los pasos para hacer una instalación básica y completamente estándar de ossec. En este artículo vamos a ver lo que hay por debajo del software.
Ossec usa tres componentes: un detector de rootkits, una herramienta para revisar la integridad del sistema, y el analizador de logs. Todas ellas se configuran en el fichero ossec.conf.
Este fichero de configuración tiene una estructura muy clara, en formato xml, en el que se definen varios bloques.
En este artículo sólo voy a dar algunas ideas básicas sobre el formato con el que se definen las reglas que describen los eventos detectables en los logs.
Tanto el chequeo de integridad como el detector de rootkits se configuran de una forma muy similar, así que lo dejaré para que quien quiera se pelee con ello.
En ossec.conf se definen los logs que se quieren monitorizar dentro de secciones “localfile”. Un ejemplo:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/auth.log</location>
</localfile>
En este caso se dice que queremos vigilar auth.log, del tipo syslog. Existen varios formatos definidos, como apache o snort-full, por citar dos ejemplos. Syslog se usa en los casos en los que se loguea un único evento por linea. Sort-full, por poner otro ejemplo, está adaptado al tipo de log que deja snort cuando usa el formato de salida full.
Una vez definidos los formatos, empezamos a hablar de reglas. El primer paso es que ossec detecte qué tipo de entrada de log es. Para esto se usan los decoders (decoder.xml) Veamos un ejemplo.
<decoder name="sshd">
<program_name>^sshd</program_name>
</decoder>
Este decoder “se activa” cuando la entrada de log es generada por el programa sshd (sshd[5493] en el siguiente ejemplo):
Feb 3 19:22:33 server sshd[5493]: Accepted publickey for prueba from 192.168.10.2 port 50560 ssh2
Pero, a pesar de la importancia de esta sencilla regla (después veremos por qué), necesitamos extender el decoder para que sea útil.
<decoder name="ssh-failed">
<parent>sshd</parent>
<prematch>^Failed \S+ </prematch>
<regex offset="after_prematch">^for (\S+) from (\S+) port \d+ \w+$</regex>
<order>user, srcip</order>
</decoder>
Gracias a la primera y simple regla “sshd” nos aseguramos que ossec sólo va a analizar la entrada de log contra esta segunda regla, mucho más compleja, si dicho log está relacionado con ssh. Esto es una gran mejora en el rendimiento del sistema.
Sin entrar en explicaciones detalladas, esta regla se cumple con este tipo de log:
Jul 26 22:06:10 server sshd[3727]: Failed password for prueba from 192.168.10.2 port 50519 ssh2
Y además crea dos “variables”; una con el usuario que ha intentado conectarse y otra con la IP origen.
Teniendo estos datos ya podemos empezar con las reglas “de verdad”. Veamos algo del fichero sshd_rules.xml
<rule id="5700" level="0" noalert="1">
<decoded_as>sshd</decoded_as>
<description>SSHD messages grouped.</description>
</rule>
<rule id="5716" level="5">
<if_sid>5700</if_sid>
<match>^Failed|^error: PAM: Authentication</match>
<description>SSHD authentication failed.</description>
<group>authentication_failed,</group>
</rule>
De manera similar a los decoders, se define una primera regla básica para ssh, que ayudará a ossec en no tener que analizar reglas de apache (por ejemplo) en logs de ssh.
La segunda regla (5716) generará una alerta de nivel 5 cuando haya un intento de login erróneo.
Pero también se pueden crear reglas compuestas que activarán alertas de mayor nivel si hay x intentos fallidos desde una misma IP
<rule id="5720" level="10" frequency="6">
<if_matched_sid>5716</if_matched_sid>
<same_source_ip />
<description>Multiple SSHD authentication failures.</description>
<group>authentication_failures,</group>
</rule>
Gracias al formato xml es muy sencillo añadir nuevas reglas. También se pueden enviar correos con las alertas a cuentas de correo diferentes en base, por ejemplo, al agente que ha generado la alerta o al nivel de la misma.
En el tercer y último artículo de la serie vamos a integrar ossec con psad.
Escrito por The Evangelist el 13 de Noviembre de 2008 y etiquetado como: Aplicaciones, Networking, OSX, Seguridad, VPN
Una de las cosas que hecho de menos en OSX con respecto a la versión Server es que está última viene con un servidor de VPNs integrado en el sistema con lo cual podemos conectarnos a nuestra red desde internet de forma segura con un VPN.
Después de mucho buscar he encontrado esta aplicación iVPN que hace lo mismo, es decir, crea un servidor de VPNs ya sea PPTP o L2TP. Aunque la aplicación es de pago (14,99 libras) es de gran utilidad, es muy simple y sencilla y funciona de maravilla.
Solo tenemos que configurar uno pocos campos y tendremos listo nuestro servidor de VPNs.
- Ip Address Range: es el rango de IPs que se asignarán a los clientes que se conecten a nuestra VPN/red
- Router: es la IP de nuestro router que será el gateway,
- Subnet Mask: es la máscara de red de nuestra red.
- Primary DNS Server: la IP del DNS primario
- Secondary DNS Server: la IP del DNS secundario
Luego debes pinchar uno de los 2 botones o PPTP o L2TP. PPTP es más común y sencillo auqnue algo menos seguro y L2TP aunque es un poco más seguro es menos común y suele dar más problemas.
Pinchamos el botón Edit Accounts para añadir usuarios que pueden conectarse a nuestra VPN:
- User Name: nombre de usuario
- Password: contraseña
- Botón Add: para añadir el usuario
- Botón Remove: para borrar el usuario seleccionado de la lista de la izquierda
- Botón Done: para terminar y volver a la pantalla anterior.
Una vez con todo solo queda activar el servidor de VPN pulsando el botón ON.
Página principal: http://www.macserve.org.uk/projects/ivpn/
Precio: 14,99 libras
Escrito por Foron el 11 de Noviembre de 2008 y etiquetado como: Networking, Seguridad
Antes de seguir con el segundo post sobre ossec, voy a dar un par de pistas sobre cómo ver el tráfico que pasa por una sesión tcp. Esto sí que es todo un mundo, así que me limito, como casi siempre, a dar cuatro detalles para que quien quiera se haga una idea de lo que se puede hacer y siga investigando.
Por supuesto, el que se pueda “espiar” lo que se está trasmitiendo no significa que debamos (ni podamos) hacerlo, al menos si no queremos tener problemas legales.
Vamos a empezar por lo básico. Necesitamos capturar tráfico para poderlo analizar después con cierta tranquilidad. Para esto usamos el conocido tcpdump, aunque podemos usar otros, como por ejemplo, snort.
tcpdump -n -i eth1 -s 1515 -U -w /tmp/captura.pcap '(tcp port 20) or (tcp port 21) or (tcp port 25)'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 1515 bytes
Para saber lo que hacen los parámetros nada mejor que el manual 
Dejamos esta terminal abierta y con el comando en ejecución. Vamos a ir analizando lo que se vuelca en captura.pcap en otra terminal.
Primera prueba.
Desde otra máquina vamos a hacer un telnet al puerto 25 y a mandar un correo.
telnet 192.168.10.1 25
Trying 192.168.10.1...
Connected to 192.168.10.1.
Escape character is '^]'.
220 smtp.example.com ESMTP Postfix
helo prueba.example.com
250 smtp.example.com
rset
250 2.0.0 Ok
helo prueba.example.com
250 smtp.example.com
mail from: prueba@example.com
250 2.1.0 Ok
rcpt to: prueba1@example.com
250 2.1.5 Ok
data
354 End data with .
Subject: Titulo del correo
Este texto se ve en la captura
.
250 2.0.0 Ok: queued as 1F7426C420
quit
221 2.0.0 Bye
Connection closed by foreign host.
Nuestro volcado tiene datos…. vamos a ver que tiene usando tcpflow.
# tcpflow -r captura.pcap -c port 25
192.168.010.001.00025-192.168.010.002.41403: 220 smtp.example.com ESMTP Postfix
192.168.010.002.41403-192.168.010.001.00025: helo prueba.example.com
192.168.010.001.00025-192.168.010.002.41403: 250 smtp.example.com
192.168.010.002.41403-192.168.010.001.00025: rset
192.168.010.001.00025-192.168.010.002.41403: 250 2.0.0 Ok
192.168.010.002.41403-192.168.010.001.00025: helo prueba.example.com
192.168.010.001.00025-192.168.010.002.41403: 250 smtp.example.com
192.168.010.002.41403-192.168.010.001.00025: mail from: prueba@example.com
192.168.010.001.00025-192.168.010.002.41403: 250 2.1.0 Ok
192.168.010.002.41403-192.168.010.001.00025: rcpt to: prueba1@example.com
192.168.010.001.00025-192.168.010.002.41403: 250 2.1.5 Ok
192.168.010.002.41403-192.168.010.001.00025: data
192.168.010.001.00025-192.168.010.002.41403: 354 End data with .
192.168.010.002.41403-192.168.010.001.00025: Subject: Titulo del correo
192.168.010.002.41403-192.168.010.001.00025: Este texto se ve en la captura
192.168.010.002.41403-192.168.010.001.00025: .
192.168.010.001.00025-192.168.010.002.41403: 250 2.0.0 Ok: queued as 1F7426C420
192.168.010.002.41403-192.168.010.001.00025: quit
192.168.010.001.00025-192.168.010.002.41403: 221 2.0.0 Bye
Sorpresa, tcpflow ha generado, en esta caso por salida estándar (-c), todo lo que ha sido capturado en el puerto 25.
Segunda prueba.
Bien, vamos con algo un poco diferente, pero igual de fácil (recordad que esto no son más que ideas)
Ahora vamos a suponer que he programado un rootkit que se llama exploit, y que lo voy a subir por ftp a la máquina que estamos monitorizando.
ftp 192.168.10.1
Connected to 192.168.10.1.
220 Este es un servidor privado. Por favor cierre la sesion inmediatamente.
Name (192.168.10.1:prueba):
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put exploit
local: exploit remote: exploit
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 File receive OK.
101992 bytes sent in 0.00 secs (29433.1 kB/s)
ftp> quit
221 Goodbye.
Muy bien, ahora veamos lo que tenemos, empezando por el puerto 21, y después por el 20.
# tcpflow -r captura.pcap -c port 21
192.168.010.001.00021-192.168.010.002.50427: 220 Este es un servidor privado. Por favor cierre la sesion inmediatamente.
192.168.010.002.50427-192.168.010.001.00021: USER prueba
192.168.010.001.00021-192.168.010.002.50427: 331 Please specify the password.
192.168.010.002.50427-192.168.010.001.00021: PASS secreto
192.168.010.001.00021-192.168.010.002.50427: 230 Login successful.
192.168.010.002.50427-192.168.010.001.00021: SYST
192.168.010.001.00021-192.168.010.002.50427: 215 UNIX Type: L8
192.168.010.002.50427-192.168.010.001.00021: TYPE I
192.168.010.001.00021-192.168.010.002.50427: 200 Switching to Binary mode.
192.168.010.002.50427-192.168.010.001.00021: PORT 192,168,10,2,205,32
192.168.010.001.00021-192.168.010.002.50427: 200 PORT command successful. Consider using PASV.
192.168.010.002.50427-192.168.010.001.00021: STOR exploit
192.168.010.001.00021-192.168.010.002.50427: 150 Ok to send data.
192.168.010.001.00021-192.168.010.002.50427: 226 File receive OK.
192.168.010.002.50427-192.168.010.001.00021: QUIT
192.168.010.001.00021-192.168.010.002.50427: 221 Goodbye.
Vamos a hacer ahora que tcpflow genere un fichero con el tráfico del puerto 20. Para esto quitamos el parámetro -c.
# tcpflow -r captura.pcap port 20
# file 192.168.010.002.52512-192.168.010.001.00020
192.168.010.002.52512-192.168.010.001.00020: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
Sorpresa, tenemos un fichero binario ….. con el exploit. Bueno, en realidad en una copia de /bin/ls, pero vale para el ejemplo
# strings 192.168.010.002.52512-192.168.010.001.00020
.......
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
-a, --all do not ignore entries starting with .
-A, --almost-all do not list implied . and ..
--author with -l, print the author of each file
-b, --escape print octal escapes for nongraphic characters
--block-size=SIZE use SIZE-byte blocks
.......
¿Qué pasa en la realidad, cuando tenemos cientos o miles de sesiones de correo o ftp y queremos ver una concreta? Por un lado debemos guardar el tráfico que queremos investigar, claro, pero luego debemos saber qué sesiones se han establecido, a qué hora, cuánto tráfico ha pasado por ellas, entre que puertos, …. Para esto hay mucho software, pero un buen ejemplo es argus. A partir de aquí, podemos generar expresiones más elaboradas para usar en tcpflow (algo más que “port 20″)
Escrito por Foron el 3 de Noviembre de 2008 y etiquetado como: Seguridad, Sistemas
En el mundo del software libre hay multitud de proyectos que, debido a su calidad, han terminado siendo comprados por empresas para ser usados como parte de sus soluciones comerciales. Dos ejemplos son sguil y ossec.
En la próxima serie de dos artículos voy a comentar muy por encima lo principal de ossec.
Ossec es un proyecto relacionado con la seguridad informática, y particularmente con lo que se suele llamar HIDS. Dicho de otra forma, y simplificando mucho, se trata de una aplicación que monitoriza una máquina, y que detecta las anomalías que puedan producirse en el sistema. Para hacer esto usa sobre todo una herramienta para la detección de rootkits, otra para revisar la integridad de ficheros y ejecutables del sistema, y por último un potente sistema para analizar logs.
En cuanto a la arquitectura del sistema, usa básicamente un modelo de servidor/agentes, con lo que tendremos una máquina (servidor) encargada de recibir y actuar en base a la información que reciba de los agentes que, en definitiva, son las máquinas que están siendo monitorizadas. La forma de actuar del servidor es, por una parte, enviando notificaciones, y por otro lado, si así se configura, generando reglas firewall que se ejecutarán en los propios agentes.
Este primer artículo sólo va a describir la instalación de ossec. Dejamos para artículos posteriores la configuración.
La instalación de ossec es muy sencilla. Es suficiente con ejecutar el típico install.sh del fichero de instalación que se puede descargar desde la web.
sh install.sh
Una vez seleccionamos el idioma de instalación empieza el tema.
1- What kind of installation do you want (server, agent, local or help)? server
- Server installation chosen.
2- Setting up the installation environment.
- Choose where to install the OSSEC HIDS [/var/ossec]: /usr/local/ossec-1.6
- Installation will be made at /usr/local/ossec-1.6 .
3- Configuring the OSSEC HIDS.
3.1- Do you want e-mail notification? (y/n) [y]:
- What's your e-mail address? zzz@yyyyyyy.net
- We found your SMTP server as: mail.yyyyyyy.net.
- Do you want to use it? (y/n) [y]:
--- Using SMTP server: mail.yyyyyyy.net.
3.2- Do you want to run the integrity check daemon? (y/n) [y]:
- Running syscheck (integrity check daemon).
3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
- Running rootcheck (rootkit detection).
3.4- Active response allows you to execute a specific
command based on the events received. For example,
you can block an IP address or disable access for
a specific user.
More information at:
http://www.ossec.net/en/manual.html#active-response
- Do you want to enable active response? (y/n) [y]: n
- Active response disabled.
3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]:
- Remote syslog enabled.
3.6- Setting the configuration to analyze the following logs:
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/syslog
-- /var/log/vsftpd.log
-- /var/log/mail.info
-- /var/log/dpkg.log
-- /var/log/snort/alert (snort-full file)
-- /var/log/apache2/error.log (apache log)
-- /var/log/apache2/access.log (apache log)
- If you want to monitor any other file, just change
the ossec.conf and add a new localfile entry.
Any questions about the configuration can be answered
by visiting us online at http://www.ossec.net .
--- Press ENTER to continue ---
A partir de aquí empieza a compilar los distintos componentes. He elegido una instalación para el servidor que recibirá los eventos, y he activado tanto la detección de rootkits como la revisión de integridad, pero he dejado sin activar la respuesta activa, que básicamente se trata de añadir entradas a hosts.deny y reglas de firewall.
El syslog remoto lo vamos a usar para recibir mensajes desde los agentes.
Por cierto, mientras escribía estas líneas el sistema se ha terminado de compilar:
- System is Debian (Ubuntu or derivative).
- Init script modified to start OSSEC HIDS during boot.
- Configuration finished properly.
- To start OSSEC HIDS:
/usr/local/ossec-1.6/bin/ossec-control start
- To stop OSSEC HIDS:
/usr/local/ossec-1.6/bin/ossec-control stop
- The configuration can be viewed or modified at /usr/local/ossec-1.6/etc/ossec.conf
Thanks for using the OSSEC HIDS.
If you have any question, suggestion or if you find any bug,
contact us at contact@ossec.net or using our public maillist at
ossec-list@ossec.net
( http://www.ossec.net/main/support/ ).
More information can be found at http://www.ossec.net
--- Press ENTER to finish (maybe more information below). ---
A partir de aquí, por un lado tendremos que configurar ossec (ossec.conf), y después tendremos que ir añadiendo los agentes con la utilidad /usr/local/ossec-1.6/bin/manage_agents.
Vamos a arrancar el servidor y a añadir un par de agentes, uno en linux y otro en windows. Bueno, el agente windows no lo voy a documentar aquí. Tiene un instalador gráfico que se descarga desde la web, y los pasos son muy similares.
/usr/local/ossec-1.6/bin/ossec-control start
Starting OSSEC HIDS v1.6 (by Third Brigade, Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.
# ps aux | grep osse
ossecm 5579 0.0 0.0 2076 528 ? S 17:45 0:00 /usr/local/ossec-1.6/bin/ossec-maild
ossec 5587 0.0 0.1 2664 1312 ? S 17:45 0:00 /usr/local/ossec-1.6/bin/ossec-analysisd
root 5591 0.0 0.0 1796 468 ? S 17:45 0:00 /usr/local/ossec-1.6/bin/ossec-logcollector
root 5603 2.5 0.0 1944 512 ? D 17:45 0:04 /usr/local/ossec-1.6/bin/ossec-syscheckd
ossec 5607 0.0 0.0 1980 480 ? S 17:45 0:00 /usr/local/ossec-1.6/bin/ossec-monitord
ossecm 5610 0.0 0.0 2076 300 ? S 17:45 0:00 /usr/local/ossec-1.6/bin/ossec-maild
# ./manage_agents
***********************************************
* OSSEC HIDS v1.6 Agent manager. *
* The following options are available: *
***********************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: A
- Adding a new agent (use '\q' to return to the main menu).
Please provide the following:
* A name for the new agent: agente1
* The IP Address of the new agent: 172.17.0.131
* An ID for the new agent[001]:
Agent information:
ID:001
Name:agente1
IP Address:172.17.0.131
Confirm adding it?(y/n): y
Agent added.
# ./manage_agents
***********************************************
* OSSEC HIDS v1.6 Agent manager. *
* The following options are available: *
***********************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: E
Available agents:
ID: 001, Name: agente1, IP: 172.17.0.131
Provide the ID of the agent to extract the key (or '\q' to quit): 001
Agent key information for '001' is:
XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=
** Press ENTER to return to the main menu.
Y ya está. Ahora sólo queda instalar el agente en el servidor a monitorizar. La clave se usa para la comunicación agente/servidor.
# ./install.sh
...
1- What kind of installation do you want (server, agent, local or help)? agent
- Agent(client) installation chosen.
2- Setting up the installation environment.
- Choose where to install the OSSEC HIDS [/var/ossec]: /usr/local/ossec-1.6
- Installation will be made at /usr/local/ossec-1.6 .
3- Configuring the OSSEC HIDS.
3.1- What's the IP Address of the OSSEC HIDS server?: 172.17.0.1
- Adding Server IP 172.17.0.1
3.2- Do you want to run the integrity check daemon? (y/n) [y]:
- Running syscheck (integrity check daemon).
3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
- Running rootcheck (rootkit detection).
3.4 - Do you want to enable active response? (y/n) [y]: n
- Active response disabled.
3.5- Setting the configuration to analyze the following logs:
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/syslog
-- /var/log/mail.info
-- /var/log/dpkg.log
- If you want to monitor any other file, just change
the ossec.conf and add a new localfile entry.
Any questions about the configuration can be answered
by visiting us online at http://www.ossec.net .
--- Press ENTER to continue ---
Y ahora copiamos la clave pública que antes hemos sacado del servidor:
./bin/manage_agents
***********************************************
* OSSEC HIDS v1.6 Agent manager. *
* The following options are available: *
***********************************************
(I)mport key from the server (I).
(Q)uit.
Choose your action: I or Q: I
* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.
Paste it here (or '\q' to quit): XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=
Agent information:
ID:001
Name:agente1
IP Address:172.17.0.131
Confirm adding it?(y/n): y
Added.
** Press ENTER to return to the main menu.
Arrancamos el agente… y ya está.
/usr/local/ossec-1.6/bin/ossec-control start
Y no hay nada más que hacer para tener lo básico de ossec. Por supuesto, todo es muy configurable, y ampliable en base a lo que cada uno necesite.
Desde otra máquina, me intento conectar digamos que 10 veces usando ssh con usuarios invalidos….. sorpresa, recibo este correo.
OSSEC HIDS Notification.
2008 Sep 21 22:30:40
Received From: (agente1) 172.17.0.131->/var/log/auth.log
Rule: 5712 fired (level 10) -> "SSHD brute force trying to get access to the system."
Portion of the log(s):
Sep 21 19:06:32 fn131 sshd[5990]: Invalid user aaaaab from 172.17.0.2
Sep 21 19:06:26 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:23 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:21 fn131 sshd[5986]: Failed none for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:21 fn131 sshd[5986]: Invalid user aaaaa from 172.17.0.2
Sep 21 19:06:09 fn131 sshd[5984]: Failed password for invalid user aaaah from 172.17.0.2 port 39009 ssh2
Sep 21 19:06:06 fn131 sshd[5984]: Failed none for invalid user aaaah from 172.17.0.2 port 39009 ssh2
Algunos ejemplos con distintos tipos de eventos:
OSSEC HIDS Notification.
2008 Oct 09 21:29:03
Received From: servidor->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):
Integrity checksum changed for: '/etc/dovecot/dovecot.conf'
Size changed from '45438' to '45460'
Old md5sum was: 'bd5c81584dad9725045ec0e52eb0c15c'
New md5sum is : '439061951cdeb975c21d37b4cc5f8649'
Old sha1sum was: '8d7ade9a74b9e8ff4d6758c14bdb070ccb15b198'
New sha1sum is : '8e7d34ba6328a1e5d38645972b369e700f7d05b2'
--END OF NOTIFICATION
OSSEC HIDS Notification.
2008 Oct 07 18:29:00
Received From: servidor->/var/log/dpkg.log
Rule: 2902 fired (level 7) -> "New dpkg (Debian Package) installed."
Portion of the log(s):
2008-10-07 18:29:00 status installed unzip 5.52-12
--END OF NOTIFICATION
OSSEC HIDS Notification.
2008 Oct 05 17:42:23
Received From: agente1->/var/log/messages
Rule: 5104 fired (level 8 ) -> "Interface entered in promiscuous(sniffing) mode."
Portion of the log(s):
Oct 5 17:42:21 nurn kernel: device lo entered promiscuous mode
--END OF NOTIFICATION
En el próximo artículo veremos un poco sobre la configuración de todas estas reglas.
Escrito por The Evangelist el 1 de Noviembre de 2008 y etiquetado como: Linux, Revistas, Seguridad, Sistemas
Este artículo fue publicado en la revista Linux+ Julio/Agosto 2007 (Nº 34) (Web de la revista) y que amablemente me han cedido y dado permiso para publicarlo. El artículo está escrito por Alberto Permuy Leal.
La implementación de un proxy en la red del cliente es un paso inicial y que, con frecuencia, viene a solucionar muchos problemas de seguridad y saturación de comunicaciones, siendo habitual la existencia de organizaciones que han estado incrementando previamente sus comunicaciones contratadas con un ISP sin saber muy bien porqué, lo único que saben es que los anchos de banda se acaban agotando, los problemas de virus y ataques persisten y las comunicaciones siempre se quedan cortas.
Por ello, una primera tarea puede ser la de instalar un proxy, con el fin de solucionar un primer problema. Como veremos en estas páginas, SQUID, como otros, nos permitirá comenzar a organizar los dos ámbitos de las comunicaciones de la PYME, el tramo Internet, optimizando el mismo y la demanda que la red realiza sobre las comunicaciones, y el tramo de los usuarios, comenzando a organizar el uso que dan los mismos a la red, aplicando asimismo soluciones de optimización caché, que redundan de manera palpable en el rendimiento de las comunicaciones.
Ésta es una de las razones por las cuales optamos por este tipo de implantaciones como primer paso, dado que la instalación de un servicio proxy es imperceptible para los usuarios, desde su punto de vista, pero redunda en resultados claros para la organización, abriendo ese camino de confianza tan importante para abordar nuevos proyectos y soluciones en el cliente.
Por lo tanto, vamos a describir de un modo detallado las características de una de las soluciones proxy que hay en el mercado: Squid. Entre sus características principales, podemos destacar la facilidad de configuración, su fiabilidad y los excelentes resultados que ofrece una vez está operativo.
Por otra parte, Squid nos abre las puertas, posteriormente, a introducir a la PYME en cuestiones que hasta el momento le eran ajenas, tales como el control del uso de la red y el análisis del rendimiento de la misma, que nos permitirá, con la información que nos ofrece Squid, planificar mejoras en dicha red y solucionar errores en el diseño de la misma.
Squid es un software proxy, diseñado originalmente para plataformas Unix-Like, liberado bajo licencia GPL, que permite desde la aceleración de la navegación, hasta caché DNS, soportando multitud de protocolos,aunque en realidad se utiliza principalmente para HTTP y FTP.
El término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. La finalidad más habitual es la del servidor proxy, que sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP.
Squid posee las siguientes características:
- Proxy y Caché de HTTP, FTP, y otras URLs,
- Proxy para SSL,
- Jerarquías de Caché,
- ICP, HTCP, CARP, Caché Digests,
- Caché transparente,
- WCCP (Squid v2.3 y superior),
- Control de acceso,
- Aceleración de servidores HTTP,
- SNMP,
- Caché de resolución DNS.
Squid puede ejecutarse en plataformas:
- Linux,
- FreeBSD,
- OpenBSD,
- NetBSD,
- BSDI,
- Mac OS X,
- OSF and Digital Unix,
- IRIX,
- SunOS/Solaris,
- NeXTStep,
- SCO Unix,
- AIX,
- HP-UX,
- Microsoft Windows NT/XP/2000/2003.
Actualmente (Enero 2007) la rama estable se encuentra en la versión 2.6.x. Entre los cambios más destacables en relación a versiones anteriores destacamos:
- Mejoras en la autentificación con Kerberos,
- Cambios adicionales en el manejo de ACLs con SSL,
- Soporte WCCPv2,
- Cifrado SSL con OpenSSL,
- Implementación Cygwin que permite a Squid correr bajo plataformas Microsoft.
Instalación
La instalación de Squid en una distribución Debian GNU/Linux o derivados (Ubuntu, Kubuntu, Knoppix, etc.) es muy sencilla. Desde consola y como root actualizaremos repositorios, y posteriormente instalaremos
Squid:
[root@satriani] apt-get
update && apt-get
install squid
Antes de comenzar con la edición del fichero de configuración documentaremos las redes o subredes desde las que Squid aceptará peticiones así como las interfaces de red de la máquina:
- La primera interfaz de red es eth0 con dirección IP 192.168.0.254/24 conectada a la VLAN2,
- La segunda interfaz de red es eth1 con dirección IP 192.168.60.253/27 conectada a la VLAN4 para la salida a Internet.
Con el comando ifconfig, comprobaremos que este direccionamiento está correctamente configurado en el servidor.
[root@satriani]
ifconfig | more
En la mayoría de las distribuciones, y partiendo de una instalación de paquetes precompilados
(.rpm o .deb por ejemplo), el fichero de configuración de Squid se halla en /etc/squid/squid.conf. Este fichero consta de multitud de parámetros; aunque en este artículo nos centraremos en las opciones
indispensables y más interesantes para conseguir un óptimo funcionamiento.
En caso de no poder localizar squid.conf, con las herramientas find y whereis intentaremos localizarlos, y en caso contrario, crearemos el fichero.
Localizando el fichero con find:
[root@satriani] find / -name squid.conf
Localizando el fichero con whereis:
[root@satriani] whereis squid.conf
squid: /etc/squid/squid.conf
Antes de nada, haremos un backup de nuestro fichero actual de configuración de Squid y lo enviaremos por email. Realmente no es necesario, pero es una buena práctica a la hora de modificar ficheros que puedan afectar a la estabilidad del sistema:
[root@satriani]cp /etc/squid/squid.conf /etc/squid/squid.conf.bak
[root@satriani]mail -s BackupSquidConf myuser@mydomain.com < /etc/squid/squid.conf
Llegados a este punto, dividiremos en dos partes el fichero de configuración squid.conf : Configuración Global y ACLs, con el fin de aclarar la comprensión del mismo.
Configuración Global
- visible_hostname: Nombre visible de nuestro servidor proxy,
- http_port: Puerto TCP en el que escucha el servicio,
- cache_mem: Tamaño de la memoria caché,
- cache_dir: Directorio de la caché,
- cache_access_log: Fichero de almacenamiento de logs,
- cache_mgr: Administrador de la caché,
- coredump_dir: Directorio para los volcados de memoria,
- maximum_object_size: Tamaño máximo de los objetos de la caché,
- half_closed_clients: Cierre de conexiones a clientes con sockets abiertos que no envían datos,
- ftp_user: Dirección de correo para FTP anónimos.
Con nuestro editor de texto favorito (nano en este artículo), editaremos o crearemos (recomendado) el fichero squid.conf, aplicando los parámetros descritos en el punto anterior acorde con el ejemplo que se muestra a continuación (ver Listado 1).
Listado 1. Squid.conf Parte 1, definición de parámetros globales
[root@satriani] nano /etc/squid/squid.conf
Squid.conf Parte 1, Configuración Global
-----------------------------------------------------
#
#Fichero de Configuración Squid 2.6.x
#Localización: /etc/squid/squid.conf
#
#Última modificación : 07/02/07
#
visible_hostname proxy.mydomain.com
http_port 3128 transparent
#
#
#Parámetros de la cache
cache_mem 32 MB
cache_dir ufs /tmp 1024 32 256
cache_mgr myuser@mydomain.com
coredump_dir /var/spool/squid/cache
acl manager proto cache_object
maximum_object_size 32768 KB
cache_access_log /var/log/squid/access.log
#
#
#Parámetros varios
half_closed_clients off
ftp_user anonymous@nospam.com
ACLs
Un ACL es una definición de control de acceso, que en Squid se especifica mediante el parámetro acl según la siguiente sintaxis:
acl nombre_acl tipo_acl descripción
...
acl nombre_acl tipo_acl
"fichero_de_descripciones" ...
Cuando usamos un “fichero_de_descripciones“, cada descripción se corresponde con una línea del fichero, como podemos ver en el siguiente ejemplo:
acl denywords url_regex "/etc/squid/denywords"
http_access deny denywords
Es necesario apuntar que antes de reiniciar el servicio, el fichero /etc/squid/denywords debe existir; en caso contrario no se podrá iniciar el servicio. Es recomendable añadir por lo menos una cadena de texto, para eliminar un posible mensaje Warning al iniciar el servicio.
Las Listas de Control de Acceso (ACL) en Squid proporcionan seguridad adicional, limitando o permitiendo tráfico. Implementando ACLs podremos, entre otras opciones filtrar tráfico por:
- IP o Subred de origen,
- Dominio o Subdominio de destino,
- Contenido del site,
- Extensión del archivo o archivos descargados,
- Navegador utilizado,
- Filtrado por MAC,
- Filtrado por horario.
Listado 2. Squid.conf Parte 2, definición de ACLs
acl all src 0.0.0.0/0.0.0.0
acl localhost src 127.0.0.1/255.255.255.255
acl lan src 192.168.0.0/255.255.255.0
acl denywords url_regex "/etc/squid/denywords"
acl denydomains dstdom_regex "/etc/squid/denydomains"
A continuación describiremos el proceso para aplicar las ACLs a nuestra implementación. Definiremos las redes / subredes en las que trabajaremos. En este caso son tres redes:
- 127.0.0.1/255.255.255.255 : Loopback, el propio Squid debe poder conectarse por la interfaz de loopback(lo).
- 192.168.0.0/255.255.255.0: LAN en la que Squid escucha por el puerto 3128(http_port).
- 0.0.0.0/0.0.0.0: Definición global de todas las redes.
Listado 3. Squid.conf Parte 3, aplicación de ACLs
http_access allow localhost
http_access allow manager localhost
http_access deny denywords
http_access deny denydomains
http_access allow lan
http_access allow mantenimiento
http_access deny CONNECT !SSL_Ports
http_access deny CONNECT !Safe_Ports
http_access deny all
Definiremos las restricciones a aplicar en los hábitos de navegación:
- Restricción a dominios determinados, por ejemplo midominio.com,
- Restricción a sitios cuyo contenido contenga la cadena micadena,
- Restricción de conexiones que no tengan como origen las redes de las interfaces loopback y eth0 (en este ejemplo),
- Restricción de conexiones que intenten acceder a puertos que no se hayan definido previamente en las ACLs SSL_ports Safe_ports,
- Restricción total al resto de conexiones que no coincidan con los patrones definidos en las ACLs.
Llegados a este punto, tenemos prácticamente configurado Squid. Antes de iniciar el servicio, necesitamos crear la estructura del directorio swap de Squid, iniciar el servicio y verificar el funcionamiento. Para ello, como de costumbre, desde el terminal y como root (Listado 4).
Listado 4. Arrancando Squid
[root@satriani] squid -z
2007/02/07 15:10:18 | Creating Swap Directories
[root@satriani] /etc/init.d/squid start
Starting Squid HTTP Proxy: squid
[root@satriani] telnet 192.168.0.254 3128
Trying 192.168.10.254 3128 . . .
Connected to proxy.mylan.com (192.168.0.254)
Escape character is '^]'.
get http://www.gnu.org
Uno de los puntos a tener en cuenta a la hora de configurar un servidor proxy son los ficheros log. Éstos suelen aumentar de tamaño, como es lógico, a medida que nuestro proxy va sirviendo páginas. Para evitar futuros problemas, es necesario configurar la herramienta logrotate, para que la rotación de logs se realice semanalmente (Listado 5).
Listado 5. Rotando logs
[root@satriani] nano /etc/
logrotate.d/squid
/var/log/squid/access.log {
weekly
rotate 5
copytruncate
compress
notifempty
missingok
}
Configuración Proxy Navegadores
En párrafos posteriores, configuraremos Iptables, para dotar a nuestro servidor proxy, de las funciones de proxy transparente. Para que los navegadores de los clientes envíen las peticiones a nuestro servidor, debemos configurar los navegadores para que salgan a Internet por el proxy.
Configuración para Mozilla Firefox 2.0.x:
Herramientas/Opciones/Avanzado/Red/Configuración.
Configuración para Internet Explorer 6.0.x:
Herramientas/Opciones de Internet/Conexiones/Configuración LAN.
Configuración para Links 0.99.x: Configuración/Opciones de Red.
Se han obviado en la implementación del proxy, la instalación de filtros adicionales, que facilitan las restricciones y las configuraciones de las ACLs, como pueden ser los archiconocidos DansGuardian o Squid Guard. Una de las opciones más interesantes de Squid, es que, en binomio con Iptables, podemos configurar el mismo servidor proxy como gateway para la salida a Internet, liberando al administrador de red, de la tediosa labor de configurar puesto a puesto los navegadores y demás aplicaciones.
La instalación y configuración de estos paquetes, así como la configuración de Squid en modo transparente es relativamente sencilla, y los resultados son realmente espectaculares, pero como habrá podido observar el lector, se escapan al enfoque inicial de este artículo.
Monitorizando accesos: SARG
Con Squid funcionando, filtrando resultados y acelerando en la medida de lo posible los accesos a Internet, la monitorización de accesos desde Shell al fichero access.log, se vuelve una tarea tediosa y complicada. Existen multitud de paquetes que resuelven con más o menos soltura esta tarea, entre ellos destacamos:
- Calamaris,
- Webalizer,
- Squidalyser,
- SARG.
Cualquier opción es altamente recomendable, pero por flexibilidad, sencillez y robustez, utilizaremos SARG. Acrónimo de Squid Análisis Report Generador, SARG es una aplicación escrita en C por Pedro Orso, que genera reportes en HTML a partir del fichero access. log generado por Squid, soportando ficheros log de: Squid, Microsoft ISA Server y Novell Border Manager.
Entre otros detalles muestra información acerca de :
- Usuarios: Distinguiendo IP origen o Nombre de Usuario,
- Archivos descargados,
- Sites visitados,
- Sites denegados,
- Top Sites: Sites más visitados,
- Errores de autentificación.
La versión más actual (Enero 2007) es la 2.2.3.1, pudiendo ser descargada en formato tar.gz o en paquetes binarios para: Debian, Fedora-RedHat, SuSE, Slackware, OpenBSD, MacOS…etc.
Como se indica en el párrafo anterior, SARG genera reportes en formato HTML, con lo cual nos vemos prácticamente obligados* a instalar un servidor web en nuestra máquina, por ejemplo Apache (http://www.apache. org), disponible para casi la totalidad de distribuciones GNU/Linux. Por razones de seguridad y privacidad, a la hora de generar los reportes, se recomienda instalar el módulo mod_auth, para restringir el acceso al servidor web.
La instalación, vía apt, yum o rpm, como viene siendo habitual es muy sencilla. Para la instalación desde una versión en tar.gz, describiremos los pasos:
Desempaquetamos y descomprimimos el fichero sarg-x.x.x.tar.gz:
[root@satriani] tar zxvf sarg-x.x.x.tar.gz
[root@satriani] ./configure
configure options:
enable-bindir= Directorio dónde se instalará el binario de sarg; por defecto : /usr/bin
enable-sysconfdir – Directorio de configuración; por defecto : /usr/local/sarg
nable-htmldir – Directorio del servidor web donde se generarán los reportes; default: /var/www/html
enable-mandir - where the sarg man page will be saved; default: /usr/local/man/man1
make
make install
En el directorio /usr/local/sarg o en el directorio especificado en –sysconfigdir, editaremos el fichero sarg.conf y haremos las modificaciones oportunas.
Podemos enviar los reportes a otra máquina vía SMB,NFS…etc.
El fichero sarg.conf almacena la configuración de SARG, y se localiza en el directorio especificado en –enable-sysconfdir, y la sintaxis es como en el Listado 6.
Listado 6. Ejemplo sarg.conf
Ejemplo fichero sarg.conf
# Slovak
# Spanish
# Turkish
#
language Spanish
# TAG: access_log file
# Where is the access.log file
# sarg -l file
#
access_log /var/log/squid/
access.log
# TAG: graphs yes|no
# Use graphics where is possible.
# graph_days_bytes_bar_color blue|g
reen|yellow|orange|brown|red
#
graphs yes
graph_days_bytes_bar_color red
Pese a ser un fichero de configuración aparentemente sencillo, en realidad nos encontramos con infinidad de posibilidades y combinaciones a la hora de trabajar con SARG.
Para hacer nuestra primera prueba, desde Shell y como root simplemente:
[root@satriani] sarg
Si no hemos tenido ningún Warning, abriendo un navegador podremos ver los resultados (Figuras 4, 5, 6).
Necesitamos añadir una tarea cron para ejecutar SARG por lo menos una vez al día, para ello, con nuestro editor de textos favoritos editamos /etc/crontab y añadimos:
0 20 * * * root /usr/bin/sarg
Iptables
El proyecto Iptables, también conocido como Netfilter, comenzó en 1998 encabezado por Michael Neuling y Rusty Russell, autor también del proyecto antecesor a iptables: ipchains.
Iptables es la herramienta principal de cortafuegos para GNU/Linux en las series del Kernel 2.4 en adelante. En relación a ipchains las principales novedades son: mejor aprovechamiento de los recursos del sistema, la integración de las reglas de filtrado, NAT y manipulación.
Para instalar Iptables en nuestra/s máquinas, podemos descargar iptables de www. netfilter.org, compilarlo e instalarlo. En prácticamente cualquier distribución actual el kernel está precompilado e iptables instalado por defecto.
Iptables para su funcionamiento utiliza tres tablas: nat, magle, y filter, donde cada una tiene definidas unas reglas o chains.Cada una de estas reglas se compone de una lista de reglas de filtrado sobre el paquete mediante un par condición/acción. El paquete IP pasará secuencialmente por cada una de estas reglas hasta encajar en alguna de las reglas definidas. En caso contrario, se aplicará la acción por defecto asociada a esa regla.
Veamos un ejemplo de construcción de regla de iptables (man iptables):
iptables { -A | --append | -D | --delete } cadena especificación-de-regla [ opciones ]
/sbin/iptables –A INPUT –i eth0 –p tcp –dport 80 –j DROP
En la regla anterior, añadimos (-A) a la tabla filter (INPUT) una regla que deniega (DROP) todo el tráfico web entrante (-p tcp –dport 80) por la interfaz eth0 ( -i eth0).
Enmascarando Interfaces: Proxy transparente
Es necesario recordar que iptables no deja de ser un shell script, y que si no salvamos las reglas, con el reinicio de la máquina, éstas se perderán. Para ello, disponemos del comando iptables-save. En este ejemplo, de integración de Iptables con Squid, no utilizaremos iptables-save, sino que crearemos un shell script, que ejecutaremos cada vez que reiniciemos la máquina. Así, podremos comentar y analizar de un modo mucho más flexible el conjunto de reglas a aplicar.
Comenzaremos creando el fichero que almacenará las reglas de iptables. Como es habitual, en el terminal y como root:
[root@satriani] touch /etc/init.d/firewall
[root@satriani] chmod 700 /etc/init.d/firewall
[root@satriani] update-rc.d firewall defaults
Hemos creado el fichero /etc/init.d/firewall, modificado permisos (rxw- - - - - - ) para que solamente root pueda ejecutarlo, y a continuación con el comando update-rc.d conseguimos que se ejecute en todos los runlevels.
Retomemos la configuración de Squid. Tenemos corriendo el servicio de Proxy Caché, en el puerto TCP 3128. Supuestamente hemos llevado a cabo la tediosa labor de configurar todas y cada una de las aplicaciones en las máquinas de nuestra LAN que queremos que salgan a Internet a través de este servicio. Evidentemente este supuesto es inviable cuando el número de máquinas y aplicaciones de las que hablamos es considerable. Para ello, iptables es capaz de simular un router, actuando como puerta de enlace para las máquinas de su LAN, por medio del enmascaramiento IP o masquerading.
Llegados a este punto, iptables llama a la puerta de nuestra máquina pidiendo ser configurado. Como hemos comentado, iptables es capaz de modificar los paquetes IP, acorde a unas reglas predefinidas. Para ello añadiremos reglas en la tabla mangle, utilizando la cadena PREROUTING; es decir, redireccionaremos todas la peticiones al puerto 80 hacia el 3128:
iptables –t nat –A PREROUTING –s 192.168.0.0/0 –p tcp –dport 80 –j DNAT –to-destination 192.168.0.1:3182
Ejecutando este script, eliminando la configuración proxy en las aplicaciones configuradas en las máquinas de nuestra LAN y modificando el gateway de éstas por las IP de la interfaz enmascarada, hemos configurado un proxy transparente.
Como habrán podido observar nuestros avispados lectores, la política por defecto es ACCEPT, con lo cual nuestra máquina acepta todo el tráfico sin restricciones ni filtrado de ningún tipo, dejándola expuesta ante cualquier ataque. Así mismo, tampoco se ha mencionando las conexiones por SSL a través del proxy transparente. La razón es muy sencilla: los paquetes viajan cifrados entre el servidor web y el navegador del cliente, impidiendo que Squid pueda escuchar y procesar correctamente las peticiones https. Recordemos que el proxy se encuentra entre el webserver y el navegador del cliente. Entre las recomendaciones sugeridas para aumentar el blindaje de nuestra máquina se encuentran:
En caso de encontrar problemas a la hora de identificar los puertos utilizados en las conexiones SSL, aplicaciones como Ethereal o Iptraff, pueden ayudarnos.
Logear reglas. Iptables permite logear reglas con la directiva LOG, lo cual nos permitirá comprobar si ha habido algún intento de acceso no deseado a nuestra máquina:
iptables –A INPUT –i eth0 –p tcp –dport 22 –j LOG –logprefix=”ACCESO-SSH”
Por defecto, el fichero log donde iptables almacena los log es /var/log/messages. A medida que este fichero va aumentando, acceder a una línea concreta, puede resultar una tarea ardua y difícil. Para ello existen herramientas que permiten su legibilidad, como por ejemplo Wflogs, que convierte entradas en formato HTML.
IDS. Implementar un Sistema de Detección de Intrusos nunca está demás. Recomendamos encarecidamente Snort. La finalidad de este artículo es mostrar al lector las posibilidades globales de Squid e Iptables. Es responsabilidad de cada usuario o Administrador, proteger y blindar sus sistemas. Implementando Squid e Iptables tendrá parte del camino recorrido, el resto… está en sus manos.
Listado 7. Script de configuración iptables
#!/bin/bash
#
#
#
#Borrado de reglas previas
iptables –F
iptables –X
iptables –Z
iptables –t nat –F
#
#
#Política por defecto
iptables –P INPUT ACCEPT
iptables –P OUTPUT ACCEPT
iptables –P FORWARD ACCEPT
iptables –t nat -P PREROUTING ACCEPT
iptables –t nat –P POSTROUTING ACCEPT
#
#
#Permitimos que los paquetes puedan ser "forwardeados"
iptables –A FORWARD –p tcp –s 192.168.0.0/24 –j ACCEPT
#
#Redireccionamos el tráfico web hacia el proxy
iptables –t nat –A PREROUTING –s 192.168.0.0/24 –p tcp –dport 80
–j DNAT –to-destination 192.168.0.1:3128
#Enmascaramos la interfaz eth0
iptables –t nat –A POSTROUTING –s 192.168.0.0/24 –o eth0 –j MASQUERADE
#
#Habilitamos bit de forward. ¡Muy importante!
echo 1 > /proc/sys/net/ipv4/ip_forward
Consideraciones finales
Controlar el acceso y acelerar la navegación a los sitios visitados en Internet es una solución viable y contrastada para optimizar el acceso y el ancho de banda de una PYME. Mediante la instalación de una solución proxy gestionar la conexión a Internet desde un sólo punto, permitiendo una conexión segura, habilitando y denegando la conexión a ciertos puertos o protocolos es posible, fiable, y económico.
Implementando Sistemas Operativos Libres (Linux,*BDSs ..etc), independientemente del ahorro de costes en licencias, dotamos a las implementaciones de un nivel de seguridad y robustez añadido, que difícilmente podremos encontrar en otros Sistemas Operativos.
Squid, como software de servidor proxy, en su versión 2.6, ha alcanzado su madurez, tanto es así, que grandes corporaciones e incluso ISPs optan por su implementación bajo plataformas *NIX. Iptables va camino de convertirse en un hito en sistemas GNU/Linux con Kernel 2.4 - 2.6. Mientras tanto y a la espera de la release 2.7 de Squid… seguiremos haciendo web-caching.
Enlaces de la red:
Escrito por The Evangelist el 2 de Octubre de 2008 y etiquetado como: Cisco, Seguridad
Crear una VPN con un Cisco ASA es muy simple y más si se usa el wizard del entorno gráfico Java, pero muchas veces viene bien poder hacerlo vía comandos desde la consola.
Aquí pongo 2 variantes para crear VPN, la primera es la salida que genera el wizard (solo para un lado) y la segunda es el código de ambos lados de la VPN extraído de un artículo del blog write mem. Está claro que puede haber muchas variantes de VPN site2site dependiendo del tipo de cifrado y otros valores, pero aquí expongo uno sencillo y seguro válido para la gran mayoría.
Lo que crea el wizard:
crypto isakmp enable outside
access-list inside_nat0_outbound line 1 extended permit ip red_local mascara_local red_remota mascara_remota
access-list outside_1_cryptomap line 1 extended permit ip red_local mascara_local red_remota mascara_remota
tunnel-group ip_peer type ipsec-l2l
tunnel-group ip_peer ipsec-attributes
pre-shared-key clave_precompartida
isakmp keepalive threshold 10 retry 2
crypto isakmp policy 10 authen pre-share
crypto isakmp policy 10 encrypt 3des
crypto isakmp policy 10 hash sha
crypto isakmp policy 10 group 2
crypto isakmp policy 10 lifetime 86400
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group2
crypto map outside_map 1 set peer ip_peer
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
nat (inside) 0 access-list inside_nat0_outbound tcp 0 0 udp 0
Los datos a cambiar son:
- red_local y mascara_local, son la red LAN de este lado de la VPN
- red_remota y mascara_remota, son la red LAN del lado remoto de la VPN
- ip_peer, es la IP pública del lado remoto
- clave_precompartida, es un clave igual en ambos lados.
Es muy importante que los datos sea idénticos en ambos lados, sobre todo el lifetime y los access-list
Y ahora la versión del Blog write mem.
Lado local:
cry isakmp policy 10
auth pre
encr 3des
group 2
hash sha
!
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
!
crypto isakmp key password address 192.168.55.1
!
access-list 101 permit ip 192.168.56.0 0.0.0.255 192.168.54.0 0.0.0.255
!
cry isakmp keep 10 2
crypto map vpnmap 10 ipsec-isakmp
set peer 192.168.55.1
set transform-set 3DES-MD5
match address 101
reverse-route
!
int fa0/0
ip addr 192.168.56.1 255.255.255.0
no shut
!
int fa0/1
ip address 192.168.55.2 255.255.255.0
no shut
crypto map vpnmap
!
ip route 0.0.0.0 0.0.0.0 192.168.55.1
!
Lado remoto:
cry isakmp policy 10
auth pre
encr 3des
group 2
hash sha
!
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
!
crypto isakmp key password address 192.168.55.5
!
access-list 101 permit ip 192.168.54.0 0.0.0.255 192.168.56.0 0.0.0.255
!
cry isakmp keep 10 2
crypto map vpnmap 10 ipsec-isakmp
set peer 192.168.55.5
set transform-set 3DES-MD5
match address 101
reverse-route
!
int fa0/0
no shut
ip address 192.168.55.1 255.255.255.0
crypto map vpnmap
!
int l0
ip address 192.168.54.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.55.5
!
Escrito por Foron el 8 de Septiembre de 2008 y etiquetado como: Firewalls, Linux, Seguridad
En el anterior post hemos visto lo más básico de psad. De hecho, he resumido alguna cosa tanto que los que ya conozcan el software pueden decir que no he sido todo lo riguroso que debiera. Un ejemplo, la parte relacionada con las variables IPT_AUTO_CHAIN#. Mi objetivo, más que ser completamente riguroso, era dar una visión global del software.
En fin, dicho esto, vamos a ver alguna otra cosilla que se puede hacer con psad.
Recordemos el problema. Queremos poder añadir a nuestro firewall perimetral reglas que con el tiempo vayan expirando sin tener que estar encima. Queremos, además, que estas reglas se añadan en base a decisiones que tomen los servidores web o smtp en base a sus propios mecanismos, quitando al firewall perimetral la responsabilidad del análisis del tráfico del nivel de aplicación.
Hay varias formas de hacerlo. Lo más fácil es usar el propio comando psad. Por ejemplo:
# psad -fw-block-ip 10.0.5.98
[+] Writing 10.0.5.98 to socket; psad will add the IP
within 5 seconds.
Es tan sencillo como esto. Veamos el resultado:
# psad --fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords…
Chain PSAD_BLOCK (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all — * * 10.0.5.98 0.0.0.0/0
Para quitar esta IP es suficiente con esperar los 600 segundos configurados, o bien ejecutar:
# psad --fw-rm-block-ip 10.0.5.98
[+] Writing 10.0.5.98 to socket; psad will remove the IP
within 5 seconds.
# psad –fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords…
Chain PSAD_BLOCK (1 references)
pkts bytes target prot opt in out source destination
A partir de aquí, seguro que a cada uno se le ocurren cinco formas de hacer que un servidor genere los comandos para que el firewall añada las reglas.
La forma en la que cada administrador gestiona lo que puede hacer con psad es particular de cada infraestructura, pero sin duda, una combinación de psad, fwsnort y otras técnicas como el port knocking añaden funcionalidades muy interesantes que en muchos casos ni siquera el software/hardware de pago ofrecen.
Escrito por Foron el 7 de Septiembre de 2008 y etiquetado como: Debian, Firewalls, Linux, Seguridad
En este post voy a documentar un uso alternativo que se puede dar a psad, un interesante software pensado para la detección de escaneos de puertos, que fue creado como parte de bastille linux en el 1999.
El problema:
Tenemos un firewall que gestiona una red digamos que de servidores web y smtp, para los que evidentemente tenemos acceso libre por los puertos 25 y 80, pero que reciben multitud de ataques de todo tipo. Las propias aplicaciones tienen sus mecanismos de seguridad, pero al final siempre añadimos muchas de las IPs que generan los ataques en el firewall perimetral. Claro, al final tenemos cientos de IPs en los firewalls que somos incapaces de mantener, y que no hacen más que complicar su gestión. Para colmo, la mayoría de esas IP sólo lo intentan durante unos pocos minutos.
Una solución:
Queremos un sistema con el que podamos añadir IPs al firewall, y que expiren, si así lo decidimos, en un cierto plazo de tiempo. Vamos a utilizar psad para esto, que además, al mismo precio, nos sirve para detectar escaneos de puertos. En este primer post sobre todo escribiré sobre lo básico de psad, que en el próximo iremos adaptando al problema.
Vamos a ir instalando. Una opción es descargar el sofware y usar su propio instalador desde cipherdyne.org/psad/, pero en este caso voy a usar el software ya precompilado para Debian. Por cierto, más que recomendable dar una vuelta por cipherdyne.org y ver el software que hay disponible.
aptitude install -R psad
No quiero que installe bastille, de ahí que use -R. Psad es una aplicación que en su mayoría está programada en perl, así que dependiendo de lo que cada uno tenga en su sistema instalará más o menos librerías.
Una instalación por defecto de psad lee los datos que a través de syslog se pasan a la tubería /var/lib/psad/psadfifo (un pipe de los de toda la vida), con lo que lo primero es hacer que kern.info se mande a dicho pipe, con algo tan sencillo como añadir a syslog.conf:
kern.info |/var/lib/psad/psadfifo
Después de reiniciar syslog, ya está todo practicamente listo…..
Configuración:
Dependiendo de la forma de instalación y de la distribución que usemos, seguramente las rutas, nombres de pipes y alguna otra opción podrían ser diferentes, con lo que lo descrito aquí es más conceptual que algo con lo que se pueda hacer copy/paste.
Como psad es un software que sobre todo lee logs, es fundamental que nuestro firewall loguee lo que queremos tratar, que puede ser sólo lo del propio cortafuegos, o también lo que otras máquinas puedan enviarle. En definitiva, que aquí está la clave del invento.
Como referencia, hay que tener en cuenta que psad mira que en las líneas de logs que recibe existan las cadenas IN= y OUT=, con lo que asume que son de iptables. Esto nos será útil posteriormente.
Toda la configuración se hace en /etc/psad/psad.conf. En el directorio /etc/psad hay muchos otros ficheros, algunos los trataré en este post, pero otro no. Hay que tener en cuenta que psad es un software que hace más cosas que lo que voy a describir aquí.
La configuración es muy sencilla de leer y muy documentada, “se explica sola”, así que sólo voy a comentar lo más útil para hacerse una idea.
Las dos siguientes variables definen las redes locales y las que no lo son, muy al estilo snort.
HOME_NET 192.168.10.0/24, 172.16.0.0/16; # un ejemplo
EXTERNAL_NET any;
Estas redes se definen porque psad usa las reglas de snort para detectar tráfico sospechoso, aunque las usa en cierta medida de forma diferente. Por ejemplo, para psad todo el tráfico que loguea está destinado a lo que para snort sería HOME_NET.
Las siguientes variables definen los niveles de peligro. Desde el punto de vista de escaneo de puertos, estos niveles definen el número de paquetes recibidos. Desde el punto de vista de otro tipo de actividad maliciosa, estos niveles se definen según el tipo de ataque o si la IP origen es conocida por anteriores bloqueos.
DANGER_LEVEL1 5; ### Number of packets.
DANGER_LEVEL2 15;
DANGER_LEVEL3 150;
DANGER_LEVEL4 1500;
DANGER_LEVEL5 10000;
Con la siguiente línea hacemos que Psad no sea sólo algo pasivo, sino que añada reglas a nuestro firewall.
ENABLE_AUTO_IDS Y;
Digamos que queremos bloquear IPs a partir del nivel 3:
AUTO_IDS_DANGER_LEVEL 3;
Y que queremos que los bloqueos duren 600 segundos
AUTO_BLOCK_TIMEOUT 600;
Por supuesto, usamos iptables:
IPTABLES_BLOCK_METHOD Y;
La siguiente variable define la/s cadenas en las que queremos que se añadan reglas de bloqueo. Su sintaxis es: Target,Direction,Table,From_chain,Jump_rule_position,To_chain,Rule_position.
Por ejemplo:
IPT_AUTO_CHAIN1 DROP, src, nat, PREROUTING, 1, PSAD_BLOCK, 1;
Lo más interesante aqui es que DROPeamos con reglas añadidas a la tabla nat y la cadena PSAD_BLOCK. Se pueden añadir IPT_AUTO_CHAINn reglas. No hace falta decir que debemos haber creado anteriormente la cadena PSAD_BLOCK
Psad puede incluso ejecutar scripts externos. La IP origen se pasa a estos scripts en la variable SRCIP.
ENABLE_EXT_SCRIPT_EXEC N;
Hay muchas opciones a configurar. Como he dicho antes aquí no hay más que unas cuantas para dar una idea de lo que se puede hacer.
Otro fichero interesante es el /etc/psad/auto_dl, en el que podemos configurar listas blancas y negras de IPs. Por ejemplo:
127.0.0.1 0;
10.111.21.23 5 tcp/22;
Con estas dos reglas permitimos todo lo que venga desde 127.0.0.1 y damos un danger_level de 5 a todo lo que venga de 10.111.21.23 y sea tráfico ssh.
Otro fichero interesante es /etc/psad/signatures, que incluye unas 200 firmas de snort, pero ligeramente modificadas para poder pasar información a psad. Por ejemplo:
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING undefined code"; icode:>0; itype:8; classtype:misc-activity; sid:365; psad_id:100195; psad_dl:2;)
Es una definición de regla relacionada con icmp, y que tiene un identificador en psad de 100195 y que asigna un danger_level de 2.
Ahora sólo quedaría arrancar psad, con:
/etc/init.d/psad start
Pruebas de funcionamiento:
Veamos lo que pasa cuando alguien nos hace un escaneo de puertos. Como nota, tengo un danger_level (DL) de 3 a partir del cual se añaden reglas de bloqueo.
Sep 6 21:48:05 psad: src: 87.218.x.y signature match: "MISC MS Terminal Server communication attempt" (sid: 100077) tcp port: 3389
Sep 6 21:48:05 psad: src: 87.218.x.y signature match: “MISC Microsoft PPTP communication attempt” (sid: 100082) tcp port: 1723
Sep 6 21:48:05 psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [21-6347] flags: SYN tcp pkts: 130 DL: 2
Sep 6 21:48:11 psad: src: 87.218.x.y signature match: “BACKDOOR DoomJuice file upload attempt” (sid: 2375) tcp port: 3141
Sep 6 21:48:11 psad: src: 87.218.x.y signature match: “DOS Real Audio Server communication attempt” (sid: 100112) tcp port: 7070
Sep 6 21:48:11 psad: src: 87.218.x.y signature match: “BACKDOOR Subseven DEFCON8 2.1 connection Attempt” (sid: 107) tcp port: 16959
Sep 6 21:48:11 psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [2-32770] flags: SYN tcp pkts: 214 DL: 3
Sep 6 21:48:11 psad: added iptables auto-block against 87.218.x.y for 600 seconds
Sep 6 21:48:16 psad: scan detected: 87.218.x.y -> 83.213.x.y tcp: [104-13722] flags: SYN tcp pkts: 30 DL: 3
Donde 87.218.x.y es la IP origen del escaneo y 83.213.x.y el destino.
En el firewall:
# iptables -L PSAD_BLOCK -n -t nat
Chain PSAD_BLOCK (1 references)
target prot opt source destination
DROP all — 87.218.x.y 0.0.0.0/0
Y a los 600 segundos, se vacía.
Sep 6 21:58:13 psad: removed iptables auto-block against 87.218.x.y
# iptables -L PSAD_BLOCK -n -t nat
Chain PSAD_BLOCK (1 references)
target prot opt source destination
Lo que he hecho hasta ahora es lo básico de psad. En el próximo post seguiré con alguna otra cosilla interesante.
Para el que quiera buscar más información, nada como el libro linux firewalls. Un libro realmente excelente de una editorial que merece la pena.
Escrito por The Evangelist el 31 de Julio de 2007 y etiquetado como: Bash, Debian, Seguridad
Instalar el paquete debian-keyring de la siguiente manera:
apt-get install debian-keyring
Si sale este error o similar:
W: GPG error: http://secure-testing.debian.net etch/security-updates
Release: The following signatures couldn't be verified because the public
key is not available: NO_PUBKEY 946AA6E18722E71E
Coger los últimos 8 dígitos de la pubkey (en el ejemplo de arriba: 8722E71E) y ejecutar los siguientes comandos:
$ gpg --keyserver pgp.mit.edu --recv-keys 8722E71E
$ gpg --armor --export 8722E71E | apt-key add -
Escrito por The Evangelist el 23 de Junio de 2008 y etiquetado como: Apache, Seguridad
En muchos de nuestros proyectos, sobre todo personales, necesitamos tener una web segura con SSL pero no queremos pagar un certificados porque no lo necesitamos, en tal caso lo que podemos hacer un crearnos un certificado auto-firmado, esto son lo pasos a seguir:
A mi me gusta crear un directorio dentro de la estructura del apache pero puede estar en cualquier sitio incluso en los certificados del sistema “/etc/ssl/certs”:
# mkdir /etc/apache2/certs
# cd /etc/apache2/certs
Creamos un certificado ráiz, a mi me gusta ponerle el nombre del dominio y crearlo con 2048 bits pero con 1024 es más que suficiente:
# openssl genrsa -out www.dominio.com.key 2048
Generamos una petición de firma del certificado:
# openssl req -new -key www.dominio.com.key -out www.dominio.com.csr
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Provincia
Locality Name (eg, city) []:Ciudad
Organization Name (eg, company) [Internet Widgits Pty Ltd]:nombre de la empresa
Organizational Unit Name (eg, section) []:Sistemas
Common Name (eg, YOUR name) []:www.dominio.com
Email Address []:el email del responsable del apache o web
A challenge password []: <NO METER NADA>
An optional company name []:<NO METER NADA>
Generamos un Certificado Autofirmado
# openssl x509 -req -days 3650 -in www.dominio.com.csr -signkey www.dominio.com.key -out www.dominio.com.crt
Luego en la configuración del apache dentro del VirtualHost debemos añadir estas líneas:
SSLEngine on
SSLCertificateFile /etc/apache2/certs/www.dominio.com.crt
SSLCertificateKeyFile /etc/apache2/certs/www.dominio.com.key
