lunes, 20 de junio de 2016

configuracion de servidor keberos y VPN´s con IPsec

Kerberos es un protocolo de autenticación de redes de ordenador creado por el MIT que permite a dos ordenadores en una red insegura demostrar su identidad mutuamente de manera segura. Sus diseñadores se concentraron primeramente en un modelo de cliente-servidor, y brinda autenticación mutua: tanto cliente como servidor verifican la identidad uno del otro. Los mensajes de autenticación están protegidos para evitar eavesdropping y ataques de Replay.
Kerberos se basa en criptografía de clave simétrica y requiere un tercero de confianza. Además, existen extensiones del protocolo para poder utilizar criptografía de clave asimétrica.

Una Virtual Private Network (VPN) se podría decir que es una extensión de una red local, de esta manera podemos conectar a una red a miles de kilómetros como si estuviéramos físicamente en ella. Hay que tener en cuenta, que la información que estamos tratando va encriptada y solamente es funcional para los que estén dentro de esta. El costo es mínimo, y hoy en día es una de las maneras más factibles a la hora de conectar.



identificación de usuarios mediante PAM

PAM (Pluggable Authentication Module) no es un modelo de autenticación en sí, sino que se trata de un mecanismo que proporciona una interfaz entre las aplicaciones de usuario y diferentes métodos de autenticación, tratando de esta forma de solucionar uno de los problemas clásicos de la autenticación de usuarios: el hecho de que una vez que se ha definido e implantado cierto mecanismo en un entorno, es difícil cambiarlo. Mediante PAM podemos comunicar a nuestra aplicaciones con los métodos de autenticación que deseemos de una forma transparente, lo que permite integrar las utilidades de un sistema Unix clásico (login, ftp, telnet...) con esquemas diferentes del habitual password: claves de un solo uso, biométricos, tarjetas inteligentes...
La gran mayoría de las aplicaciones de linux usan estos métodos (PAM) para autenticarse frente al sistema, ya que una aplicación preparada para PAM (PAM-aware) puede cambiar el mecanismo de autenticación que usa sin necesidade de recompilar los fuentes. Incluso se puede llegar a cambiar el sistema de autenticación local sin siquiera tocar las aplicaciones existentes.
PAM viene "de serie" en diferentes sistemas Unix, tanto libres como comerciales, y el nivel de abstracción que proporciona permite cosas tan interesantes como kerberizar nuestra autenticación (al menos la parte servidora) sin más que cambiar la configuración de PAM, que se encuentra bien en el fichero /etc/pam.conf o bien en diferentes archivos dentro del directorio /etc/pam.d/
PAM trabaja con cuatro tipos separados de tareas de administración: authentication, account, session, y password. La asociación del esquema de administración preferido con el comportamiento de la aplicación se hace mediante archivos de configuración. Las funciones de administración las hacen módulos que se especifican en el archivo de configuración. Más adelante se explicara brevemente la sintaxis del archivo de configuración ya que se va fuera del alcance de este artículo.
Cuando una aplicación preparada para PAM inicia, se activa su comunicación con la API de PAM. Entre otras cosas esto fuerza la lectura del archivo de configuración: /etc/pam.conf. Alternativamente puede ser que se inicie la lectura de los archivos de configuración bajo /etc/pam.d/ (cuando existe un archivo de configuración correcto bajo este directorio, se ignora el archivo /etc/pam.conf)
sintaxis del archivo de configuración:
El archivo (/etc/pam.conf) está formado por una lista de reglas (típicamente una por línea). Cada regla es un conjunto de campos separados por espacios (los tres primeros son case-sensitives):
service type control module-path module-arguments
La sintaxis de los archivos bajo /etc/pam.d/ es igual salvo que no existe el campo "service". En este caso "service" es el nombre del archivo en el directorio /etc/pam.d/ (el nombre del archivo debe estar en minúsculas) Usualmente service es el nombre del servicio o aplicación comúnmente usado, ejemplo de esto son login, su y ssh.type especifica a que grupo de administración está asociada la regla. Las entradas válidas son:

  • account: este módulo maneja la cuenta sin basarse en autenticación. Típicamente se usa para restringir/permitir el acceso a un servicio basado en la hora o quizás desde donde se loguea el usuario (ej.: root solo se puede loguear desde consola
  • auth: provee mecanismo de autenticación (el usuario es quien dice ser).
  • password: este módulo es requerido para modificar la password del usuario.
  • session: este módulo está asociado con hacer tareas previas y/o posteriores al inicio del servicio mismo (pueden ser cosas como montar un directorio, activar logueos, etc).

      El tercer campo control especifica que hacer si falla el control aplicado. Existen dos sintaxis para este campo, una sencilla de un campo y otra que especifica más de un campo dentro de corchetes rectos [] Para la básica, las opciones son:
        -required: indica que esta regla debe ser exitosa, de lo contrario el usuario no es autorizado a correr el servicio. Si falla se devuelve el control al programa, pero antes se ejecutan todos los módulos.
        -requisite: es como el required, pero devuelve el control al programa enseguida de fallar.
        -sufficient: Si este módulo se verifica, entonces (se devuelve) se le da el ok al programa y no se sigue verificando los otros módulos.
        -optional: la falla o no de este módulo es solo importante si es el único existente.
      El cuarto campo module-path especifica el path al módulo PAM asociado con la regla. Los módulos se encuentran en /lib/security.
      El quinto campo module-arguments es un conjunto de cero o más argumentos pasados al módulo durante su invocación. Los argumentos varían según el módulo.
      La configuración de los archivos de configuración bajo /etc/pam.d/ resulta ser más flexible (se evita tener una archivo único enorme). Bajo este directorio se puede encontrar el archivo de confiuración personal de un servicio particular como ser ssh. La única diferencia entre la sintaxis del archivo /etc/pam.conf es que no existe el campo service.

      restricción de acceso a servicios (TCP wrappers)

      TCP Wrapper es un sistema que nos permite permitir, denegar o filtrar el acceso a los servicios de un servidor con sistema operativo UNIX (como por ejemplo Linux o BSD).
      Los ficheros principales implicados en TCP Wrappers son “/etc/host.allow” y “/etc/host.deny”. En el fichero /etc/host.allow se indican las políticas permisivas y en el fichero /etc/host.deny las políticas restrictivas.
      Las políticas o reglas para filtrar el acceso al servidor desde la red se definen de la siguiente forma:
      Demonios o lista de demonios del sistema : Lista de equipos : Acción a realizar
      A continuación detallamos cada campo:
      – Demonios: Son servicios que existen en sistemas operativos Unix como por ejemplo sshd (servicio SSH),  slapd (servicio LDAP) o proftpd (servicio FTP). Para crear una regla común para varios demonios debemos indicar su nombre separados por comas. Existe también el comodín “ALL” que hace que dicha política afecte a todos los demonios del sistema.
      – Lista de equipos: En este campo indicamos a que equipos aplicamos esta política. Podemos indicar una dirección IP, un rango de direcciones IP, o un nombre de dominio. También podremos usar el comodín “ALL” para que esta política afecte a todos los equipos que intenten acceder. También existe el operador “EXCEPT” que nos permite eliminar de la regla uno o varios equipos.
       – Acción a realizar: Aquí debemos indicar si la política permite el acceso o deniega el acceso a los demonios indicados anteriormente. Las palabras que se usa denegar el acceso es “deny”. En caso de dejar este campo vacío, significa que permitimos el acceso a los demonios y equipos indicados. Opcionalmente, podemos enviar comandos con la directiva “spawn”. Esta directiva suele ser utilizada para la creación de registros de conexión al propio equipo. Existe también la directiva “twist” quesustituye el servicio o demonio solicitado por el comando que le hemos especificado. Esto significa que por defecto se deniega el acceso. Esto es muy útil para la creación de honeypost.

      Ejemplo de uso de TCP Wrapper

       Como primer ejemplo vamos a denegar el acceso a un servidor SSH instalado en el equipo solo a una determinada IP. Al ser una política permisiva (permite el acceso a todos los equipos excepto a la IP que se le indica) la vamos a definir utilizando el fichero /etc/host.allow .
      Escribiremos lo siguiente para aplicar esta política:
      Denegamos acceso por SSH a una IP
      sshd —> Deminio del servicio SSH
      192.168.5.135—> Ip a la que vamos a aplicar la política
      deny —> Denegamos el acceso

      Comprobamos que desde el equipo con la IP 192.168.5.135 no se puede acceder al servicio SSH:
      Comprobación de acceso al Servicio SSH
      A continuación vamos a denegar el acceso al servicio SSH a todos los equipos. Además, gracias a la directiva “spawn” vamos a guardar un registro del intento de conexión a nuestro servidor. Con %d imprimimos el demonio que denegamos y %h el equipo que se intenta conectar.
      Fichero hosts.deny
      Una vez que un equipo se intenta conectar a la máquina en la que tenemos la política anterior configurada, se crea una linea en el fichero que hemos indicado con el demonio al que hemos denegado el acceso y la IP desde donde se intentaba conectar.
      Registro de Acceso

      viernes, 17 de junio de 2016

      Configuracion de un firewall ipchains iptables

       Los cortafuegos, unos mecanismos bastante extendidos para proteger un equipo o una red de estos. También conocidos como "firewalls", los podemos encontrar como dispositivos externos al PC (conectados entre la máquina a proteger y la red), o bien como un software implementado sobre un sistema operativo. Los primeros son denominados "Hardware Firewall" (cortafuegos por hardware) y los segundos, más comunes entre los usuarios 'de a pie' se conocen como "software firewall" (cortafuegos por software). La cantidad de marcas que fabrican estos dispositivos (Hardware Firewall) sería incontable y casi tendríamos que dedicar un post sólo para enumerarlas; pero para nombrar alguna de las más conocidas tenemos a Cisco o Linksys. Además de las funciones propias de un cortafuegos, estos dispositivos suelen implementar otras características, como pueden ser soportar VPN, QoS, proxis, entre otros.
      Los cortafuegos por software, destaca un nombre, IPtables, el cortafuegos que por defecto viene integrado con la mayoría de las distribuciones Linux, y es en el que nos centraremos, no sin mencionar antes los distintos tipos de software firewall que podemos encontrar.


      • Cortafuegos de Estado: Este firewall comprobará el estado del paquete en la transmisión diferenciando entre una nueva conexión y otra ya existente.
      • Cortafuegos de capa de aplicación: Tiene en cuenta el contenido del paquete a nivel de aplicación, pudiendo hacer así un filtrado más específico.
      • Cortafuegos de filtrado de paquetes: Con este tipo analizamos y filtramos los paquetes transmitidos o recibidos, según alguno parámetros designados previamente como por ejemplo direcciones IP, puertos a usar, origen, destino.
      Existen cuatro tablas a aplicar dentro de IPtables: filter, mangle, nat y raw; que a su vez contienen tres cadenas: INPUT, OUTPUT y FORWARD. Vamos a utilizar la tabla "filter", y lo podremos hacer de dos formas. Una sería aceptar todos los paquetes entrantes al equipo e ir restringiendo uno a uno los paquetes que nos interesen; esta sería la política conocida como ACCEPT. La otra forma de filtrar paquetes sería el opuesto, denegar el acceso a todos los paquetes y se van permitiendo los paquetes que queramos; esta segunda política de filtrado se conoce como DROP.
      Para especificar qué tipos de paquetes acceden o salen de nuestro equipo, tenemos que describirlos de una forma determinada para que IPtables nos comprenda. Para esto necesitamos órdenes y parámetros con los que formular la regla debidamente.
      Ordenes:
      IPtables –F: flush (borrado, vaciado) de todas las reglas IPtables –L: listado de reglas que se están aplicandoIPtables –A: añadir regla IPtables –D: borrar una regla
      Etc...
      Estos son varios de los parámetros que usaremos para configurar las reglas de IPtables.
      -p [protocolo]: Protocolo al que pertenece el paquete. -s [origen]: dirección de origen del paquete, puede ser un nombre de host, una dirección IP normal, o una dirección de red (con máscara, de forma dirección/máscara). -d [destino]: Al igual que el anterior, puede ser un nombre de host, dirección de red o dirección IP singular. -i [interfaz-entrada]: Especificación del interfaz por el que se recibe el paquete. -o [interfaz-salida]: Interfaz por el que se va a enviar el paquete. [!] -f: Especifica que la regla se refiere al segundo y siguientes fragmentos de un paquete fragmentado. Si se antepone !, se refiere sólo al primer paquete, o a los paquetes no fragmentados. -j [target]: Nos permite elegir el target al que se debe enviar ese paquete, esto es, la acción a llevar a cabo con él.
      Ahora vamos con un ejemplo de una regla que acepta conexiones al puerto 80 del sistema.
      iptables -A INPUT -i eth0 -s 0.0.0.0/0 -p TCP --dport www -j ACCEPT
      Y aquí la descripción de cada componente del anterior comando:
      iptables: comando para IPtables (no hay que olvidar que las reglas son un Shell script) -A: append, opción para añadir la regla INPUT: estado del paquete (al entrar es INPUT) -i eth0: interfaz de red eth0 -s 0.0.0.0/0:dirección de acceso (cualquiera en este caso) -p TCP: tipo de puerto --dport: puerto de destino -j ACCEPT:destino del paquete (se acepta aunque aquí podría ser DROP, LOG, REJECT,..)
      Pues ya tenemos y conocemos todo lo básico para crear un firewall por software en Linux a nuestra medida.
      Así que ahora pongámonos manos a la obra y lo primero será cortar todas las comunicaciones con esta línea:
      sudo iptables -P INPUT DROP
      Así lo que decimos a IPtables es que no permita el paso de ningún paquete de datos, y esto incluye incluso los salientes, por lo que si hacemos la comprobación, comprobaremos que no tenemos conexión a Internet. Esto lo podemos arreglar fácilmente si usamos la siguiente línea.
      sudo iptables -A INPUT -i lo -j ACCEPT
      Muy bien, ahora ya podemos navegar, pero indaguemos en algunas web y comprobemos que la carga de contenido está restringida, es decir, sí podemos navegar, pero no vemos imágenes, contenido flash y cualquier otro componente de una web de hoy día. Esto se debe a que con la línea anterior hemos permitido el acceso de nuestro equipo (con 'lo' que IPtables traduce como localhost, es decir, nuestro ordenador) a Internet, pero no al contrario. Fijemos entonces una norma que nos permita una navegación adecuada y segura a la par con la siguiente línea de comandos:
      sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
      Así decimos a IPtables que permita la entrada de datos al equipo, pero únicamente aquellos paquetes que estén relacionados directamente con las solicitudes que nuestro equipo ha emitido.
      Pues ya tenemos configurado nuestro cortafuegos por software con IPtables, sólo comentar una última cosa, y es que estas reglas desaparecen al apagar la máquina, por lo que al iniciarlas tendremos que volver a introducirlas. A no ser que programemos un script que se ejecute durante el inicio del sistema.

      ¿Qué es un Proxy y para qué sirve?

      Un proxy es un ordenador intermedio que se usa en la comunicación de otros dos. La información (generalmente en Internet) va directamente entre un ordenador y otro. Mediante un proxy, la información va, primero, al ordenador intermedio (proxy), y éste se lo envía al ordenador de destino, de manera que no existe conexión directa entre el primero y el último.

      En casi la totalidad de los casos, el proxy sólo sirve para ocultarse, y la mayoría de las veces estos proxies se usan para realizar prácticas ilegales (spam, fraudes, etc.). Es por ello, por lo que siempre es deseable evitar los proxies, sobre todo cuando son servidores de foros, chat o redes sociales.
      En otros casos (esa minoría de los casos), es cuando se usa un proxy como interconexión entre muchos ordenadores de una red, con Internet. En ese caso, se puede usar un proxy por las ventajas añadidas que posee.

      ¿Cómo se monta un proxy?
      Pues  con una IP dinámica, un servidor, un dominio, configurar el servidor (Linux o Windows) para ello, una sencilla página web, banners de publicidad y promocionarse (anunciarse).
      Ventajas

      Cuando se usa un proxy en una red interna para usarlo como conexión entre el exterior (Internet) y el interior (cada ordenador interno) posee muchas ventajas:
      • Menos tiempo de configuración (sólo hay que configurar el proxy).
      • Mayor seguridad
      • Filtrados más eficientes
      • Velocidad
      • En otros casos la mayor ventaja, sin duda, es:
      • El anonimato
      Desventajas
      • Carga. El proxy puede verse sometido a demasiada carga si muchos ordenadores realizan peticiones de forma simultánea.
      • Caché de datos entre 2 ordenadores. Algunos proxies pueden guardar copias de las transferencias, lo que supone cierta intromisión e inseguridad.
      • Desactualización. En algunos proxies la información más actual puede verse afectada.
       Tipos de Proxies
      • Proxy web.
      • Proxy inverso.
      • Proxy NAT.
      • Proxy transparente.
      • Proxy abierto.
      en este vídeo se explica en sencillos pasos la configuración de una proxy