<leonk24> hola buenas tardes a todos<nitcom> Bueno , señores , segun lo anunciado .. esta es la 4 charla correspondiente a la serie de charlas<nitcom> programadas ..<nitcom> como ya todos saben .. el dia de hoy en es un tema de seguridad<nitcom> desde un nivel basico<nitcom> a intermedio<nitcom> y si las preguntas la requieren a un nivel avanzado<nitcom> el log de la charla estara en la web ..<nitcom> señores .. es un gusto presentarles al expositor del dia de hoy<nitcom> el Ing. Carlos Leon <nitcom> aunque le agrada que solo le digan sr.. carlos<nitcom> :)<leonk24> jajajja<leonk24> nada de señor :)<nitcom> bueno .. si mas preambulo , Carlos , la sala es tuya .<nitcom> :))<leonk24> ok gracias totales<leonk24> bueno la charla de hoy trata basicamente de los principios de seguridad que deberiamos practicar en ambitos generales (empresa, casa, cabinay lo que fuere)<leonk24> primeramente hay que definir los aspectos basicos que conforman las seguridad<leonk24> Confidencialidad :<leonk24> Nos dice que los Objetos de un sistema van a ser accedidos unicamente por elementos autorizados a el. Y que los elementos autorizados no van a cambiar los permisos del objeto<leonk24> Integridad :<leonk24> Significa que los objetos solo pueden ser modificados por elementos autorizados y de una manera controlada<leonk24> Disponibilidad:<leonk24> Indica que los objetos del sistema tienen que permanecer accesibles a elementos autorizados.<leonk24> No esta demas indicar que estos aspectos de seguridad...dependiendo de tipo de red que queramos proteger, algunos se pueden potenciar mas que otros. <leonk24> Un ejemplo en un banco podria decirse que es mas importante la Integridad que la Disponibilidad<leonk24> es decir es mas importantte que los saldos de personas esten intactos que el servicio se caiga por unos minutos. Lo primero no se puede permitir lo segundo no deberia permitirse pero si sucede no es un desastre total<leonk24> Bueno una vez dejado un poco en Claro estos aspectos pasaremos a comentar un poco las herramientas y niveles que nuestro sistema operativo favorito LINUX nos ofrece para implementar lo antes ya descrito<leonk24> Primero tenemos la Seguridad en el FileSystem. Es el nivel más básico de integridad de los UNIX y estan si no me equivoco desde el principio de los tiempos<leonk24> es decir cada Archivo y cada Proceso del Sistema tiene un Propietario. Y solo el puede modificar los permisos hcia otras personas<leonk24> u usuarios<leonk24> podemos darnos cuenta de esto porque ademas de los usuarios comunes y silvestre de un sistema existe el usuario administrador (root) y "usuarios especiales" que unicamente se utilizan para levantar procesos y servicios dando mayor seguridad a ello. Por ejemplo el usuario apache, squid, postfix<leonk24> esto nos permite que no todos los servicios corran con privilegios totales de root. <leonk24> Entonces si vemos bien la carpeta con ls -ld /var/spool/squid <leonk24> veremos que en la primera columno aparecen unos permisos y a continuacion un par de columnas mas para el usuario y grupo propietario respectivamente<leonk24> Esto nos indica que el proceso(servicio) squid tiene los maximos privilegios solo en esa carpeta (dependiendo de los permisos).<leonk24> Entonces este es el mismo principio porque nuestro querido Linux no hay virus de peligro. Porque si un usuario ejecutara un virus (programa malicioso) desde su sesion ya sea grafica o texto<leonk24> el virus solamente se ejecutara con los permisos que el usuario tiene, Es decir afectando solo a su home directories y mas no a todo el sistema<leonk24> No en vano como primera regla al usar Linux nos piden que no utilizemos el usuario root a menos que fuera necesario.<leonk24> Imaginense un virus con acceso a todo el sistema...!!! :(<leonk24> Otro aspecto fundamental que debemos controlar en Linux...es el numero de servicios que brinda el equipo a asegurar.<leonk24> Bueno retrocendiendo un poquito. Para cambiar permisos del filesystem tenemos el comando chmod..(mas informacion man chmod)<leonk24> y Para cambiar los propietarios de un archivo del filesytem tenemos el comando chown.<leonk24> Otro aspecto fundamental que debemos controlar en Linux...es el numero de servicios que brinda el equipo a asegurar.<leonk24> Si tenemos ya seguro nuestro filesystem deberiamos pasar a analizar que es lo queremos hacer con el sistema Linux a proteger<leonk24> Si por ejemplo es un servidor de Correo. Deberia brindar los servicios unicamente necesarios para realizar su funcion<leonk24> ademas de tambien controlar a quien se le brinda ese servicio<leonk24> bueno para saber que servicios y en que puertos esta prestando nuestra maquina. El comando netstat --listening es muy util.<leonk24> Tambien es necesario conocer que facilidades de seguridad nos presta cada servicio para configurar y prestar ese servicio al minimo numero necesario de usuarios<leonk24> por ejemplo en sendmail tenemos el archivo (/etc/access) donde definimos a quien permitimos enviar un correo y hacer relay<leonk24> en el servicio samba existe la linea host allow (/etc/samba/smb.cnf) para permitir solo el acceso a determinados IP al servicio<leonk24> y asi la mayoria si no todos los servicio tienen sus propias directivas de seguridad que deberiamos implementar y no esperar a que un firewall haga ese trabajo<leonk24> Entonces para implementar una buena seguridad a este nivel tenemos que conocer bien el servicio que vamos a implementar. Conocer los exploits posibles para esa version y por supuesto tenerlo siempre actualizados a las ultimas versiones. Si cumplimos esto nuestro Servidor sera solido como una roca.<leonk24> Existe unas directivas de seguridad que poco se utilizam o al menos eh visto que se utilizan poco<leonk24> y son las directivas de las librerias pam<leonk24> esta libreria nos permite tener un control centralizado de las autentificaciones de los diferentes servicios de nuestro sistema.<leonk24> serivicios y procesos (correccion)<leonk24> si entramos al directorio /etc/pam.d/<leonk24> vamos a encontrar un relacion de ficheros que llevan las directivas para su respectivo proceso<leonk24> por ejemplo si vemos el archivo login.<leonk24> vemos una serie de directivas.<leonk24> En la primera columno encontramos el tipo de modulo de la libreria que sera utilizado<leonk24> en la segunda el flag de control <leonk24> en la tercera el nombre del modulo propiamente dicho<leonk24> y en la cuarta los argumentos<leonk24> en la primera linea de login dice<leonk24> en la primera linea de /etc/pam.d/login dice<leonk24> auth required pam_securetty.so<leonk24> esto quiere decir por ejemplo que el modulo llamado es un modulo de autentificacion <leonk24> que el flag es requerido. Es decir se van a ir cargando e inspeccionando las siguientes directivas de /etc/pam.d/login. Pero si falla el resultado ya esta determinado. "Va a fallar o denegar el acceso". <leonk24> Bueno esta linea nos impide basicamente que nadie se puede logear como root fuera del tty consideradas seguras (tty locales). Nadie se podra logear como root remotamente a menos que esta linea de comente.<leonk24> Los tipos de Modulos son los siguiente.<leonk24> auth --> autentificacion<leonk24> account --> autorizacion y administracion de la cuenta<leonk24> password --> actualizacion de credenciales (password)<leonk24> session --> modificacion de entorno del usuario<leonk24> y los flags de control son<leonk24> required --> ya comentado anteriormente<leonk24> requisite --> si falla la verificacion de ese modulo. Inmediatamente reporta el fallo sin necesidad de cargas las otras directivas<leonk24> sufficent --> si el resultado es positivo inmediatamente acepta sin necesidad de cargar los demas<leonk24> optional --> el resultado de cualquier modulo optional es ignorado<leonk24> Bueno se que es un poco confuso todo esto de las pam.d pero al menos espero haberles dado un alcance para que se despierte su propia investigacion y pienses en la infinidad de posibilidad que nos presentan estas estupendas librerias<leonk24> miren por ahi todas los archivo que encuentren y veran que casi todos llaman a este archivo /etc/pam.d/system-auth<leonk24> es aqui donde se concentra la forma de acceder al Sistema. Es decir si se va a loguear con los passwd y shadow, desde NIS, desde LDAP, desde PDC, Hesiod. Etc.<leonk24> Bueno pasando a otro punto llegamos a los TCP-WRAPPERS.<nitcom> cool !<leonk24> los tcp-wrappers se resumen en la configuracion de dos archivos /etc/host.allos /etc/host.deny<leonk24> no todos los servicios permiten ser controlados por tcp_wrappers <leonk24> entre ellos tenemos todos los manejados por xinetd, sendmail, slapd, sshd, stunnel, tcpd, gdm, ORBit, portmap (nfs,nis)<leonk24> cabe mencionar que a diferencia del firewall la conexion se llega a realizar pero es ahi donde se valida su estado en host.allow o host.deny<leonk24> Existen tres estado<leonk24> Si el acceso es explicitamente permitido..Accede<leonk24> Caso contrario...Si el estado es explicitamente negado...Se Deniega<leonk24> Caso contrario...Si no hay ninguna directiva al respecto se permite el acceso<leonk24> Es decir TCP-WRAPPERS en permisivo por defecto<leonk24> Conversaremos un poco la configuracion.<leonk24> la sintaxis basica tanto como host.allow y host.deny es la siguiente<leonk24> daemon: lista_clientes [:opciones]<leonk24> En daemon va especificamente el nombre del proceso (no del servicio)<leonk24> va sshd no ssh.<leonk24> En Lista Cliente podemos tener:<leonk24> Lista por IP, por nombre de host, por REd (IP/MASK)<leonk24> por ejemplo en /etc/host.allow podria haber lo siguiente<leonk24> in.telnetd: 192.168.1.0/255.255.255.0<leonk24> y en host.deny<leonk24> podria haber<leonk24> ALL: ALL<leonk24> esto quiere decir que solo a esa maquina entrara usuarios de la red local al servicio telnet y nadie podra conectarse cualquier servicio que soporte tcp-wrappers<leonk24> tcp-wrappers soporta operadores como comodines para su mejor utilizacion<leonk24> ALL , UNKNOWN (todos los hosts que no puedan hacer looed up), KNOWN (lo contrario a lo anterior)<leonk24> ademas de EXCEPT (que sirve para implementar excepciones a una regla)<leonk24> Bueno ahora pasaremos a la herramienta principal<leonk24> para una red<leonk24> el firewall...<leonk24> Bueno en Linux el firewall no es un servicio propiamente dicho...esta en el dominio del kernel<leonk24> por lo que todo linux por defecto tiene soporte para firewall(iptables en el kernel 2.4)<leonk24> entonces El firewall del 2.4 que vamos a comentar en esta charla sera el iptables<leonk24> tambien conocido como NetFilter<leonk24> Este firewall se divide en 6 cadenas básicas y 3 tablas principales.<leonk24> Comentaremos las Tablas.<leonk24> filter:<leonk24> es la tabla basica de filtrado de paquete aqui van reglas de aceptar o filtrar deternimados paquetes de acuerdo a condiciones preestablecidad<leonk24> soporta las cadenas INPUT, FORWARD, OUTPUT<leonk24> nat:<leonk24> es la tabla que permite establecer reglas de NAT (NETWORK ADDRESS TRANSLATION)<leonk24> modificando las direcciones y puertos tanto de origen como destino.<leonk24> soporte las cadenas OUTPUT, PREROUTING, POSTROUTING<leonk24> mangle:<leonk24> permite la modificacion de caracteristicas especiales de los paquetes como el tos por ejemplo<leonk24> ademas permite asignarle una marca al paquete, que nos podria servir posteriormente para reglas secundarias de ruteo o de control de tráfico<leonk24> esta tabla mangle soporta todas las cadenas<leonk24> entonces ahora definamos las cadenas.<leonk24> Las Cadenas son estados por donde pasan los paquetes<leonk24> Comenzaremos con<leonk24> PREROUTING :<leonk24> es el estado de paquetes de entrada antes de la desicion de ruteo ( se decide si el paquete sera reenviado a otra maquina o si se utilizara en un proceso local)<leonk24> INPUT :<leonk24> despues de la desicion de ruteo inmediatamente antes de pasar el paquete a un proceso local<leonk24> FORWORD ;<leonk24> despues de la desicion de ruteo si el paquete sera reenviada a otro host<leonk24> en la zona de SALIDA tenemos<leonk24> OUTPUT :<leonk24> Es un estado donde los paquete han salida directamente del sistema local. <leonk24> POSTROUTING :<leonk24> Una vez que se decide poruqe tarjeta de red va a ir el paquete se pasa al estado POSTROUTING<leonk24> http://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm#_Toc73696475<leonk24> aqui les paso un link donde pueden encontrar un gráfico explicatorio de lo comentado anteriormente y mas claro esta<leonk24> Entonces los puntos de filtraje necesarios siempre son. INPUT FORWARD y OUTPUT. En la tabla filter<leonk24> supongamos entonces que queremos impedir la entrada de conexiones a nuestro puerto de correo electronico<leonk24> puerto 25<leonk24> tendriamos que poner la regla en la tabla filter en la cadena input y seria como sigue<leonk24> iptables -t filter -A INPUT -p tcp --dport 25 -j DROP<leonk24> donde -t indica la tabla<leonk24> donde -A indica que hay que agregar (ADD) a esta cadena<leonk24> -p el tipo de protocolo<leonk24> --dport protocolo de destino 25<leonk24> -j Aqui termina la condicion y luego va a ir la accion que se ejecutara<leonk24> como acciones comunes tenemos DROP, LOG, REJECT y ACCEPT. Donde DROP descarte el paquete sin dejar huella de el<leonk24> LOG guarda un lod del paquete en /var/log/messages<leonk24> REJECT rechaza el paquete enviando un paquete de control ICMP para explicar las razones del rechazo (DROP NO ENVIA NADA SE COME EL PAQUETE)<leonk24> y ACCEPT que bueno es obvio<leonk24> entonces la sintaxis básica seria<leonk24> iptables -t TABLE -[AID] CADENA "aqui viene la condicion" -j "DESICION"<leonk24> la condicion se puede estables con numerosos parametros<leonk24> -s --> Ip de origen<leonk24> -d --> Ip de destino<leonk24> -p --> protocolo, sirve para establecer puertos propiamente<leonk24> puede ser tcp, udp, icmp<leonk24> --dport --> puerto de destino de la conexion<leonk24> --sport --> puerto de origen de la conexion<leonk24> la forma de escribir IP o rangos de red pueden ser<leonk24> 192.168.1.0/255.255.255.0 --> Notacion comun<leonk24> 192.168.1.0/24 --> Notacion CIDR (24 bits de red)<leonk24> Cabe mencionar que en iptables todos los paquete son analizados ya sea de establecimiento de conexion, o de respuestas<leonk24> es decir la respuesta tambien debe tener su regla hecha<leonk24> pudiendo ser de esta manera<leonk24> iptables -t filter -A INPUT -p tcp --dport 25 -j DROP (ANTERIOR)<leonk24> iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT (CAMBIO A LA ANTERIOR)<leonk24> iptables -t filter -A OUTPUT -p tcp --sport 25 -j ACCEPT (PARA ACEPTAR LA SALIDA DE LAS RESPUESTAS)<leonk24> esta seria una forma de permitir acceso al puerto 25 y que las respuestas salgan por el<leonk24> Cabe mencionar que existen politicas por defecto en cada una de las cadenas de cada tabla<leonk24> es decir podemos establecer que en la cadena INPUT de la tabla filter todo sea negado por defecto e ir abriendo puerto con determinadas reglas<leonk24> para modificar una politica por defecto, haremos lo siguiente<leonk24> iptables -P INPUT DROP<leonk24> iptables -P OUTPUT DROP<leonk24> iptables -P FORWARD DROP<leonk24> que en realidad es lo mas seguro..y de ahi ir abriendo puertos y reglas hacia nuestra red. o Nosotros mismo<leonk24> como ya deben saber para permitir el forwarding de paquete deben cambiar el parametro de ip_forward de 0 a 1 en el archivo /etc/sysctl.conf<leonk24> Las dos reglas comentadas anteriormente harian tedioso la implementación de un firewall en Linux, pues se deberia habilitar una regla de entrada y otra de salida para las respuesta en cada conexion<leonk24> lo que se hace comumente es analizar los estados de las conexiones..(esto es una extension del iptables que se cargo como modulo ampliamente soportada)<leonk24> entonces podemos definir que todas la conexiones que ya estan previamente establecidas o relacionadas con otras sean aceptadas, asi nos evitaremos la regla de respuesta.<leonk24> y seria como sigue en cada uno de las cadenas de filter<leonk24> iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT<leonk24> iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT<leonk24> iptables -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT<leonk24> asi se asegura que toda respuesta va a pasar por nuestro firewall y solo nos queda preocuparnos del filtrado de las conexiones nuevas<leonk24> ojo que estan reglas deberian ser las primeras en cada cadena del firewall<leonk24> Bueno espero que haya quedado claro esta parte...pregunten con toda confianza. gustoso contestare a todo<leonk24> gracias nitcom<arauko> leonk24, perfecto :-)<arauko> preguntas?<arauko> ok, bueno, leonk24 gracias tio , todo fue bien entendido al parecer :-)<arauko> buena charla<SpiderMan2> a ver<SpiderMan2> tengo entendido que CheckPoint lidera el mercado mundial de firewalls<leonk24> bueno puede ser cierto eso.<SpiderMan2> es posible construir un firewall en Linux con la misma seguridad que brinda Checkpoint ???<SpiderMan2> recuerda que ellos inventarios el Stateful Packet Inspection<leonk24> al parecer iptables brinda mas seguridad que el checkpoint al ser kernel inside y tener un monton de opciones para establecer las condiciones. Incluso opciones que no brinda el checkpoint<SpiderMan2> y ahora todos los firewalls trabajas en forma mixta, lo hacen con SPI mas proxys de aplicacion<leonk24> al menos en su version normal<leonk24> iptables + iproute2 + tc. Tienes un Gateway que controla todo<SpiderMan2> mmmm entiendo<arauko> creo que ya eso es todo<arauko> leonk24, Gracias tio<nitcom> tengo una pregunta leonk24 , el fw , es tanto filtro por puertos , como denegacion de accesos a ips .. pero todo esto trabaja en capa 3 (ip) , dime , lei un poco de trabajo en modo promiscuo<arauko> hah<leonk24> gracias a ustedes tambien<nitcom> es decir , hacer trabajar el fw , como un bridge ..<nitcom> capa 2<nitcom> que tan efectivo esto , es decir , evitar notar que el fw esta presente al tio que desea acceder a nuestra red<leonk24> eh leido trabajos sobre eso. Nunca lo he implementado no se el perfomance especifico<nitcom> otra ok ...<nitcom> netfilter esta integarada en el kernel ..<leonk24> el comando brctl es el que brinda está opcion no me fijado si fedora core 2 trae el modulo ya compilado<nitcom> al igual ipsec ..<leonk24> pero yo preferiria mil veces implementar una vpn con cipe oculto asi el oculto el firewall y brindo una mayor seguridad<nitcom> convendria usar ambas cosas , o no es buena mezclarlas ? es decir .. netfilter + ipsec ?<leonk24> o claro con ipsec...justamente en eso ando ahora con un roadwarrior para windows que me esta demorando<leonk24> yo lo he usado con ipsec y va bastante bien. Pero ipsec es mas seguro, autentifica ademas de se estandar<nitcom> podrias ilustrarnos quizas algo breve , sobre que cosas puedo hacer sobre ipsec ?<leonk24> bueno con ipsec podemos formar una vpn (VIRTUAL PRIVATE NETWORK) que no solo encripta el tunel si no que ademas lo puede validar por medio de certificados digitales asegurandose que los paquetes llegue y venga de un verdadero destino<leonk24> existen configuracion NET-NET que normalmente utilizan ESP<leonk24> las configuraciones HOST-HOST que utilizan a veces simplemente AH<leonk24> las NET-HOST RoadWarrior que permiten tener un Gateway de acceso para equipos moviles o externos que no representen una red solo un hosts.<leonk24> la implemtacion que normalmente se utiliza de ipsec es freeswan que ahora es openswan.<leonk24> es compatible con muchas otros sistema de VPN. la lista aqui<leonk24> esta es la lista de interoperabilidad http://wiki.openswan.org/index.php/interoperating<leonk24> algo mas<nitcom> vpn , pero a nivel capa 3 o a nivel aplicacion ? , por que si yo armo , una red mpls , con cisco , creo vpn's , pero esto es capa 3 , ipsec hace lo mismo ? o solo en aplicacion <leonk24> es a nivel capa 3<leonk24> no utiliza ni tcp ni udp<leonk24> como cipe<leonk24> sino utiliza sus propios protocolos esp y ah<nitcom> bacan !<nitcom> una tercera y ultima tio ... espero no te molestes , que sabes de ebtables , es bueno ya ir experimentando con ello , o el codigo aun es muy duro ?<leonk24> no se na...haber alfabetizamente<nitcom> :))<nitcom> solo la evolucion de iptables<leonk24> alfabetizame<nitcom> ipmasq -> iptables -> ebtables<leonk24> asi yo pense que era arptables que tanto promociona redhat<leonk24> y en realidad no lo eh visto<jodias_verdes> el asunto de los Live-CD Linux, que son capaces incluso de montar y acceder como root con permisos totales a las $HOME de cualquier sistema, incluÃdo la FC2<leonk24> es normal porque es un otro kernel que esta accediendo a los filesystem.<leonk24> Para evitar es importante la seguridad fisica o encriptar tus filesystem<leonk24> ext3 lo permite<jodias_verdes> le leido en un articulo hace unos dias que permite encriptar ficheros de un maximo de 2 Gb<jodias_verdes> no recuerdo que programa era<leonk24> no encriptar fichero..si no encriptar el filesystem entero la particion entera<leonk24> en linux<LinuxBlues> el propio kernel permite encriptar filesystems, pero el problema es que se encuentran patrones repetitivos tras encriptarlos con el algoritmo que utiliza el kernel, lo cual es preocupante, pero no permitira que nadie acceda a tus filesystems<LinuxBlues> utiliza el propio del kernel <leonk24> quieres decir con patrones repetitivos ( que el algoritmo de encriptacion no es tan bueno) o es que hay mucha redundancia<leonk24> que se podria en algun momento romper con ayuda de esos patrones..eso quieres decir...!!<LinuxBlues> quiero decir que si hay un patron repetido en el filesystem encriptado es "mas facil" saber o acercarse a saber lo que contiene ese filesystem<LinuxBlues> solo es preocupante, pero nadie los ha desencriptado aun<LinuxBlues> que se sepa<leonk24> ok<jodias_verdes> He leÃdo que en Mac's hace meses que se encripta el /home/user automaticamente y en tiempo real...sorprendente?<leonk24> uhm ..mac siempre sorprende en algo<leonk24> :)<jodias_verdes> gracias :)<Administr> la redundancia es un punto flaco en la encriptacion de ahi que trate con compresion como parte del algoritmo para eliminarla<leonk24> uhm aya que bien<leonk24> bueno muchachos me despido cuidense<nitcom> bueno .. Carlos Leon ..<nitcom> Muchas gracias por tu valioso aporte a la comunidad<leonk24> de nada...