/home/blaster [ Blaster's blog ]

Archive for Enero, 2008

Nmap es una herramienta desarrollada por Fyodor de www.insecure.org, es una herramienta básica que permite realizar una labor sencilla de revisión (escaneo) de puertos y reporte del tipo de sistema operativo que usa la máquina.

El paquete nmap lo usaremos para escanear máquinas nuestras desde un servidor Linux nuestro. Estas máquinas que escanearemos tienen cualquier tipo de sistema operativo, es un escaneo de puertos tcp (o udp) que es un estándar de internet y no depende del sistema operativo. Es decir, la máquina a ser escaneada puede estar en windows, linux, puede ser un switch o un ruteador o cualquier elemento de nuestra red con dirección IP.

como lo instalamos ?

El proceso de instalación en CentOS

Linux es bastante simple:

yum -y install nmap

Esto nos instalará en nuestra máquina la versión más moderna que provea CentOS.

Este proceso también debe funcionar para:

* Fedora

* Red Hat Enterprise Linux (3 y 4)

* White Box Enterprise Linux (3 y 4)

en ubuntu

sudo apt-get install nmap

Domain Name System (DNS)

La funcionalidad del servicio de DNS es convertir nombres de máquinas (legibles y fáciles de recordar por los usuarios) en direcciones IP o viceversa.

Ejemplo:

A la consulta de cuál es el IP de pirulo.remix.com, el servidor responderá 192.168.0.1 (esta acción es conocida como mapping); del mismo modo, cuando se le proporcione la dirección IP, responderá con el nombre de la máquina (conocido como reverse mapping).

El Domain Name System (DNS) es una arquitectura arborescente para evitar duplicación de la información y facilitar la búsqueda. Por ello, un único DNS no tiene sentido sino como parte del árbol.

La aplicación que presta este servicio se llama named, se incluye en la mayoría de distribuciones de GNU/Linux (/usr/sbin/named) y forma parte de un paquete llamado bind coordinado por ISC (Internet Software Consortium). DNS es simplemente una base de datos, por lo cual es necesario que las personas que la modifiquen conozcan su estructura, ya que, de lo contrario el servicio quedará afectado. Como precaución, debe tenerse especial cuidado en guardar las copias de los archivos para evitar cualquier interrupción en el servicio.

Un proxy-caché recibe peticiones de objetos por parte de los clientes (en este caso navegadores web) y las reenvía al servidor. Cuando recibe los objetos solicitados del servidor, los envía al cliente y almacena una copia de los mismos en un caché de disco.

La ventaja del caching consiste en que cuando varios clientes solicitan el mismo objeto, este puede proporcionárseles desde el caché de disco. De este modo, los clientes obtiene los datos mucho más rápidamente que si lo hicieran desde Internet y se reduce al mismo tiempo el volumen de transferencias en red.

Al script que creemos con las reglas para el IPTABLES hay que darle flags de ejecución:

chmod +x firewall1.sh o chmod 750 firewall1.sh

La estructura de un comando iptables es la siguiente :

iptables -t [tabla] -[AIRDLFZNXP] [regla] [criterio] -j [acción]

Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico o un software sobre un sistema operativo. En general debemos verlo como una caja con DOS o mas interfaces de red en la que se establecen una reglas de filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso puede ir más allá y realizar modificaciones sobre las comunicaciones, como el NAT. Esa sería la definición genérica, hoy en dia un firewall es un hardware especifico con un sistema operativo o una IOS que filtra el tráfico TCP/UDP/ICMP/../IP y decide si un paquete pasa, se modifica, se convierte o se descarta. Para que un firewall entre redes funcione como tal debe tener al menos dos tarjetas de red. Esta sería la tipología clásica de un firewall:

Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a internet (como es el caso de un servidor web, un servidor de correo, etc..), y en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos. Lo que se recomienda en esa situación es situar ese servidor en lugar aparte de la red, el que denominamos DMZ o zona desmilitarizada. El firewall tiene entonces tres entradas:

En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el servidor sea accesible desde internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el firewall.

Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de internet en las empresas, aunque ahí también suelen tener una doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior; esto último se hace con el firewall o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel).

Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino de los paquetes del protocolo tcp/ip. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no solo los tcp, también los udp, los icmp, los gre y otros protocolos vinculados a vpns.

Este podría ser (en pseudo-lenguaje) el conjunto de reglas de un firewall simple (en una entrada el router y en la otra el HUB o Switch):

Politica por defecto ACEPTAR.

Todo lo que venga de la red local al firewall ACEPTAR

Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR

Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR

Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR

Todo lo que venga de la red local y vaya al exterior ENMASCARAR

Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR

Todo lo que venga del exterior al puerto tcp 3389 DENEGAR

Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR

En definitiva lo que se hace es:

• Habilita el acceso a puertos de administración a determinadas IPs privilegiadas
• Enmascara el trafico de la red local hacia el exterior (NAT, una petición de un pc de la LAN sale al exterior con la ip pública), para poder salir a internet
• Deniega el acceso desde el exterior a puertos de administración y a todo lo que este entre 1 y 1024.

Hay dos maneras de implementar un firewall:

1. Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y solo se denegará lo que se diga explícitamente.
2. Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el firewall aquellos que se permita explícitamente.

Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que preocupar de proteger aquellos puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar. Por ejemplo, si queremos proteger una máquina linux, podemos hacer un netstat –ln (o netstat –an, o netstat –puta | grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos y ya está. ¿Para qué vamos a proteger un puerto que realmente nunca se va a abrir? El único problema que podemos tener es que no controlemos que es lo que esta abierto, o que en un momento dado se instale un software nuevo que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política por defecto es ACEPTAR y no se protege explícitamente, nos la estamos jugando un poco. En cambio, si la política por defecto es DENEGAR, a no ser que lo permitamos explícitamente, el firewall se convierte en un auténtico MURO infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a meter reglas super-permisivas. Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema.

Una cosa a tener muy en cuenta es el orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace con un paquete se va comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se hace lo que dicte esta regla (aceptar o denegar); después de eso NO SE MIRARÁN MÁS REGLAS para ese paquete. ¿Cuál es el peligro? Si ponemos reglas muy permisivas entre las primeras del firewall, se aplicará una amplia gama de paquetes y las reglas para situaciones concretas que irían después no se aplicarían y servirían de poco.