Enrutado

29 julio 2009

routed

routed es uno de los paquetes de rutado standard disponibles para Linux. Soporta RIP (uno de los protocolos de rutado más viejos todavía en servicio), y ya está. El RIP es muy simple, los routers simplemente hacen un broadcast de sus tablas de rutado a los routers vecinos, lo cual da como resultado (en teoría) una tabla completa de rutado que tiene entradas para cada destino en Internet. Este método es fundamentalmente inseguro, y muy ineficiente más allá de pequeñas redes seguras (en cuyo caso probablemente no sea necesario). Asegurarlo no es posible, se puede configurar un cortafuegos en los puertos 520 y 521, que son los que utiliza RIP para transferir, sin embargo puede dar como resultado rutas a través de las cuales preferirías no atravesar, y los atacantes pueden seguir falsificando las rutas. Ejecutar este servicio es una idea muy mala.

gated

gated es un software de rutado más avanzado que routed. Soporta versiones de RIP 1 y 2, DCN HELLO, OSPF versión 2, EGP versión 2, BGP versiones 2 a 4. Actualmente el protocolo de rutado más popular parece ser el BGP (Border Gateway Protocol), ganando en popularidad el OSPF (OSPF tiene seguridad incorporada, es muy eficiente y bastante más complicado).

zebra

zebra tiene bastantes más características que gated, y ostenta una bonita línea de interfaz de comandos al estilo de Cisco. Se ejecuta como un demonio, multi-hilo para el rendimiento, cada protocolo (RIP, OSPF, etc.) tiene su propia configuración, y se pueden ejecutar múltiples protocolos a la vez (aunque podría originar confusiones/problemas). Existe un puerto de configuración maestro, y un puerto para cada protocolo:

zebrasrv 2600/tcp #zebra service

zebra 2601/tcp #zebra vty

ripd 2602/tcp #RIPd vty

ripngd 2603/tcp #RIPngd vty

ospfd 2604/tcp #OSPFd vty

bgpd 2605/tcp #BGPd vty

ospf6d 2606/tcp #OSPF6d vty

Recomendaría filtrar estos puertos con el cortafuegos. El acceso se controla vía contraseña de login, y el acceso a las funciones de comandos solicita otra contraseña (utilizando la misma sintáxis que en Cisco, “enable”). Se puede descargar de: [[http://www.zebra.org/ http://www.zebra.org%5D%5D

Anuncios

Cortafuegos

29 julio 2009
Tutorial creado por Kurt Seifried. Extraido de: http://es.tldp.org/Manuales-LuCAS/GSAL/gsal-19991128-htm/
16 de Febrero de 2006
Un cortafuegos consiste en filtrar el tráfico TCP-IP, generalmente en el punto donde la red se conecta a otra (p. ej. a Internet, a una LAN de clientes, etc), que puede ser no fiable (en el caso de Internet) o quizás incluso fiable (otro piso de tu edificio). Al igual que los cortafuegos de los grandes edificios, un cortafuegos de red puede evitar e incluso bloquear la extensión del ataque si un segmento se ve comprometido con éxito, al igual que su homónimo cortafuegos puede evitar que la red se siga viendo comprometida.

Linux ha tenido capacidad de cortafuegos desde hace ya un tiempo, en forma de ipfwadm, que era un filtro a nivel de paquetes muy sencillo. Con la llegada del kernel 2.1, se ha visto reemplazado por ipchains, que es un poco más sofisticado. Este a su vez se verá reemplazado en el propuesto kernel 2.4, con un filtrado de paquetes todavía más avanzado, que es más independiente. Sin embargo, ambos todavía siguen siendo filtros de paquetes, y no permiten características más avanzadas como la inspección de estados o algunos tipos de conexiones proxy. Sin embargo Linux soporta IPMASQ, una forma de NAT (Traducción de Direcciones de Red, Network Address Translation). El IPMASQ permite enganchar una red de ordenadores a Internet, pero haciendo un proxy de sus conexiones a nivel de IP. De tal forma que todo el tráfico parezca provenir y dirigirse a una máquina (la máquina Linux con IPMASQ), lo cual proporciona un alto grado de protección a la red interna. Como plus añadido, los clientes de la red interna NO necesitan configurar su proxy; mientas el servidor IPMASQ del Linux esté bien configurado y los clientes lo utilicen como su puerta de enlace por defecto, todo irá bien.

Ambos ipchains e ipfwadm proporcionan las siguientes funcionalidades:

  • bloqueo / permiso del paso de datos basado en IP/puerto/interface origen/destino
  • enmascaramiento de conexiones, basado en IP/puerto/interface origen/destino

Además, ipchains soporta:

  • redireccionamiento de puertos
  • creación de cadenas, para reglas y condiciones más complejas, más fácil de mantener
  • routing de calidad de servicio (QOS, Quality of Service), útil en conexiones de baja velocidad o saturadas
  • especificación de IP/puerto/interface además de especificación inversa (utilizando el !)

El HOWTO del cortafuegos y las páginas “man <command>” (ipchains o ipfwadm) se ocupan en gran detalle de la mecánica para la configuración de las reglas, pero en realidad no se ocupan de la estrategia para hacer un filtrado de forma segura. La primera elección que se debe hacer es si se va a seguir una política de denegación o de permisión por defecto, seguido de qué servicios y hosts se quiere permitir y bloquear.

Cuando se vaya a decidir la política, se debería escoger aquella que deniego todo por defecto, a menos que esté específicamente permitido (de forma que si existe un fallo, con suerte se vea minimizado vía política por defecto) o una política que permita todo y bloquee ciertos servicios/hosts. Generalmente suelo utilizar una política de denegación por defecto, pues de esta forma puedo arreglar errores y cambios de forma más segura que una política que permita el flujo de datos por defecto.

Pongamos por caso, se tiene un servidor asegurado vía filtrado con cortafuegos, ejecutando Apache, se instala WU-FTPD para uso interno (de modo que la gente pueda subir ficheros) a las 3 de la mañana, y se te olvida cambiar las reglas del cortafuegos. Si se ha escogido una política permisiva por defecto, cualquiera puede acceder al servidor ftp desde Internet, y además, cometiste el error de instalar una versión antigua que permitía a cualquiera comprometer la máquina. Si por otra parte, se sigue una política de denegación por defecto, no hubiesen accedido al servidor de ftp, ni lo hubiesen hecho tus usuarios, pero te darías cuenta más rápidamente. Los usuarios enfadados son algo más sencillo de tratar que una red que haya sido comprometida.

En esta sección, he decidido no tratar específicamente las reglas de filtrado del cortafuegos, daré ejemplos para cada servicio de red, puesto que para filtrar adecuadamente un protocolo primero hay que entender cómo se comporta. Por ejemplo, existe una gran diferencia entre filtrar el www y el ftp en cuanto a accesos internos y externos. Algunas reglas/conceptos generales:

IPFWADM

El Ipfwadm es un sólido paquete de filtrado para Linux, aunque carece de muchas características disponibles en Ipchains. Ipfwadm sólo soporta 3 objetivos para cada paquete: aceptar, denegar o rechazar, mientras que las reglas del ipchains se pueden dirigir a 6 objetivos, o a un objetivo definido por el usuario. En realidad, el Ipfwadm sólo es apropiado para un cortafuegos sencillo a nivel IP, enmascaramiento de IP y si se tiene previsto utilizar FreeS/WAN. Las opciones básicas son: especificar una dirección (dentro, fuera, o ambas, útil con el flag de interface), reglas de entrada, reglas de salida, reglas de redireccionamiento (pongamos que se tienen múltiples interfaces, también se ocupa de las reglas de enmascaramiento) y reglas de enmascaramiento que controlan el comportamiento del enmascaramiento (timeouts, etc). Se pueden insertar, añadir y borrar reglas, configurar políticas por defecto y listar todas las reglas. Aparte de eso es muy parecido a ipchains, con pequeñas variaciones. Lo que viene a continuación es un script apropiado para un servidor que está haciendo de bridge entre 2 redes (10.0.0.x en eth0, 10.0.0.1 y 192.168.0.x en eth1, 192.168.0.1) ejecutando un servidor de correo.

#!/bin/bash

#

# Primero limpiar todas las reglas

#

ipfwadm -f -I

ipfwadm -f -O

ipfwadm -f -F

#

# Permitir el redireccionamiento entre las dos redes y si no es entre # ellas, denegarlo

#

ipfwadm -F -a accept -P all -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24

ipfwadm -F -a accept -P all -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24

ipfwadm -F -p deny

#

# Y por supuesto hay que dejar que entren los paquetes

#

ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24

ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24

#

# Dejarles acceder al servidor de correo pero a nada más

#

ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 10.0.0.1 25

ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth0 -D 192.168.0.1 25

ipfwadm -I -p deny

Ahora el FreeS/WAN soporta la serie 2.2.x del kernel, nunca se debería escoger ipfwadm sobre ipchains. Ipchains ofrece un grado de control mucho más afinado y es mucho más flexible que ipfwadm.

IPCHAINS

El ipchains contiene algunas características nuevas comparado con ipfwadm; se pueden crear cadenas de reglas (de aquí el nombre) y enlazarlas juntas, haciendo más sencilla la administración de cortafuegos. El ipchains soporta más objetivos que ipfwadm; se puede apuntar una regla a: ACCEPT, DENY, REJECT, MASQ, REDIRECT o RETURN o a una cadena definida por el usuario. Como tal es bastante potente, se podría, por ejemplo, redireccionar todos los paquetes destinados al puerto 80 (tráfico www) de mi puerta de enlace para que se redirigiesen al puerto local 3128, el servidor proxy de Squid. También se puede utilizar esto junto con el routing de calidad de servicio, el ejemplo dado en la documentación de ipfwadm es priorizar el tráfico sobre un enlace PPP, se le puede dar una prioridad más alta al tráfico de telnet que al de, pongamos, ftp, reduciendo los problemas de latencia causados por un enlace saturado. Por lo general, creo un fichero /etc/rc.d/init.d/ipchains-sh (o en cualquier otro lugar apropiado) y lo llamo inmediatamente después de que arranca la red, lo cual deja un tiempo pequeño durante el cual el servidor es vulnerable, pero mínimamente, pues todavía no se están ejecutando demonios de red.

El siguiente script es apropiado para una puerta de enlace ejecutándose con 2 interfaces, que es por lo que he utilizado el objetivo DENY en lugar de REJECT, de modo que se descarte el paquete y no se responda de ninguna manera, lo cual ralentiza los escaneos de red (puesto que esperan el timeout en lugar de recibir una respuesta) y revela menos información. También desaconsejaría guardar logs de los datos, a menos que se disponga de la suficiente cantidad de espacio en disco duro, puesto que cada paquete que se envía (varios bytes) se utilizan muchos bytes de disco duro para crear la entrada del log, siendo fácil saturar el syslog y/o el disco duro en una conexión rápida. La página del ipchains se encuentra en: http://www.rustcorp.com/linux/ipchains/

#!/bin/bash

#

# Este script configura las reglas apropiadas de un cortafuegos para un

# servidor con 2 interfaces ejecutándose como puerta de enlace.

#

# Si se planea utilizarlo, es necesario editar este script.

#

# Se supone que las máquinas internas hacen todas una llamada a la puerta

# de enlace, de modo que las reglas no bloquean el tráfico interno.

#

# Un par de variables

#

# ETH0IP es la dirección IP de ETH0 (el interfaz externo)

# ETH0NET es la red

# ETH0NETMASK es la máscara de red

# HOSTFIABLE1 es un host fiable (para administración de web/ssh)

# HOSTFIABLE2 es un host fiable (para administración de web/ssh)

# ETH1IP es la dirección IP de ETH1 (el interfaz interno)

# ETH1NET es la red

# ETH1NETMASK es la máscara de red

#

ETH0IP=1.1.1.1

ETH0NET=1.1.1.0

ETH0NETMASK=24

HOSTFIABLE1=1.5.1.1

HOSTFIABLE2=1.5.1.2

ETH1IP=10.0.0.1

ETH1NET=10.0.0.0

ETH1NETMASK=24

#

PATH=/sbin

# LIMPIAR TODAS LAS REGLAS

ipchains -F input

ipchains -F output

ipchains -F forward

# ANTI-SPOOFING

ipchains -A input -p all -j DENY -s 10.0.0.0/8 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 127.0.0.0/8 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 192.168.0.0/16 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 172.16.0.0/16 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s $ETH0IP -i eth0 -d 0.0.0.0/0

# PRIMERO ICMP

ipchains -A input -p icmp -j ACCEPT -s $ETH0NET/$ETH0NETMASK -i eth0 -d 0.0.0.0/0

ipchains -A input -p icmp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0

# SSH

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE1 -i eth0 -d 0.0.0.0/0 22

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE2 -i eth0 -d 0.0.0.0/0 22

# BLOQUEO 1:1023

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023

# BLOQUEO DE OTRAS COSAS

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1109

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1524

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1600

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2003

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2049

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2105

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 4444

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6667

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 7000

# ADMINISTRACIÓN DE WEB

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE1 -i eth0 -d 0.0.0.0/0 10000

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE2 -i eth0 -d 0.0.0.0/0 10000

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 10000

# REGLAS DE REDIRECCIONAMIENTO

ipchains -P forward DENY

ipchains -A forward -p all -j MASQ -s $ETH1NET/$ETH1NETMASK -d 0.0.0.0/0

NETFILTER

El NETFILTER es la siguiente generación de filtrado de paquetes para Linux. Debería de hacer otro tipo de cosas más fácilmente, como cortafuegos, IPSec, cualquier cosa que tenga que ver con la gestión de paquetes. El HOWTO se encuentra disponible en: http://netfilter.kernelnotes.org/

IPF

El IPF es un paquete de cortafuegos alternativo, disponible para Linux (y la mayoría de sistemas operativos). Se puede conseguir en: http://cheops.anu.edu.au/

SINUS Firewall

El SINUS Firewall es un cortafuegos alternativo para Linux (kernel 2.0.x and 2.2.x). Se puede conseguir en: http://www.sinusfirewall.org/.

Phoenix Adaptive Firewall

Estoy en proceso de evaluar el producto, sin embargo parece bastante prometedor. Reemplaza ipchains completamente y añade un montón de inteligencia al proceso de filtrado. Sin embargo es un producto comercial (sobre los 3000$ US), y es el primer cortafuegos para Linux en estar certificado por la ICSA. Está disponible en: http://www.progressive-systems.com/products/phoenix/

Creación de Reglas

ipfwadm2ipchains

Un simple script que convierte las reglas de ipfwadm a ipchains, haciendo más fácil la migración. El script se encuentra disponible en la siguiente dirección: http://users.dhp.com/~whisper/ipfwadm2ipchains/

mason

Mason es un generador automático de reglas para ipfwadm e ipchains. Se carga y monitoriza el flujo de paquetes a través de la máquina, y después, basándose en eso crea un conjunto de reglas para permitir ese tipo de actividad (p. ej. si se hace un ftp al servidor desde un sitio remoto, permitirá ese tipo de acceso en las reglas que crea). Es una buena herramienta para administradores de cortafuegos novatos, disponible en: http://users.dhp.com/~whisper/mason/

firewall.sh

Un script basado en diálogo que te conduce a través de la creación de reglas de filtrado, bastante bien hecho y está orientado a nuevos usuarios, disponible en: http://devplanet.fastethernet.net/Utilities/

Mklinuxfw

Mklinuxfw es una herramienta perl dirigida a proporcionar una variedad de interfaces (CGI, KDE, línea de comandos, etc.) para la creación de reglas de cortafuegos. Actualmente soporta interfaz CGI y está en progreso el GTK. Se puede descargar de: http://www.madhouse.org.uk/~red/framepage.phtml?/mklinuxfw/index.html

kfirewall

kfirewall es una aplicación basada en GUI para la creación de reglas ipfwadm o ipchains. Se puede conseguir en: http://megaman.ypsilonia.net/kfirewall/

fwconfig

fwconfig es una herramienta interesante para configurar ipfwadm e ipchains, basada en www. Se puede descargar desde: http://www.mindstorm.com/~sparlin/fwconfig.shtml

xipfwadm

xipfwadm es una aplicación Tcl/Tk para X que simplifica la creación de reglas ipfwadm. Se puede conseguir en: http://www.x25.org/xipfwadm.html

Firewall Manager

Firewall Manager es una aplicación Tcl/Tk orientada a ser ejecutada desde X-Window que proporciona un GUI para gestión de cortafuegos. Se puede descargar desde: http://www.tectrip.net/arg/

Linux Firewall Tools

Un sitio interesante, tiene un cgi online para crear scripts de cortafuegos, aunque a mi no me funcionó (muy lento). Se puede ver en: http://www.linux-firewall-tools.com/.

FCT – Firewall Configuration Tool

Una de las herramientas de configuración online mediante cgi más avanzadas. Se puede probar en http://www.fen.baynet.de/~ft114/FCT/index.htm.

DNi

DNi es un cgi online que te ayuda a crear reglas de cortafuegos para ipfwadm. Se puede probar en: http://members.tripod.com/~robel/dni/.


Seguridad IP (IPSec)

29 julio 2009
Tutorial creado por Kurt Seifried. Extraido de: http://es.tldp.org/Manuales-LuCAS/GSAL/gsal-19991128-htm/
16 de Febrero de 2006

Seguridad IP (IPSec) es el cifrado del tráfico de red. No se puede cifrar la información de la cabecera ni el trailer (p. ej. la dirección IP y puerto de donde viene el paquete y su destino, los checksums de CRC, etc.), pero se puede cifrar la carga útil. Esto permite asegurar protocolos como POP/WWW sin tener que cambiarlos de ninguna forma, puesto que el cifrado se hace en el nivel IP. También permite conectar de forma segura LANs y clientes entre sí, sobre redes inseguras (como Internet). En la actualidad, IPSec para Linux está en fase de pruebas, sin embargo ya se han lanzado varias versiones estables, y yo mismo he desarrollado servidores seguros basados en IPSec. IPSec es un standard, y parte el protocolo IPv6, de modo que ya se puede comprar software IPSec para Windows 95/98/NT, Solaris y otros Unix, que interoperarán con Linux IPSec.

Soporte IPSec del kernel

Para utilizar IPSec es necesario tener soporte IPSec en el kernel. Desafortunadamente, ninguna distribución Americana de Linux puede exportar criptografía robusta fuera de Norte América, de modo que en general, suelen escoger no incluirla en absoluto, de las distribuciones extranjeras de Linux, en la actualidad ninguna viene con soporte IPSec dentro del kernel. Es necesario conseguir el código fuente del kernel (recomiendo la 2.2.10, la más reciente a la hora de escribir esto), y el código fuente del Linux IPSec, disponible en: http://www.xs4all.nl/~freeswan/

Instala el fuente del kernel (generalmente en /usr/src/linux) y compila el nuevo kernel, instálalo, arráncalo y pruébalo. Asegúrate de que tus redes funcionan correctamente, si no funcionan, hacer que lo haga IPSec será imposible. Ahora hay que descargar la última instantánea de IPSec (la versión 1.0 NO funcionará con los kernels 2.2.x). Después ir a /usr/local/src (o dondequiera que hayas puesto el código fuente de tus programas), desempaquetar el fuente y ejecutar el programa de instalación (make menugo suele ser lo habitual para la configuración basada en ncurses). Lo cual parcheará los ficheros del kernel, luego ejecuta la configuración del kernel y después construye las herramientas IPSec y el kernel.

cd /usr/local/src/

tar –zvvxf /path/del/tarball/snapshot.tar.gz

chown –R root:root freeswan-snap1999Jun14b

cd freeswan-snap1999Jun14b

make menugo

asegúrate de guardar la configuración del kernel, incluso aunque se hayan elegido las opciones, no han sido guardadas. También tendrás que reconstruir el kernel, puesto que el comando “make menugo” ejecuta un “make zImage”, lo cual suele fallar, debido a los grandes tamaños del kernel de la 2.2.x. Una vez que se ha hecho la compilación, debería dar uno o dos mensajes de error, simplemente haz:

cd /usr/src/linux

make bzImage

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.10-ipsec

Ahora hay que editar lilo.conf, ejecutar lilo de nuevo y reiniciar para hacer uso del nuevo kernel.

lilo.conf debería tener el siguiente aspecto:

boot=/dev/hda

map=/boot/map

install=/boot/boot.b

prompt

timeout=100

image=/boot/vmlinuz-2.2.10-ipsec

label=linux-ipsec

root=/dev/hda1

read-only

image=/boot/vmlinuz-2.2.10

label=linux

root=/dev/hda1

read-only

vuelve a ejecutar lilo y verás:

linux-ipsec *

linux

después reinicia y deberías estar ejecutando el kernel 2.2.10 con soporte IPSec. A medida que la máquina se reinicia y empieza el IPSec se verán varios errores, por defecto IPSec está configurado para utilizar el interfaz eth999, el cual por supuesto no existe. Deberías añadir /usr/local/lib/ipsec en la frase del path o si no tendrás que escribir el path completo un montón.

Configuración de redes IPSec

Tendrás que habilitar el TCP-IP forwarding en el servidor de enlace, en Red Hat Linux se hace cambiando la línea de /etc/sysconfig/network:

FORWARD_IPV4=”false”

por:

FORWARD_IPV4=”yes”

o se puede habilitar vía sistema de ficheros en /proc:

cat 1 > /proc/sys/net/ipv4/ip_forward

Puesto que la mayoría de la gente tiene por defecto políticas de denegación de paquetes de forwarding, tendrás que permitir que los paquetes atraviesen la rede remota / máquina de tu red / máquina y vice versa. Además de esto, cualquier regla de enmascaramiento para redes internas que también estén usando IPSec debe venir después de las reglas que permiten el tráfico IPSec, o la máquina intentará enmascarar los paquetes, en lugar de pasarlos al IPSec.

El siguiente ejemplo es para dos redes protegidas (usando direcciones IP no rutables, escondidas tras máquinas Linux haciendo enmascaramiento de IPs) conectadas vía Internet:

10.0.0.2 192.168.0.2

10.0.0.1 192.168.0.1

1.2.3.4 5.6.7.8

1.2.3.1 5.6.7.1

2.3.4.5 6.7.8.9

INTERNET

Conexión manual de llaves

Primero configuraremos un enlace utilizando la conexión manual de llaves (por simplicidad), hay que editar ipsec.conf, y las reglas del cortafuegos. La mayoría de las opciones por defecto del fichero ipsec.conf son correctas, pero hay que cambiar lo siguiente:

conn ejemplo

type=tunnel

left=

leftnexthop=

leftsubnet=

right=

rightnexthop=

rightsubnet=

spibase=0x200

esp=3des-md5-96

espenckey=

espauthkey=

reemplaza la espenckey y la espauthkey con las nuevas llaves (utilizando ranbits para generar un número, recuerda dejar el 0x por delante, que especifica que es un número hexadecimal) de modo que es algo así:

conn mi-tunel

type=tunnel

left=1.2.3.4

leftnexthop=1.2.3.1

leftsubnet=10.0.0.0/24

right=5.6.7.8

rightnexthop=5.6.7.1

rightsubnet=192.168.0.0/24

spibase=0x200

esp=3des-md5-96

espenckey=cualquier_llave_de_autentificación (ranbits 192)

espauthkey=cualquier_otra_llave (ranbits 128)

Una vez que has acabado, copia los ficheros ipsec.conf e ipsec.secrets desde la máquina en que los editaste hasta el otro servidor, de forma segura. Ahora, lo único que queda es añadir reglas al cortafuegos para que no se enmascaren los paquetes (en lugar de eso lo que queremos es redirigirlos, hacer un forward).

En el servidor 1.2.3.4 se deberían añadir las siguientes reglas:

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0./24

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

asegúrate de que estas reglas aparecen antes de la regla de enmascaramiento, algo así:

#

# FORWARD RULES

#

ipchains –P forward DENY

#

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0/24

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

ipchains –A forward –p all –j MASQ –s 10.0.0.0/24 –d 0.0.0.0/0

Y en el servidor 5.6.7.8 se repetiría el proceso:

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0/24

asegúrate de que estas reglas aparecen antes de la regla de enmascaramiento, algo así:

#

# FORWARD RULES

#

ipchains –P forward DENY

#

ipchains –A forward –p all –j ACCEPT –s 192.168.0.0/24 –d 10.0.0.0/24

ipchains –A forward –p all –j ACCEPT –s 10.0.0.0/24 –d 192.168.0.0/24

ipchains –A forward –p all –j MASQ –s 192.168.0.0/24 –d 0.0.0.0/0

Ahora deberías ser capaz de establecer el túnel ipsec manualmente en ambas máquinas, y las máquinas de la Red A deberían ser capaces de hablar con las máquinas de la red B sin problemas.

ipsec manual –up mi-tunel

lo cual mostraría una salida similar a:

/usr/local/lib/ipsec/spi: message size is 36

/usr/local/lib/ipsec/spi: message size is 132

/usr/local/lib/ipsec/spi: message size is 132

Para probarlo, haz un ping a 192.168.0.2 desde el cliente 10.0.0.2. Si funciona, lo has configurado correctamente. Si no funciona, verifica tu red para asegurarte de que 1.2.3.4 puede ver 5.6.7.8 y que está habilitado el TCP-IP forwarding, y asegúrate de que no hay reglas del cortafuegos que estén bloqueando paquetes o intentando enmascararlos. Una vez que has establecido y probado la conexión con éxito, deberías pasar a la conexión automática de llaves (especialmente en entornos de producción).

Conexión automática de llaves

Si se intenta usar IPSec en un entorno de producción, la conexión manual de llaves es una mala idea, en términos generales. Con la conexión automática se tiene un secreto compartido de 256bit que se copia a ambos lados del túnel, el cual se utiliza durante el intercambio de llaves para asegurarse que no se dan ataques del tipo “man in the middle, hombre de por medio”. Con la conexión automática, la vida media de una llave es de 8 horas, lo cual se puede ajustar a cualquir intervalo, y si alguien se las arregla para atacar por fuerza bruta la llave, sólo será válida durante ese período de tráfico de 8 horas. El ejemplo siguiente se construye sobre el anterior:

ipsec.secrets contiene el secreto compartido. Este fichero debe ser puesto a salvo a toda costa. Para una conexión entre los servidores 1.2.3.4 y 5.6.7.8 se necesitaría una línea como:

1.2.3.4 5.6.7.8

“0xa3afb7e6_20f10d66_03760ef1_9019c643_a73c7ce0_91e46e84_ef6281b9_812392bf”

Esta línea necesita estar en ambos ficheros ipsec.secrets. Después se necesitaría editar la configuración del túnel en ipsec.conf por la siguiente:

conn mi-tunel

type=tunnel

left=1.2.3.4

leftnexthop=1.2.3.1

leftsubnet=10.0.0.0/24

right=5.6.7.8

rightnexthop=5.6.7.1

rightsubnet=192.168.0.0/24

keyexchange=ike

keylife=8h

keyingtries=0

Entonces se arrancaría el demonio pluto, intenta conectar al demonio Pluto desde el otro extremo del túnel, y establece una conexión. Una advertencia, Pluto se ejecuta en el puerto 500, udp, de modo que lo más probable es que tengas que abrir un hueco en el cortafuegos para permitirle pasar:

ipchains –A input –p udp –j ACCEPT –s 0.0.0.0/0 –i eth0 –d 0.0.0.0/0 500

Encuentro conveniente el uso de la clave “%search” en lugar de listar el túnel a arrancarse, añadiendo:

auto=start

para cada configuración del túnel y editar el ipsec.secrets:

plutoload=%search

plutostart=%search

Lo cual a la larga te hará la vida más fácil. Si todo va bien, deberías ver algo parecido a esto en /var/log/messages:

|| Jun 26 02:10:41 server ipsec_setup: Starting FreeS/WAN IPSEC… Jun 26 02:10:41 server ipsec_setup: /usr/local/lib/ipsec/spi: message size is 28 Jun 26 02:10:41 server ipsec_setup: KLIPS debug ‘none’ Jun 26 02:10:41 server ipsec_setup: KLIPS ipsec0 on eth0 1.2.3.4/255.255.255.0 broadcast 24.108.11.255 Jun 26 02:10:42 server ipsec_setup: Disabling core dumps: Jun 26 02:10:42 server ipsec_setup: Starting Pluto (debug ‘none’): Jun 26 02:10:43 server ipsec_setup: Loading Pluto database ‘mi-tunel’: Jun 26 02:10:44 server ipsec_setup: Enabling Pluto negotiation: Jun 26 02:10:44 server ipsec_setup: Routing for Pluto conns ‘mi-tunel’: Jun 26 02:10:45 server ipsec_setup: Initiating Pluto tunnel ‘mi-tunel’: Jun 26 02:10:45 server ipsec_setup: 102 “mi-tunel” #1: STATE_MAIN_I1: initiate Jun 26 02:10:45 server ipsec_setup: 104 “mi-tunel” #1: STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2 Jun 26 02:10:45 server ipsec_setup: 106 “mi-tunel” #1: STATE_MAIN_I3: from STATE_MAIN_I2;sent MI3, expecting MR3 Jun 26 02:10:45 server ipsec_setup: 003 “mi-tunel” #1: STATE_MAIN_I4: SA established Jun 26 02:10:45 server ipsec_setup: 110 “mi-tunel” #2: STATE_QUICK_I1: initiate Jun 26 02:10:45 server ipsec_setup: 003 “mi-tunel” #2: STATE_QUICK_I2: SA established Jun 26 02:10:46 server ipsec_setup: …FreeS/WAN IPSEC started ||

Y en el fichero /var/log/secure se debería ver algo parecido a esto:

|| Jun 26 02:10:42 server Pluto[25157]: Starting Pluto (FreeS/WAN Version snap1999Jun14b Jun 26 02:10:42 server Pluto[25157]: added connection description “mi-tunel” Jun 26 02:10:42 server Pluto[25157]: listening for IKE messages Jun 26 02:10:42 server Pluto[25157]: adding interface ipsec0/eth0 1.2.3.4 Jun 26 02:10:42 server Pluto[25157]: loading secrets from “/etc/ipsec.secrets” Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #1: initiating Main Mode Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #1: ISAKMP SA established Jun 26 02:10:42 server Pluto[25157]: “seifried-mosqueado” #2: initiating Quick Mode POLICY_ENCRYPT+POLICY_TUNNEL+POLICY_PFS Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #2: sent QI2, IPsec SA established Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #3: responding to Main Mode Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #3: sent MR3, ISAKMP SA established Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #4: responding to Quick Mode Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #4: IPSec SA established Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #5: responding to Main Mode Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #5: sent MR3, ISAKMP SA established Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #6: responding to Quick Mode Jun 26 02:10:42 server Pluto[25157]: “mi-tunel” #6: IPsec SA established ||

Además de esto se puede ver la salida de “eroute” para asegurarse de que los túneles están correctamente configurados:

10.0.0.0/24 -> 192.168.0.0/24 => tun0x114@1.2.3.4

Y si le echas un vistazo a tus rutas (“route”), deberías ver:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

1.2.3.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1

1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

1.2.3.0 0.0.0.0 255.255.255.0 UG 0 0 0 ipsec0

192.168.0.0 1.2.3.1 255.255.255.0 UG 0 0 0 ipsec0

10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 1.2.3.1 0.0.0.0 UG 0 0 0 eth0

Productos IPSec comerciales

He pensado que sería interesante hacer un breve listado de los productos IPSec comerciales, por supuesto haciendo énfasis en los basados en Linux y FreeS/WAN

i-data

i-data desarrolla una línea de productos que incluyen un servidor VPN, basado en Linux y en FreeS/WAN. Están ubicados en Dinamarca, lo cual les permite que su producto esté disponible para todo el mundo. El sitio web está en: http://www.i-data.com/networks/

Productos IPSec para Windows

También existen paquetes de software que proporcionan capacidad de IPSec para Windows, uno de los cuales incluso es gratuito.

PGP VPN

Los autores de PGP (Network Associates) han creado un paquete de software “PGP VPN” (que tiene muy poco que ver con PGP). Soporta IPSec y se dice que también opera con Linux FreeS/WAN. Se puede conseguir en: http://www.nai.com/asp_set/products/tns/pgp_vpn.asp

IRE

[[http://www.ire.com/ http://www.ire.com%5D%5D


Microsoft mintió sobre su apertura a la licencia GPL

27 julio 2009

Gracais compañero ToxicShell por la informacion e investigue mas aqui pongo lo que obtuve

Después de que Microsoft haya anunciado con bombos y platillos la liberación de 20000 líneas de código para tres controladores bajo licencia GPL2, ahora se descubrió que esa apertura fue para evitar una potencial disputa legal sobre la violación de la licencia GPL, que no permite la mezcla de códigos cerrados y elementos de código abierto.

Según el portal The Register, Stephen Hemminger ingeniero de Open Source Vyatta, se dio cuenta que uno de los drivers del código de software Hyper-V de Microsoft hacía uso de componentes GPL, algo que está prohibido a no ser que esos mismos drivers también sean liberados, y esa parece haber sido la verdadera causa del supuesto cambio de actitud de Redmond.

Cuando Hemminger descubrió el problema, se puso en contacto con el responsable del Linux Driver Project y programador en Novell, Greg Kroah-Hartman, para que ambos colaboraran con Microsoft para poder solucionar ese conflicto, esperando que la relación de interoperabilidad entre Novell y Microsoft facilitara la resolución del problema.

El tema es que de acuerdo a Hemminger, Microsoft anunció esa liberación como algo que realmente no era. Es decir, la compañía hizo el anuncio como si se tratara de un “hito importante”, un “poderoso catalizador” para el cambio y un “buen ejemplo” de cómo se cumplen las demandas de los clientes, cuando en realidad sólo fue para evitar un embarazoso problema jurídico.

Por otro lado, una periodista de ZDNet se contactó vía email con Kroah-Hartman para verificar la información, y le preguntó si era cierto que Hemminger había reclamado poner las líneas de código bajo la GPL, ya que sino se estaría violando la licencia, y si tuvo que sugerirle a Microsoft que hiciera la apertura. Al respecto, Kroah-Hartman respondió: “yo no tenía que sugerir nada, sólo me limité a mencionar la evidencia de la situación”.

A su vez, en The Register destacan que Microsoft quizás tergiversó las causas de esa liberación por la importancia política y estratégica de la tecnología Hyper-V de la empresa, o por el prestigio de adoptar la licencia GPL y acelerar la ejecución de Linux en Hyper-V, para taparle la boca a los escépticos.

El portal también señala que la combinación de códigos abiertos y cerrados en los drivers Hyper-V puede haber sido producto de personas que no sabían lo que estaban haciendo, o no comprendieron la licencia, y que Microsoft no sería la única empresa que incurre en esta falta.

Sin embargo, The Register pone de manifiesto que dada la rivalidad existente entre Microsoft y los sistemas de código abierto, no se puede confiar en esas especulaciones, ya que lo más seguro es que los de Redmond tengan cosas que ocultar, y que la aceptación del código abierto dentro de la corporación no debe ser tan generalizada como quisieron hacer creer con su reciente anuncio.

Fuente
http://www.redusers.com/microsoft-mintio-s…la-licencia-gpl



Microsoft entrega su primer aporte al kernel de Linux

23 julio 2009

(cc) por ohem

Por primera vez en su historia, el gigante del software entrega un aporte de código abierto directamente al kernel de Linux. Se trata de unas 20.000 líneas de código licenciado como GPLv2 que implementan los drivers necesarios para correr Linux virtualizado sobre plataforma Windows. El código que ya está en manos de los desarrolladores del kernel, permitirá obtener el mejor rendimiento posible cuando se utilice Linux virtualizado sobre Windows Server 2008 Hyper-V o Windows Server 2008 R2 Hyper-V.
Este aporte es parte de un esfuerzo que realiza el Open Source Technology Center de Microsoft. Se trata de una unidad que actúa como un punto de unión entre las comunidades de código abierto interesadas en trabajar con Microsoft, y los equipos al interior de la compañía interesados en la tecnología de código abierto. Desde el OSTC de Microsoft han surgido otros aportes al código abierto como las mejoras a PHP para ejecutarse sobre Windows, el apoyo a Firefox para mejorar su rendimiento sobre Windows Vista, y la participación en varios proyectos de Apache Software Foundation como Axis2, Hadoop, Stonehenge y QIPD.
En esta oportunidad, se trata de un paso necesario dado la creciente realidad de que el entorno corporativo necesita manejar sistemas heterogéneos, en donde cada sistema operativo satisface distintas necesidades. Sam Ranji, a cargo del OSTC dice:

Cada vez es más frecuente que las compañías busquen ayuda en Microsoft para tener éxito en un mundo de tecnología heterogénea, porque entendemos que reducir la complejidad es un factor clave para reducir el costo.

Luego agrega:

Por lo tanto hay un beneficio mutuo para los clientes, Microsoft y las distribuciones de Linux comerciales y basadas en comunidad, al mejorar el rendimiento de Linux como un sistema operativo virtualizado en Windows Server.

Sam dice que mucha gente desconoce el esfuerzo en código abierto que están realizando porque están más enfocados en trabajar en ello que en promoverlo. Como compañía les interesa que sus clientes tengan libertad de opción a la hora de escoger tecnologías, y muchos de ellos están utilizando software de código abierto sobre sus plataformas Windows.
Tanto el imparable desarrollo de tecnologías de código abierto como la necesidad de consolidar plataformas y reducir los costos – debido a las condiciones de la economía – hacen que navegar contra esta revolución sea un esfuerzo inútil. La demanda de los propios clientes de Microsoft por mejorar la interoperabilidad es un factor clave para mantener estos esfuerzos.
En palabras de Sam Ramji:

A medida que el código abierto se adopta en un rango de plataformas, entender, involucrarse y dar soporte al desarrollo de código abierto continuará siendo fundamental para permitir mayor elección a los clientes.

Links :
Microsoft contributes Linux drivers to Linux Community (Microsoft)
Microsoft contributes code to the Linux Kernel (Channel 9)


Administracion de usuario en PHP

23 julio 2009

1.pagina de login (index.php)

2.una de verificacion de login (verifica.php) // aki es donde haces una consulta a tu DB consultando el nivel de user que tiene el usuario que se esta loggiando, por ejemplo, nivel=0 si es admin, y nivel=1 cliente. y despues viene la redireccion.
2.1 Una web con el contenido de Administracion (admin.php //para nivel=0)
2.2 Una web con el contenido de Clientes (cliente.php//nivel=1)
//aki lo sintetizo mejor con un codigo q esta trabajando

<?php

include(“conecta.php”);

$link = Conectarse();

$rut = $_POST[“rut”];
$pass = $_POST[“pwd”];

if($rut == “” || $pass == “”){

echo”<h2>Debe ingresar su Rut y Contraseña</h2>”;
?><META HTTP-EQUIV=”Refresh” CONTENT=”5; URL=login2.php”><?
mysql_close($link);
}
else {

if (ereg(“^[a-zA-Z]+$”,$rut)){

echo”debe ingresar valores validos para un rut”;
mysql_close($link);
}
else{

$result = mysql_query(“SELECT clave, rut, nombre, id_nivel FROM usuario WHERE rut=$rut”);
$c = 0;

if($row = mysql_fetch_array($result)){

if($row[“clave”] == $pass && $row[“id_nivel”] == “1”){
session_start();
$c = 1;
$_SESSION[‘nombre_s’] = $row[“nombre”];
$_SESSION[‘rut_s’] = $row[“rut”];
$nombre1 = $row[“nombre”];
echo “<h1>Bienvenido “,$row[“nombre”], ” sera redireccionado breve” ?>
<META HTTP-EQUIV=”Refresh” CONTENT=”3; URL=cliente.php?nombre1=<?php echo
$nombre1 ?>”><?;

}

if($row[“clave”] == $pass && $row[“id_nivel”] == “0”){
session_start();
$c = 1;
$_SESSION[“nombre_s”] = $row[“nombre”];
$nombre1 = $row[“nombre”];
echo “<h1>Bienvenido “,$row[“nombre”], ” sera redireccionado en breve” ?>
<META HTTP-EQUIV=”Refresh” CONTENT=”2; URL=administrador.php?nombre1=<?php
echo $nombre1 ?>”><?;

}
if($c==0){echo”<h1>La Password no concuerda”?><META HTTP-EQUIV=”Refresh” CONTENT=”2; URL=index.php”><?;}
}else {echo”no se encontro registrado el Rut digitado”;}

}

}

?>


Llamar un SP de MySql con PHP

23 julio 2009

Perdon, tuve una omision. Se agradece al amigo Gustavo por la informacion al final viene el link del compañero.

Saludos

definir los script en php que se conectaran a esta BD y llamar el procedimiento, para ello primero creamos un archivo llamado BD.php que nos permitira configurar la conexion a la BD.

BD.php

01.<?php
02.
03.class BD{
04.var $servidor;
05.var $usuario;
06.var $clave;
07.var $bd;
08.var $conexion;
09.
10.function BD()
11.{
12.$this->servidor = "localhost";
13.$this->usuario  = "tu_user";
14.$this->clave    = "tu_clave";
15.$this->bd       = "ejemplos_mysql"; // asi se llama nuestro ejemplo
16.}
17.function conectar_li()
18.{
19.$this->conexion = mysqli_connect($this->servidor,$this->usuario,$this->clave,$this->bd);
20.return $this->conexion;
21.}
22.function getBD()
23.{
24.return $this->bd;
25.}
26.}
27.
28.?>

Lo siguiente es definir un script que nos permita llamar a todos los objetos creados en nuestra BD en mysql que en este caso contara con un solo procedimiento, el de registro, este script se llamara Servidor.php.

Servidor.php

01.<?php
02.class Servidor{
03.var $conexion;
04.
05.function registro($nick_var, $email_var, $mensaje_var){
06.$result = mysqli_query($this->conexion,"select registro('$nick_var', '$email_var', '$mensaje_var');");
07.$row = mysqli_fetch_array($result);
08.return $row[0];
09.}
10.}
11.?>

Como notaron, estamos usando quizas demasiados archivos para un ejemplo tan sencillo que puede hacerse todo en un script php, pero si entienden este ejemplo nos servira mucho para poder avanzar con el chat en ajax.

Ahora ejecutemos el ejemplo con un script de prueba

prueba.php

01.<?php
02.include("BD.php");
03.
04.$bd = new BD();
05.$conexion = $bd->conectar_li();
06.
07.include("Servidor.php");
08.
09.$servidor = new Servidor();
10.$servidor->conexion = $conexion;
11.
12.$nick = 'Gustavo Delgado';
13.$email = 'gustavo.uach@gmail.com';
14.$pregunta = 'esto deberia quedar en la BD no......¿?';
15.
16.$id_usr = $servidor->registro($nick, $email, $pregunta);
17.
18.echo "Tu id de la tabla de usuario es:  ".$id_usr;
19.?>

Al ejecutar el ejemplo deberiamos ver el id_usuario = 1 si es que no se han ingresado datos anteriormente, en caso contrario veremos el id correpsondiente a la nueva insercion.

Obs: Partimos del supuesto de que tienes un servidor http, con mysql y php instalado.

Autor Gustavo
codigox.tk
gustavo.uach@gmail.com

Fuente: http://www.inspiracion.cl/codigox/2009/04/llamar-un-sp-de-mysql-con-php/