Lugar desolado! Ya nos mudamos

Estimado visitante, este blog esta sin manetenimiento.

Ahora podés visitar http://www.netsecure.com.ar,
donde encontraras los mismos artículos que aquí y mucho más.

Gracias.

Anuncios

2da parte del Manual de HPing

Ya esta disponible la segunda parte del manual/tutorial de hping en NetSecure.com.ar

http://www.netsecure.com.ar/2010/10/20/manual-tutorial-de-hping-con-ejemplos-ii/

Nuevo post en Netsecure.com.ar

Gente querida,

Pueden encontrar en http://netsecure.com.ar/2010/05/20/manual-tutorial-de-hping-con-ejemplos-i/, el primer artículo que conformará un manual lo mas completo posible de Hping y sus posibles usos, con los ejemplos necesarios, para aprender a explotarlo a full.

Espero que les guste!

Comercialización de la seguridad

Hace unas semanas atraz, un artículo publicado en Security Focus[0], en el cual se comenta que los contenidos de la misma van a ser movidos paulatinamente a la web de Symantec, me dejo preocupado ya que Security Focus ha sido un pilar para la seguridad informática en la red de redes.  Por ejemplo,  las listas de correo  Pentest como Bugtraq, son un paso obligado para quien quiera estar informado sobre lo último en seguridad informática,  ya que son una base de conocimiento y datos muy grande.

En el año 2002, Security Focus fue adquirida por Symantec si sufrir muchos cambios,  Symantec, dice que con la compra reconoce la importancia de mantener una buena relación con la comunidad abocada a la seguridad, y seguro que lo hace.  Sin embargo, su artículo “Change in Focus” no me convence en lo mas minimo.

La misma inseguridad me causa casos como el de Nessus, el cual surgio como un proyecto libre y termino siendo cerrado, con el mismo fin lucrativo que Symantec comienza a desviar el tráfico de Security Focus.

Mi punto de vista, tiene que ver con la historia de la seguridad informática, ya que siento que de manera sutil el sector ha ido siendo sobre utilizado por empresas, que al hablar de seguridad sus pupilas se transforman en signos de pesos.

Mi punto de vista:

La tecnología es una revolución que aún no acaba, es decir, esta en constante cambio,  y los últimos años pueden considerarse un poco mas llamativos aún.  Desde la burbuja de las “.com” (’98 aproximadamente, hasta 2001) internet como se la conocía cambió dramáticamente, empezando desde las tecnologías de acceso, que permitieron mayores velocidades y por consiguiente nuevos tipos de servicios.

Así la masificación trajo consigo un aumento de la participación, que amplió el mercado, y causó un mayor interés por parte de las empresas. Los cambios en la cultura, pueden verse en el boom de los weblogs y luego en las redes sociales, en las cuales, muchas empresas vieron un nuevo espacio para la publicidad y la venta de sus productos, y todo esto ayudado en gran parte con la idea de la web 2.0.

Ineludiblemente, al aumentar la cantidad de servicios, tecnologías de accesos, cantidad de empresas online y la cantidad de gente que accede, también la seguridad informática se transformó en tópico de interés de muchos, y cuando hay demanda, “alguien” tiene que suplirla…

Los primeros en llegar al terreno de la seguridad (de forma masiva) fueron las empresas que comercializaban antivirus, ya que este era el miedo del público conectado a la red. Pero en un mundo que avanza constantemente, aumentaron las amenazas y los antivirus fueron solo una parte de las necesidades, en particular para las grandes corporaciones que necesitaban conectarse para existir, y fue así es como la necesidad creo lacomericialización de la seguridad.

Mis preguntas:

¿Cuan bueno es que todo el conocimiento y estudio de una comunidad abierta pueda ser dominada y absorbida por una compania?

¿ Como puede la comunidad librarse del factor humano subordinado a la necesidad del dinero?

¿ que ventajas tiene el apoyo de las empresas a las comunidades abiertas?

¿ Como influye este tipo de movimientos a la neutralidad que queremos en internet?

¿ Correrá el mismo riesgo las comunidades libres sobre seguridad, como por ejemplo OWASP ( http://www.owasp.org/ ) ?

¿ Que diríamos si Nmap pasaría a ser una herramienta privativa y rentada?

Mi conclusión:

Con el paso del tiempo, las comunidades no salen beneficiadas cuando la información generada en colaboración de forma libre es utilizada para beneficios de unos pocos de forma rentada, por lo que no dejo de convencerme que la mejor manera de luchar contra este tipo de conflictos es el uso y recomendación de los estándares abiertos, así como del desarrollo de aplicaciones GNU y no open source solamente.

Este artículo puede se encuentra en http://netsecure.com.ar y http://www.netvulcano.com.ar

Ruteo en Linux vs Cisco – Parte 2

Para seguir evaluando las difrencias y similitudes en ambas plataformas (ver parte 1),  trataré de ir haciendo una muestra de equivalencias en ambos sistemas, para que pueda ser usado como “diccionario” para los habitantes de estos dos mundos.

Privilegios

En el mundo de los sistemas, conozco un solo sistema operativo anarquico, es decir, donde cualquier usuario puede llegar a cambiar cualquier configuración, pero no es el tema de este artículo, si no por el contrario, tanto linux como IOS (sistema operativo de CISCO), necesitamos ciertos privilegios en el sistema para poder cambiar una configuración.
Basicamente, en linux tenemos a los usuarios, los grupos, y el usuario root.
Los permisos se otorgan mediante distintos permisos en los archivos, siendo que los archivos tienen un dueño (un usuario), tambien tienen un grupo, el cual es un conjunto de usuarios. De esta manera, linux puede distribuir ciertas responsabilidades en distintos usuarios. Sin embargo, el poder de todo lo tiene el usuario “root” (esto no es nada particular de linux, si no mas bien de los sistemas operativos unix).

Así cuando querramos configurar algo en nuestro linux deberemos tener acceso al usuario root.

Podemos pasar de usuario común a root de la siguiente manera:

usuario@myhome:~$ su - root
Password:
myhome:~#

Tipicamente, en los unix, ver el signo  # significa tener los permisos de superusuario (root).
Algo parecido (en realidad identico pero enmascarado), sucede en los sistemas IOS.
Cuando iniciamos por primera vez un router cisco, y nos conectamos mediante una terminal (hyperterminal o minicom), vemos esto:

Router>

Que significa que solo tenemos acceso a un limitado número de comandos, para poder ejecutar comandos que afecten a la configuración del router debemos ejecutar el comando “enable”.

Router>enable
Router#

Como vemos el prompt, nos muestra el signo #, que nos indica que tenemos los permisos equivalentes a root, en un sistema unix.
En este caso, ejecutar el comando enable nos transforma automaticamente en superusuarios, sin embargo, cuando se configura un router, mas que para realizar unas pruebas, se establece una contraseña, asi mismo, se puede establecer una contraseña para el usuario mas básico, de forma tal que nadie que no conozca la contraseña pueda siquiera husmear en el router.

Router>enable
Password:
Router#

Al instalar un IOS, lo primero que debemos hacer es configurar una contraseña,
para estar mas seguros de que nadie meterá las narices donde no debe.

Tanto IOS como linux, tienen mecanismos similares de autenticación, en el caso de linux pueden ser mucho mas avanzado, sin embargo no suelen tener mucha reelevancia si queremos que actue solo como router.

Guardar Cambios

Una diferencia, que si bien es simple, pero importante, es como ambos sistemas, es la forma en que estos guardan los cambios efectuados.
En ambas plataformas,  los cambios de configuración se hacen inmediatamente al ejecutar el comando, sin embargo, este cambio solo dura, hasta que se reinicie el equipo. Para perdurar los cambios mas allá de los reinicios, en las plataformas cisco, debemos ejecutar el comando “write”, este comando guarda todas los cambios realizados en el equipo, y volveran a ser levantadas una vez que se reinicie.

En linux, no existe un comando tan general que guarde todos los cambios realizados, si no que cada configuración o variable, tiene su o sus archivo/s. En las siguientes secciones revisaremos esos archivos y la forma analoga de hacerlo en cisco.

Configuración de interfaces en [ Linux | Cisco ]

Algo fundamental en cualquier dispositivo de red, es poder configurar las interfaces de red.
Compararemos los siguientes puntos, para hace un primer “approach”, en estas equivalencias entre cisco y linux.

En este post nos encargaremos de analizar y comparar estos puntos.

Configuración básica

Salvado de información

Visualización de datos


Configuración básica

Para asignara una dirección de red a una interfaz en linux (como root):

ifconfig eth0 192.168.1.1 netmask 255.255.255.0

Aún que vale recalcar que esto se mantiene por compatibilidad con los unixs, ya que la mejor manera de configurar las interfaces en linux, es con el pack de utilidades iproute2, que se haría de la siguiente manera:

ip addres add 192.168.1.1 dev eth0

Para agregar una descripción podemos agregarla en los archivos de configuración que veremos mas abajo.

En un router cisco, lo hariamos de la siguiente manera:

Router>enable
Router#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface FastEthernet 0/0
Router(config-if)#no shutdown
Router(config-if)#ip address 192.168.1.1 255.255.255.0

Al momento de ejecutar el comando enable, el router puede pedirnos un password, este password se configurar
en la instalacion del router, aunque puede quedar sin password, como en este caso.

Para agregar una descripción podemos usar:

Router(config-if)#description "Ethernet conectada a la dmz"

Para configurar el hostname de un router Cisco:
Router>enable
Router#config t
Router(config)#hostname MyRouter
MyRouter(config)#exit
MyRouter#write

El "write" graba todos los cambios hechos, por lo cual insisto en ser cuidadosos con este comando, por que si ademas de cambiar el nombre, cambiamos otra cosa, quedará grabado al ejecutar "write"
En linux, necesitamos ser root,  y lo hacemos de la siguiente manera:

gustavo@Onix:~$ su -
Contraseña:
Onix:~# hostname MyHostname
Onix:~#

Como vemos, el comando es igual que en cisco, sin embargo, pareciera ser que no cambia automáticamente el hostname,  sin embargo si es asi, solo que el hostname que vemos en nuestra consola ( Onix:~# ) es una variable que se configura en el momento que iniciamos sesión. Por lo tanto, si ejecutamos el comando exit, y volvemos a loguearnos, ya aparecerá el nombre cambiado.
Otra forma de cambiar el hostname, es ejecutando:

Onix:~# echo "MyHostname"  > /proc/sys/kernel/hostname

De todos modos, el hostname no cambiara en nuestra consola, hasta que loguemos de nuevo.
Los comandos vistos recientemente,  no cambian el hostname de nuestro linux permanentemente. Para hacerlo permanente mente, debemos editar el archivo: /etc/hostname

En este caso no necesitamos editarlo con un editor, ya que es solo una linea la que hay que cambiar:

echo "MyHostname" > /etc/hostname

Salvado de configuración de las interfaces

Tanto en Cisco, como en Linux, los cambios explicados arriba, se pierden a la hora de reiniciar el equipo. Los dos sistemas tienen formas de guardar esta información, a saber:
En una distro tipo Debian el archivo es: /etc/network/interfaces
En los sistemas tipo RedHat el archivo es: /etc/sysconfig/network-scripts/ifcfg-[nombre de la intefaz]
Para poder editar estos archivos usamos cualquier editor de texto instalado. Generalmente Vi.
Una vez editado el archivo correspondiente, los cambios no se aplican hasta que reiniciemos los scripts de red.

En la plataforma Cisco, una vez realizado el cambio pretendido, si se quiere guardar dicho cambio, se hace de la siguiente manera:

Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#exit
Router(config)#exit
Router#write
Building configuration...
[OK]
Router#

Este comando, guarda todos los cambios realizados en el router, por lo cual hay que tener cuidado al utilizarlo, por que podemos estar guardando algun otro cambio que hayamos realizado.

Visualización de datos

En ocaciones necesitamos visualizar cierta información de las interfaces, en Cisco podemos hacerlo de la siguiente manera:

Router>show interfaces
FastEthernet0/0 is administratively down, line protocol is down (disabled)
 Hardware is Lance, address is 00e0.8f0d.d501 (bia 00e0.8f0d.d501)
 Description: "Ethernet conectada a la dmz"
 Internet address is 192.168.1.1/24
 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255
 Encapsulation ARPA, loopback not set
 ARP type: ARPA, ARP Timeout 04:00:00,
 Last input 00:00:08, output 00:00:05, output hang never
 Last clearing of "show interface" counters never
 Queueing strategy: fifo
 Output queue :0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 0 packets input, 0 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 0 input packets with dribble condition detected
 0 packets output, 0 bytes, 0 underruns
 0 output errors, 0 collisions, 1 interface resets
 0 babbles, 0 late collision, 0 deferred
 0 lost carrier, 0 no carrier
 0 output buffer failures, 0 output buffers swapped out
....

Este comando nos lista abundante información de todas las interfaces de red.

En Linux ejecutamos:

Para ver información sobre una sola interfaz:

/sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:17:77:cd:1b
 inet addr:192.168.1.3  Bcast:192.168.1.7  Mask:255.255.255.248
 inet6 addr: fe80::216:17ff:fe77:cd1b/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:4606 errors:0 dropped:0 overruns:0 frame:0
 TX packets:3338 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:384745 (375.7 KiB)  TX bytes:602690 (588.5 KiB)
 Interrupt:250 Base address:0x2000

Para ver info de todas las interfaces:

/sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:17:77:cd:1b
 inet addr:192.168.1.3  Bcast:192.168.1.7  Mask:255.255.255.248
 inet6 addr: fe80::216:17ff:fe77:cd1b/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:4606 errors:0 dropped:0 overruns:0 frame:0
 TX packets:3338 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:384745 (375.7 KiB)  TX bytes:602690 (588.5 KiB)
 Interrupt:250 Base address:0x2000

lo        Link encap:Local Loopback
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:4112 errors:0 dropped:0 overruns:0 frame:0
 TX packets:4112 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:176739 (172.5 KiB)  TX bytes:176739 (172.5 KiB)

Con el comando iproute, podemos visualizar sobre una sola interfaz de la siguiente manera:

ip address list eth0
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
 link/ether 00:16:17:77:cd:1a brd ff:ff:ff:ff:ff:ff

ó

ip address list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
 link/ether 00:16:17:77:cd:1b brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.3/29 brd 192.168.1.7 scope global eth0
 inet6 fe80::216:17ff:fe77:cd1b/64 scope link
 valid_lft forever preferred_lft forever

para ver la info de todas las interfaces.

En los siguientes posts veremos algunos detalles mas avanzados, relacionados con el ruteo en ambos sistemas.

/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */

Flags del Kernel para Firewall o Tuneando el /proc

Opciones de Seguridad en el kernel de Linux (proc)

Hemos visto en otros articulos, que IpTables, es la herramienta en espacio de usuario, que permite establecer filtros con NetFilter, el cual es parte del kernel de Linux. Pero independientemente de las herramientas en espacio de usuario, existe una forma de indicar al kernel, como manejar ciertoas cosas. Esta forma es, a saber, mediente el directorio /proc

/proc

No tengo que detenerme mucho sobre le directorio /proc, ya que basta googlear para encontrar información sobre este pseudo sistema de ficheros. Solo basta decir que mediante el proc podemos acceder a información del kernel, y modificar “on the fly” ciertas configuraciones.
Por ejemplo en /proc/sys/kernel/hostname encontramos el hostname de nuestro linux, y lo cambiamos haciendo

echo otroHostname > /proc/sys/kernel/hostname

De esta misma manera, podremos cambiar “a mano” ciertos valores del funcionamiento del kernel, y consecuentemente, el comportamiento del networking del mismo. Sin embargo, existe una manera mas “prolija”: sysctl (fijate que si no existe el archivo (es decir no existe la funcionalidad), con esa redirección lo crearemos, pero no implica que afectará en manera alguna al funcionamiento del kernel).
Sysctl, nos permite configurar las mismas variables (ver mas abajo) que esten configuradas en el /proc/sys , de forma centralizada en el archivo /etc/sysctl.conf. Siendo su sintaxis muy simple:

clave.a.configurar = valor

Para no ahondar mucho sobre el tema, simplemente hagamos un breve repaso y vayamos a lo importante

Breve repaso:

sysctl -a # muestra todas las variables configurada
sysctl -w kernel.hostname=MyHaxorName # asigna "MyHaxorName" como hostname del sistema
sysctl kernel.hostname # muestra el valor asignado a la variable
echo "kernel.hostname = MyHaxorName" >> /etc/sysctl.conf # cada vez que se inicie el sistema, sysctl configurará
las variables como se encuentran en este archivo 

A continuación, una lista de las variables mas importantes a tener en cuenta para la seguridad de nuestro firewall

Filtro anti-spoof

/proc/sys/net/ipv4/conf/eth0/rp_filter

En /proc/sys/net/ipv4/conf tenemos una carpeta por cada interfaz de red (eth0, lo, wlan0.. etc, además de las carpetas default y all). En cada una de ellas, encontramos archivos que configuran comportamiento especifico de cada interfaz, en el caso de rp_filter, es un filtro anti spoof: solo permite que la respuesta a un paquete sea enviada por la misma interfaz por la cual se recibió el paquete.

Habilitamos con 1, deshabilitamos con 0.

Ignorar pings

/proc/sys/net/ipv4/icmp_echo_ignore_all

Bastante conocido, con un 1 en este archivo, ignoramos todos los paqutes ICMP tipo echo, es decir, los pings.
El no responder pings, permite que pasemos desapercibidos en algunos escaneos simples, pero también nos bloquea la posibilidad de hacer pruebas de pings.

Syn Cookies

/proc/sys/net/ipv4/tcp_syncookies

El ataque syncooky conciste en enviar muchos paquetes TCP con el flag SYN activado,  pero no completa el HandShake, por lo que ocupa memoria en conexiones que quedan a la espera, causando un DoS. Colocando un 1 en este archivo, le pedimos al kernel, que no abra un buffer hasta que la conexión este abierta.

Paquetes Marcianos

/proc/sys/net/ipv4/conf/all/log_martians

Envia señales a syslog cuando entran paquetes de redes ilegales (cuando el kernel no sabe como rutearlas).

Paquetes Icmp Redirect

/proc/sys/net/ipv4/conf/all/accept_redirects

Un paquete ICMP Redirect, informa cuando hemos mandado un paquete a travez de una ruta que no es la optima.

Un ejemplo casero, es cuando tenemos ROUTER1 conectado a internet y a la LAN, en la cual existen 2 pc (PC1 y PC2), la configuración normal seria configurar a PC1 y PC2 con Default Gatewat en ROUTER1. Si cometieramos la tontera configurar PC2 con su default gateway en PC1 (teniendo por Default Gateway a ROUTER1 en esta pc) PC1 nos informaria que hay una ruta mas directa, y es atravez de ROUTER1. Esa funcion de anunciar esa ruta la cumple los paquetes ICMP Redirect. Con este tipo de paquetes, “alguien” podría realizarte un MITM.

ICMP Send_Reditect

/proc/sys/net/ipv4/conf/all/send_redirects

La explicación de esta variable esta explicada en Paquetes ICMP Redirect, pero en este caso, implica no enviar dichos paquetes ICMP.
Si tu linux no actua como ruter, en una red con varios routers, lo mas aconsejable es deshabilitarlo, poniendo un 0.

Ip Connection Tracking

/proc/sys/net/ipv4/ip_conntrack_max ó
/proc/sys/net/ipv4/netfilter/ip_conntrack_max

En este archivo podemos colocar un numero, el cual será la cantidad máxima de conexiones IP que el kernel puede manejar. Este numero suele estar fijado segun la cantidad de memoria ram que poseamos. Esto puede ser un punto clave a la hora de lidiar con DoS. Asi mismo, podemos encontrar unos cuantos archivos similares, pero más especificos, haciendo ls /proc/sys/net/ipv4/netfilter/ip_conntrack*, los nombres de cada uno dan una idea de funcionalidad, y si conoces bien el funcionamiento del protocolo IP podrás retocar estos valores.

Source Route

/proc/sys/net/ipv4/conf/all/accept_source_route

Cuando internet nacio, inocentemente creia que todos serían buenas personas, por lo que sus protocolos, permitian a cualquiera obtener mucha información, en este caso, Ipv4,  permite que solicitemos a un determinado host, una ruta especifica por donde enviar paquetes, pudiendo ser utilizada esta información para conocer las “Relaciones de Confianza” entre routers. Fuera de eso, hoy en dia no se usa. Lo deshabilitamos con un 0

ICMP Broadcasting  (protección smurf)

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

ICMP tiene la facultad de poder enviar paquetes Broadcast, es decir, enviar un paquete, el cual todos los hots reconoceran como enviados hacia si mismos, ya que el destino de dicho paquete es una dirección de broadcast. Al recibir este paquete, el host actua en consecuencia y lo responde. Si todo funcionara como corresponde, no habria problema con esta funcionalidad… pero si “alguien” decide enviar paquetes ICMP Broadcast a una gran lista de IPs con un “source” spoofeado, todos los IPs de la lista enviarian una respuesta a la IP inocente (la spoofeada), causandole probablemente un DoS. Para evitar que nos usen como “reflector” enviandonos paquetes broadcast, ignoramos dichos paquetes colocando un 1 en este archivo.

ICMP Dead Error Messages

/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

El RFC 1122, nos pide que los paquetes ICMP erroneos sean completamente descartados silenciosamente, para no probocar tormentas de broadcast.  Para cumplir con dicho requerimiento, colocamos un 1 en dicho archivo.

IP Forward

/proc/sys/net/ipv4/ip_forward

Conocida por todos, esta variable, habilita o deshabilita el reenvio de paquetes. En los casos donde nuestro linux haga NAT, debe estar habilitada, en caso contrario, es recomendable deshabilitarlo.

TCP FIN TimeOut

/proc/sys/net/ipv4/tcp_fin_timeout

Tiempo en segundos que esperaremos antes de descartar una conexión parcialmente cerrada, por defecto 60 segundos, ya que así lo pide el RFC correspondiente a TCP, pero si queremos podemos disminuirlo a fin de evitar algún DoS.

TCP KeepAlive Time

/proc/sys/net/ipv4/tcp_keepalive_time

Cantidad de segundos que esperará el kernel, antes de enviar un paquete para mantener abierta la conexión, a pesar de que no esta siendo utilizada momentaneamente. Por defecto el valor es 7200 (2 horas),  pudiendo ser reducido en algunos casos a 1 hora o 1/2 hora, en segundos 3600 o 1800.

Proxy Arp

/proc/sys/net/ipv4/conf/all/proxy_arp

Con un 0 podemos deshabilitar esta funcionalidad, que no suele ser necesaria, a menos que seamos servidor de VPN, Firewall o Router que lo requiera.

Cache ARP

/proc/sys/net/ipv4/neigh/[interfaz de red]/gc_stale_time

Los segundos que configuremos en esta variable, definiran el tiempo en que se actualiza el cache ARP. Dicho cache, es el que se envenena cuando se realiza un ARP Poisoning Attack, por lo que cuanto mas bajo sea, mas vulnerable a este ataque, pero al mismo tiempo,  mas rapido sabremos cuando una IP quedo fuera de servicio o una MAC cambio de IP (arp -n para verificar las entradas del cache y su estado)

Escalado de Ventana

/proc/sys/net/ipv4/tcp_window_scaling

Dicha variable, habilita (con un 1) o deshabilita (con un 0) la posibilidad de que la conexión TCP negocie el tamaño de la ventana. Dependiendo del segmento de la red y la topologia de la misma, suele ser conveniente que esté habilitada, sin embargo, nos expone a ciertos escaneos (nmap windows scaling) y a posibles DoS.

Algoritmo SACK

/proc/sys/net/ipv4/tcp_sack

SACK es un algoritmo para detectar perdidas de paquetes. Si habilitamos dicha opción (colocando un 1) siempre y cuando pueda, TCP lo utilizará, en caso contrario, ignorará dicha opción. Es recomendable habilitar dicha opción, ecepto que nuestras conexiones TCP las hagamos en un ambito sin demasiadas perdidas de paquetes.

Rango de Puertos Locales

/proc/sys/net/ipv4/ip_local_port_range

En este archivo no colocaremos ni un 1 ni un 0, si no que colocaremos de números, que definiran un rango de puertos, el cual será utilizado para puertos locales, es decir, puertos desde donde comenzaremos conexiones hacia el exterior. En general el rago es 1024 a 4999, pero es conveniente ejecutar:

#echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range

en sistemas donde se usen los puertos 1024 a 4999 para brindar servicios.

TTL de nuestros paquetes

/proc/sys/net/ipv4/ip_default_ttl

TTL es Time To Live, o bien, el tiempo de vida que le otorgaremos a los paquetes generados por nuestro host. Este “tiempo” no se cuenta en segundos, sino en cantidad de routers que puede atravesar antes de ser descartado (morir). Es asi que cada router, descuenta uno a dicho valor.
Llegar de sudamerica a china nos cuesta de 12 a 20 saltos, por lo que un paquete que tenga mas de 30 saltos es un tanto raro. El valor mas recomendado en general es 64 (traceroute y a sacarnos las dudas)

Explicit Congestion Notification

/proc/sys/net/ipv4/tcp_ecn

Como lo recita su nombre, ECN es una opción de TCP que permitenotificar cuando un host esta congestionado, para que se busque otra ruta. Algunos firewalls o routers pueden llegar a filtrar los paquetes que tengan esta opción habilitada, pero son los menos. Habilitamos con un 1, que sería lo mas recomendable.

Conclusión:

A la hora de armar un Firewall para nuestro linux, no es cuestión de ejecutar cualquier script a fin, si no conocer bien que es lo que necesitamos, para que y como. El conocer estas variables nos permite conocer donde debemos tocar en caso de ser necesario. Para complementar este conocimiento recomiendo leer las fuentes expuestas mas abajo y leer los siguientes artículos: NetFilter / IPTables I, II, III, IV, V

Fuentes:

http://www.securityfocus.com/infocus/1711

http://ipsysctl-tutorial.frozentux.net/chunkyhtml/tcpvariables.html

http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html

/* A partir de marzo nos estamos mudando a http://netsecure.com.ar o http://www.netvulcano.com.ar */

Ruteo en linux vs Cisco I

Por que comparar

Podés estar preguntandoté por que realizar una comparación entre cisco (reyes indiscutibles de las grandes redes) contra el kernel linux, utilizado principal mente para brindar servicios de red, es probable, que opines que es como comparar Papas con frutillas.
He aquí la respuesta: Sin duda, cada uno ocupa un lugar que no puede ser remplazado por el otro, empero, hay una zona gris, donde si bien puede usarse un router cisco, también puede usarse un servidor linux, ahorrando costos y teniendo muchos mas beneficios. Otra de las razones, es que con una serie de artículos que cubran las diferencias y similitudes entre ambos, quienes conozcan de cisco podrán aproximarse al mundo linux de manera mas simple, y viceversa.

Empezemos de una vez!

Cabe mencionar, que existe un proyecto llamado FREESCO, el cual intenta proveer en un solo disquette un sistema operativo (kernel linux) que suplante a los productos de CISCO o 3COM.

Cisco provee una cantidad enorme de productos, dentro de los cuales los firewalls, los routers y los switch son los mas conocidos y abundantes. CISCO suele innovar en los protocolos y funcionalidades de dispositivos de red, y es el referente mas grande del mundo en cuanto a Networking.

Linux por su parte es un kernel, con varios años de desarrollo, al igual que los kernels BSD tiene carácteristicas importantes cuando hablamos de ruteo o firewalls, por sobre eso, las distribuciones GNU/Linux, son tan abundantes que pueden instalarse en varios tipos de arquitecturas de servidores (incluso mainframes) y PCs de escritorios.

Para empezar, debemos hablar sobre la diferencia de Hardware, la cual es muy importante en esta comparación.

Hardware

Linux, ha demostrado ser un de los kernels mas portables, exceptuando NetBSD (que sin duda es el kernel mas portado) Linux ha podido instalarse en Mainframes (la famosa BlueGene) y hasta en pockets pc o telefonos celulares. Esto nos da la ventaja de poder instalar linux en casi cualquier hard disponible.

Si bien esto nos da mayor flexibilidad, cuando lo comparamos con CISCO, debemos entender que todo el hard de cisco, esta especialmente integrado, ayudando a que el software haga uso de las capacidades a nivel firmware.
Otra punto importante a evaluar, es la fidelidad.
Es probable, que un hard CISCO, tenga una mayor fidelidad que una pc cualquiera. Para poder usar una PC, deberiamos eliminar los discos con partes mobiles (suplantandolós por disco de estado solido) , lo cual son la parte mas sensibles de las PC junto con la alimentación electríca y la temperatura.
Es decir, que el hecho de que Linux se pueda instalar en cualquier hard, no significa necesariamente, que nos saldrá mas barato, pero sin duda, si que nos da mayor flexibilidad desde cualquier punto de vista.
Sin embargo, Linux tomará ventaja, cuando pensemos que a la pc podemos remplazar cualquiera de sus partes para mejorarla, o reemplazar alguna parte dañada.

Tanto en el hard cisco como en el que puede instalarse un Linux, son unidades de procesamiento, y las capacidades dependerán fundamentalmente del costo que estemos dispuestos a gastar. Para poder hacer una correcta comparación, se debe evaluar el ámbito de aplicación, ya que en ciertos casos es mas fácil usar un router cisco, y en otros, será mas facil instalar una pc con un linux instalado especialmente para routear.

Características

Consideraremos al ruteo, o las funcionalidades de un firewall como un servicio que puede ser brindado por un nodo de la red, para poder comparar de manera cuantificable las características de CISCO contra Linux.

Depende del costo que gastemos en un router cisco, podremos obtener mas servicios y características. Fundamentalmente CISCO provee en sus dispositivos servicios de ruteo avanzado, con protocolos como RIP(v2,ng), BGP, EIGRP, GRP, OSPF, y  demás, los cuales permiten realizar sistemas complejos de ruteo, de una manera bastante simple. Todo esto se puede combinar con STP, para lograr una rápida y segura convergencia de la red.

Sin embargo, aunque con un poquito mas de esfuerzo (verdaderamente muy poco) podemos tener exactamente los mismos servicios, en un server con alguna distro GNU/Linux, pero a esos servicios podemos agregarle los servicios “clásicos” brindados por un servidor Unix, llamese, NFS, CIFS, DNS, FTP, SSH, HTTP, IRC, y bue.. no se, 65000 mas. Lo que en verda quiero decir, es que en un linux podemos implementar ciertos servicios adicionales que sirvan a la red de usuarios, y aún si fueramos puristas y quisieramos tener un dispositivo que solo rutee, las posibilidades de selección de ruta son mucho mejor, como ya intentaremos mostrar.
Por sobre esto, hay muchas herramientas, para obtener estadisticas, o para detectar errores de red o de aplicaciones (por ejemplo sniffers, scanners etc).

A pesar de todo eso, esto no hace que Linux sea la opción ideal, ya que todas estas características pierden importancia cuando pensamos, que si bien podemos llegar a necesitar algunas de ellas,  probablemente no lo necesitaremos en todos los nodos, por lo que la simpleza de los dispositivos embebidos puede disputarle la punta según la necesidad.

Un punto mas a considerar, es el esfuerzo a la hora instalar un fix o una version nueva del software.
En el caso de CISCO significa un indisponabilidad segura, ya que para updatear necesitamos reiniciar, en Linux, solo necesitamos reiniciar completamente, es caso de que se trate de un update en el kernel, pero si se trata de alguno de los servicios, es sabido que solo necesitaremos reiniciar el servicio.

Sin duda, en muchos casos Linux, llevará la punta en cuanto a cantidad de aplicaciones que podemos implementar sobre el, en comparación con la poca flexibilidad que nos ofrece CISCO, a la inversa, la simplicidad y minimalidad de CISCO es una ventaja que puede volcar la balanza a su favor.

Conocimientos

Al comparar ambas posibilidades, debemos tener en cuenta los conocimientos necesarios para poder operar cualquiera de los dos.
Sin embargo, no voy explayarme sobre esto, ya que en los sucesivos artículos trataremos de comprar ambas posibilidades, y conocer las dos formas de hacerlo, ya que considero, que los administradores eligen una u otra cosa, dependiendo del conocimiento que tienen de una u otra tecnología, dejando en segundo plano los otros puntos a considerar.

Espero que se vayan dejando bien sentadas las diferencias (ventajas y desventajas) y cualquier acotación será mas que bienvenida, seguimos en el próximo artículo!.

Publicado en Articulos. Etiquetas: , , , , , . 1 Comment »