Nmap ( “Network mapper”) es un servicio gratuito y de código abierto. Es de gran utilidad para la exploración de red o de auditoría de seguridad.

A muchos administradores de sistemas y de redes también les resulta útil para tareas varias: Inventario de los equipos de red, gestión de horarios de servicio de actualización, seguimiento y tiempo de actividad o servicio de acogida.

Nmap usa los paquetes IP en bruto en nuevos métodos para determinar qué hosts están disponibles en la red, qué servicios (solicitud de nombre y versión) son los anfitriones que ofrecen, qué sistemas operativos (y versiones del sistema operativo) que se están ejecutando, qué tipo de filtros de paquetes / cortafuegos están en uso, y docenas de otras características.

Fue diseñado para escanear rápidamente grandes redes, pero funciona muy bien en las computadoras sencillas. Nmap se ejecuta en todos los principales sistemas operativos.

Además de la clásica línea de comandos de Nmap ejecutable, Nmap la suite incluye una avanzada interfaz gráfica y los resultados visor (Zenmap), una forma flexible de transferencia de datos, reorientación, y la herramienta de depuración (NCAT), y una utilidad para comparar los resultados de exploración (Ndiff)

El instalador para windows lo tengo aqui

Una de las características más intrigantes de OpenSSH es su capacidad para autenticar usuarios usando los protocolos RSA y DSA de autenticación, basados en un par de claves numéricas complementarias.

Uno de sus principales atractivos, las autenticaciones RSA y DSA prometen la habilidad de establecer conexiones con sistemas remotos sin proporcionar una contraseña. A pesar de que esto es interesante, los nuevos usuarios de OpenSSH muchas veces configuran RSA/DSA de forma rápida y sucia, dando como resultado una entrada en el sistema sin necesidad de contraseña, pero dejando abierto un gran agujero de seguridad en el proceso.

Los protocolos de autenticación RSA y DSA de OpenSSH están basados en un par de claves criptográficas especialmente creadas, denominadas clave privada y clave pública. La ventaja de usar este sistema de autenticación basado en claves es que, en muchos casos, es posible establecer una conexión segura sin tener que escribir una contraseña a mano.

Hay dos observaciones importantes sobre la autenticación RSA y DSA.

La primera es que realmente sólo necesitamos generar un par de claves. Podemos entonces copiar nuestra clave pública a las máquinas remotas en las que nos gustaría acceder y todas ellas nos autenticarán felizmente contra nuestra única clave privada. En otras palabras, no necesitamos un par de claves para cada sistema al que nos gustaría tener acceso. Sólo un par es suficiente.

La otra observación es que nuestra clave privada no debería caer en malas manos. La clave privada es lo único que nos concede acceso a nuestros sistemas remotos, y cualquiera que posea nuestra clave privada es admitido exactamente con los mismos provilegios que tenemos. Así como no querríamos que personas extrañas tuvieran las llaves de nuestra casa, debemos proteger nuestra clave privada de un uso no autorizado. En el mundo de los bits y los bytes, esto significa que nadie debería poder leer o copiar nuestra clave privada.

Desde luego, los desarrolladores de ssh son concientes de la importancia de la claves privadas, y han construído unas pocas salvaguardas en ssh y en ssh-keygen para que nuestra clave privada no sea maltratada. Primero, ssh está configurado para imprimir un gran mensaje de advertencia si nuestra clave tiene permisos de fichero que permitiría ser leída por cualquiera además de nosotros. Segundo, cuando creamos nuestro par de claves pública/privada usando ssh-keygen, ssh-keygen nos pedirá que introduzcamos una frase de paso. Si lo hacemos, nuestra clave privada estará encriptada usando esta frase de paso, así que si incluso fuera robada, será inútil para cualquiera que por casualidad no supiera la frase de paso. Armados con este conocimiento, vamos a echar un vistazo a cómo configurar ssh para usar los protocolos de autenticación RSA y DSA.

En el archivo de configuración /etc/ssh/sshd_config tenemos que asegurarnos tener las siguientes directivas activas

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile    %h/.ssh/authorized_keys
PasswordAuthentication no

Como se ya se dijo, las llaves se generan con ssh-keygen, se debe generar el par de llaves para cada cuenta de usuario. Las llaves se guardan por defecto en el directorio particular de cada usuario en la carpeta .ssh

Es importante mecionar que la llave pública debe concatenarse con el archivo authorized_keys

Un tutorial bastante completo está en http://idefix.eup.uva.es/Manuales/ssh/TutorialOpenSSH.pdf

Otra referencia es http://www.gentoo.org/doc/es/articles/openssh-key-management-p1.xml

SSH (Secure SHell), es tal vez la herramienta de conexión segura mas usada en el mundo Linux. Simplemente, no hay nada como ssh para conectarse entre servidores Linux.

Seguramente es por eso también que es normal que el servidor SSH sea atacado. Básicamente, los ataques a ssh están basados en técnicas desarrolladas para servidores mal configurados o que no esten actualizados. El atacante, trata de encontrar alguna vulnerabilidad descubierta, tal vez un puerto abierto o de ataques de login mediante fuerza bruta. (Con brutus o con otro mas fuerte)

Una mala configuración sería permitir que el usuario root tenga permiso de acceso al servidor ssh, un atacante puede lanzar un ataque de fuerza bruta con el objeto de adivinar la contraseña. El no tener un número máximo de intentos de conexión le permitiría al atacante lanzar cientos de sesiones simultaneas de solicitud de ingreso.

Otra mala configuración sería el no limitar el número de intentos fallidos por conexión y se pueden enumerar muchas otras. Si a todo esto agregamos una contraseña debil de root (por ejemplo menos de 8 caracteres y solo minúsculas) será cuestión de unos cuantos minutos o un par de horas para lograr el objetivo.

ssh mas seguro

Normalmente el archivo de configuración principal de ssh es:

/etc/ssh/sshd_config   (puede variar en algunas distros)

Las principales directivas de configuración son:

Port 432                           (o el que se quiera menor a 1024)
Protocol 2
LoginGraceTime 30
PermitRootLogin no
MaxAuthTries 2
MaxStartups 3
AllowUsers sergio                     o también:
AllowUsers sergio analuisa@10.0.1.100

Port: El puerto 22 es el puerto predeterminado para atender las solicitudes de conexión, es por eso que un atacante intentará acceder usando este puerto, el cambiar el puerto no garantiza que el servicio ya no será localizable.

Protocol 2: Hay dos versiones de ssh en cuanto a su protocolo de comunicación, la versión 1 y la versión 2. La 1 esta en desuso pero todavía se incluye por compatibilidad, tiene varias vulnerabilidades conocidas y su uso no es ya recomendable. Un error frecuente es dejar al demoinio ssh que permita el uso de las dos versiones (Protocol 2,1). Para evitar el uso del protocolo 1 y sus posibles ataques a este, basta con indicar en esta línea que solo admita comunicaciones de ssh basadas en el protocolo 2.

LoginGraceTime 30: El número indica la cantidad de segundos en que la pantalla de login estará disponible para que el usuario capture su nombre de usuario y contraseña, si no lo hace el login se cerrará, evitando así dejar por tiempo indeterminado pantallas de login sin que nadie las use.

PermitRootLogin no: Esta es quizás la más importante directiva de seguridad que podemos indicar para fortalecer nuestro servidor ssh. Prácticamente todos los sistemas Linux y Unix crean por default al usuario root, entonces sabemos que existe!!!. Muchos ataques de fuerza bruta se concentran en atacar al usuario root con la esperanza de que tenga una contraseña débil (¡que es mas común de lo que pensamos!).

MaxAuthTries 2: El número indica la cantidad de veces que podemos equivocarnos en ingresar el usuario y/o contraseña, en este caso después de dos intentos, se perderá o cerrará la conexión.

MaxStartups 3: El número indica la cantidad de pantallas de login, o cantidad de conexiones simultaneas de login que permitirá el sshd por ip que intente conectarse.

AllowUsers: En sistemas donde se tiene varios usuarios, quizás existan varios que solo pueden acceder desde la LAN por ejemplo, o quizás solo desde ciertos equipos. Si solo indicamos al usuario:

AllowUsers sergio

El usuario sergio podrá ingresar desde cualquier PC en cualquier lugar, no se está validando el host.
Si se quiere mas seguridad, es posible indicar también el host mediante el símbolo @

AllowUsers sergio@192.168.0.25     (solo desde la IP indicada)
AllowUsers sergio@192.168.0.*       (Toda la red indicada)
AllowUsers sergio@*.pato.com  analuisa@ventas.pato.com
  (sergio desde cualquier equipo del dominio indicado, analuisa solo desde el equipo indicado)

Como puede verse, bastan algunas cuantas directivas o variables bien configuradas en nuestro archivo /etc/ssh/sshd_config para incrementar enormemente la seguridad en este servicio.

Proxima entrega

Sistemas de llaves publicas y privadas con SSH

Son muchas las personas que me preguntan si al usar Linux se libran de los virus o si existe un antivirus en Linux, la verdad es que en Linux existen muy pocos virus y si estamos utilizando adecuadamente los niveles de seguridad es prácticamente imposible verse afectado, no obstante a veces utilizamos Linux como servidor y lo conectamos un una red con otros sistemas operativos que si son muy sensibles a los virus, de ahí la principal necesidad de instalar un antivirus en Linux, estaremos hablando sobre CLAMAV en detalle, en este caso estaré utilizando Fedora Core 8.

Los paquetes que se deben instalar son:

clamav
clamav-filesystem
clamav-data
clamav-lib
clamav-update

Esto se logra fácilmente:

En fedora, centos y famila:
yum –y clamav clamav-filesystem clamav-data clamav-lib clamav-update

En openSUSE y Familia:
yast –i clamav clamav-filesystem clamav-data clamav-lib clamav-update

En debian, ubuntu y familia:
apt-get install clamav clamav-filesystem clamav-data clamav-lib clamav-update

Generalmente estos paquetes no tienen dependencias adicionales

Luego procedemos a editar el archivo de configuración /etc/freshclam.conf con el editor de textos que más nos agrade, a mi me gusta el vim.

vim /etc/freshclam.conf

y localizamos la línea que dice:

#DatabaseMirror db.XY.clamav.net

Hay que eliminar el signo # para quitar el comentario y sustituir XY por el prefijo del país, si no estamos seguros del prefijo la lista completa está disponible en: http://www.iana.org/root-whois/index.html

Como yo estoy en Nicaragua queda asi:

DatabaseMirror db.ni.clamav.net

En este momento ya se puede iniciar clamav para hacerlo en la terminal se corre el siguiente comando:

freshclam

esto actualizará la base de datos de virus

Si deseas escanear tu directorio particular o el directorio actual de trabajo solo escribe

Clamscan

Si quieres hacer un escaneo completo del sistema entonces

clamscan / -r –quiet

clamscan es el programa

/ significa que iniciará desde la raíz del árbol

-r significa recursivamente, es decir dentro de los directorios y sub-directorios

–quiet significa que solamente informará en caso de ocurrir un error o de encontrar un virus

Si quieres hacer algo mas complicado te recomiendo leer el manual

man clamscan

Necesitamos que cada día se actualice la base de datos de virus

Nos vamos a /etc/cron.daily en esta ubicación se encuentras scripts que el cron ejecutará todos los días

cd /etc/cron.daily

Creamos el archivo que se convertirá en el script

toouch freshclam

y le agregamos lo que queremos que haga

echo freshclam > freshclam

Lo convertimos en ejecutable

chmod 755 freshclam

y listo todos los días se actulizará la base de datos automáticamente

1. Qué es un firewall

Un firewall es un dispositivo, ya sea a nivel hardware o a nivel de software, que filtra el tráfico entre dos o más redes. 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, utilizando protocolos como NAT.

Una traducción no muy afortunada para el término fireall es Cortafuegos

Figura 1: Firewall típico entre red local e internet

Ventajas del uso de los Firewalls:

• Protege de Intrusos: Esto hace referencia que los accesos a ciertos fragmentos de la red interna solo es permitida a algunas terminales autorizadas.
• Protección de información privada: Permite definir distintos niveles de accesos a la información de manera que en la organización los grupos de accesos definidos solo contaran con servicios e información limitados.
• Optimización de Accesos: En primero lugar identifica todos los nodos o terminales de la red interna y luego optimiza la comunicación entre ellos.

2. Qué es iptables

IPtables es un firewall vinculado al kernel de GNU/linux que se ha extendido enormemente a partir del kernel 2.4 . Es el sucesor de ipchains. Iptables no es como un servidor que lo iniciamos o detenemos, iptables esta integrado al kernel, es parte del sistema operativo.

3. ¿Cómo se pone en marcha?

Realmente lo que se hace es aplicar reglas. Para ellos se ejecuta el comando iptables, con el que añadimos, borramos, o creamos reglas. Por ello un firewall de iptables no es sino un simple script de shell en el que se van ejecutando las reglas de firewall. En todo caso los Nerdsitos y lo Geeks se pueden crear un shell script que “detenga” el firewall permitiendo o negando el tráfico y otro que “inicie” el firewall aplicando las reglas.

Figura 2: cuando un paquete, una trama u otra comunicación llega al kernel con iptables se sigue este camino

Un firewall con iptables – para proteger un servidor sencillo

Mi buen amigo Pello Xabier Altadill Izura, en su sitio web tiene varios ejemplos muy interesantes, yo tomé un par de ellos y los modifiqué un poco, aquí el primero, pensado para una computadora con un servidor Web, un servidor FTP y un servidor MySQL:

#!/bin/bash
## SCRIPT de IPTABLES - ejemplo
## Ing. Carlos A. Leal S.
## cleal@ns.uca.edu.ni
## basado en www.pello.info

clear

echo “Aplicando Reglas de Firewall…”

echo “Haciendo FLUSH de reglas”
iptables -F
iptables -X
iptables -Z
iptables -t nat -F

echo “Establecemos politica 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

echo “Empezamos a filtrar”

echo “El localhost se deja por ejemplo conexiones locales a mysql”
iptables -A INPUT -i lo -j ACCEPT

echo “A nuestra IP le dejamos todo”
iptables -A INPUT -i eth0 -s 165.98.12.189 -j ACCEPT
iptables -A INPUT -i eth0 -s 172.16.8.189 -j ACCEPT

echo “Permitimos mysql desde la red local”
iptables -A INPUT -s 172.16.8.0/24 -p tcp –dport 3306 -j ACCEPT

echo “Al diseñador le dejamos usar el FTP”
iptables -A INPUT -s 172.16.8.194 -p tcp –dport 20:21 -j ACCEPT

echo “El puerto 80 de www debe estar abierto, es un servidor web.”
iptables -A INPUT -p tcp –dport 80 -j ACCEPT

echo “Y el resto, lo cerramos”
iptables -A INPUT -p tcp –dport 20:21 -j DROP
iptables -A INPUT -p tcp –dport 3306 -j DROP
iptables -A INPUT -p tcp –dport 22 -j DROP
iptables -A INPUT -p tcp –dport 10000 -j DROP
iptables -A INPUT -p tcp –dport 3306 -j DROP

echo “OK . Verificando que lo que se aplica con: iptables -L -n”
iptables -L -n

echo “Fin del script”

El segundo ejemplo es una versión mejorada

#!/bin/sh
## SCRIPT de IPTABLES - ejemplo del manual de iptables
## Ejemplo de script para proteger la propia máquina mejorado
## Ing. Carlos A. Leal S. - cleal@ns.uca.edu.ni
## basado en www.pello.info

clear
echo “Aplicando Reglas de Firewall…”

echo “FLUSH de reglas”
iptables -F
iptables -X
iptables -Z
iptables -t nat -F

echo “Establecemos politica 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

echo “Empezamos a filtrar”

echo “A localhost se deja por ejemplo conexiones locales a mysql”
iptables -A INPUT -i lo -s 127.0.0.1/8 -j ACCEPT

echo “A nuestra IP le dejamos todo”
iptables -A INPUT -i eth0 -s 165.98.12.189 -j ACCEPT
iptables -A INPUT -i eth0 -s 172.16.8.189 -j ACCEPT

echo “Negamos MySQL”
iptables -A INPUT -p tcp –dport 3306 -j DROP

echo “Permitimos FTP”
iptables -A INPUT -p tcp –dport 20:21 -j ACCEPT

echo “El puerto 80 de www debe estar abierto, es un servidor web.”
iptables -A INPUT -p tcp –dport 80 -j ACCEPT

echo “Cerramos rango de los puertos privilegiados. Cuidado con este tipo de barreras, antes hay que abrir a los que si tienen acceso.”
iptables -A INPUT -p tcp –dport 1:1024 -j DROP
iptables -A INPUT -p udp –dport 1:1024 -j DROP

echo “Cerramos otros puertos que estan abiertos”
iptables -A INPUT -p tcp –dport 10000 -j DROP
iptables -A INPUT -p udp –dport 10000 -j DROP

echo ” OK . Verifique que lo que se aplica con: iptables -L -n”
iptables -L -n

echo “Fin del scrip”