Header Ads

Firewall IV

En los posts anteriores Firewall, Firewall II y Firewall III, abordamos temas relacionados con el control HTTPS usando el IPtables, para frenar el acceso a programas y sitios que usan el puerto de seguridad 443, conocido como puerto HTTPS.
También explicamos el uso de la tabla MANGLES y restringir el acceso de equipos no autorizados a nuestra red local de datos, entre otras reglas, pero solucionar del filtrado HTTPS via IPTables, o amarrar IP+Host+Mac no significa que todo está resuelto. Hay mucho Black Traffic que circula por el puerto 80 (HTTP), el cual puede ser filtrado por el Squid.
Squid es uno de los software tipo proxy más usados en la actualidad y es capaz de filtrar múltiples protocolos, pero, para el caso del proxy cache transparente, Squid no procesa peticiones al puerto de seguridad 443 en modo transparente (Vea Firewall); pero sí procesa el resto del tráfico por el puerto 80.
Ver tutorial de instalación de Squid para Linux y Windows
FILTRANDO BLACKTRAFFIC
El Administrador TI debe determinar que sitios debe bloquear y cuales no y crear una ACL que contenga estos portales restringidos para su red local, sin embargo, (tal y como sucedía con las IPs de HTTPS en el artículo Firewall) son incontables los sitios de descargas, de contenido adulto xxx, etc, etc.
Cómo bloquear millones de IPs y URLs con contenido no deseado... 
Si bien este trabajo es arduo para el Administrador TI, existen sitios que ofrecen ACLs Blacklists. Lo único que hay que hacer es descargarlas, colocarlas en una carpeta y agregarle al Squid las reglas de filtrado correspondiente, indicándole la ruta de las ACLs.
Estas ACLs pueden representar el 80% de los portales e IPs que el Administrador TI necesita bloquear. El restante 20% serán aquellas específicas que el Administrador TI haya recopilado y que no se encuentren en las ACLs ofrecidas en estos "big packs blacklists".
SUPERPACKS BLACKLISTS
Estos sitios especializados ofrecen Packs de ACLs Blacklists con Black Traffic. La ventaja es que los creadores las actualizan permanentemente, lo cual es un ahorro de tiempo considerable para el Administrador TI. He aquí algunos de ellos:
En Squidguard puede encontrar una relación de sitios que ofrecen las ACLs Blacklists
Capitole.fr (Free): Puede elegir las ACLs Blacklists de manera individual y descargar la que necesite (o descargarlas todas).
SquidBlacklists (Pago): Ofrece ACLs Blacklists para diversos usos.
URLBlacklists (Free y Pago): Descarga limitada. Viene configurado para dansguardian. Tiene un Script para hacer las actualizaciones automáticas. Puede descargarlo AQUI. Debe instalar Dansguardian primero.
Shallalist (Free): Colección de listas de URLs, similar a las anteriores, con la ventaja que tiene un script para su instalación en el Squid. Ver Howto AQUI y DD AQUI
MESD (Free): Un paquete de Blacklists más pequeño pero igual de efectivo.
O visitar nuestro proyecto blacklistweb.com, que recopila todas estas listas negras públicas en una sola ACL
Configurando Squid
Supongamos que hemos descargado una ACL con URLs de sitios con contenido para adultos (porno) y otra de sitios prohibidos de descargas. Ahora vamos a ponerlas en el Squid y a activarlas.
A modo de ejemplo las ubicaremos en una carpeta en la siguiente ruta:
/home/usuario/acl/porno
Sustituya usuario por tu-usuarioEditando squid.conf
sudo /etc/squid/squid.conf
o
sudo /etc/squid3/squid.conf
Inserte las siguientes reglas
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl webserver src 192.168.1.0/255.255.255.0
acl porno dstdomain "/home/usuario/acl/porno"
acl descargas dstdomain "/home/usuario/acl/descargas"
Y actívelas
# Don't upgrade ShoutCast responses to HTTP
acl apache rep_header Server ^Apache
http_access allow manager localhost
http_access allow manager webserver
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny porno
http_access deny descargas
http_access allow localhost
http_access deny all
upgrade_http0.9 deny shoutcast
Pueden seguir agregando reglas de filtrado con ACLs, por ejemplo, que prohíban las descargas de archivos vía HTTP (exe, mp3, mp4...) y solo dejar pasar pdf, xls, doc, etc. También se puede exceptuar las reglas para determinado grupo privilegiados de terminales dentro de la red local, los cuales deben estar también dentro de una ACL (macs-privilegiadas).
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl archivos-bloqueados rep_mime_type -i "/home/usuario/acl/archivos-bloqueados"
acl extensiones url_regex "/home/usuario/acl/extensiones"
Y luego...
# Don't upgrade ShoutCast responses to HTTP
http_reply_access allow macs-privilegiadas archivos-bloqueados
http_access allow macs-privilegiadas extensiones
http_reply_access deny archivos-bloqueados
http_access deny extensiones 
EFECTO DOMINÓ
Primero que todo hay que establecer que en un proxy server, que tenga Squid e Iptables "filtrando" el tráfico de nuestra red local, el tráfico primero llega al servidor y ahí se produce el filtrado, no antes ni después, por tanto no importará que tengamos el IPtables en DROP, ya que ante un ataque DDOS, al no haber nada protegiendo a nuestro Servidor Proxy, el ataque llegará y con toda seguridad el servidor caerá.
Ante esto, muchos se preguntarán: ¿Si usamos un servidor para proteger nuestro servidor, quién protege al primer servidor y así sucesivamente?.. Un servidor tras otro, protegiendo siempre al anterior; y si "el último" es atacado, cae el resto como fichas de dominó. El hecho de tener muchos servidores, firewalls dedicados y otros equipos perimetrales protegiendo nuestro servidor proxy y bases de datos, no garantiza que un ataque no llegue al núcleo de nuestra red local. Todo radica en la estrategia de defensa y no en la cantidad de equipos.
Existen varios tipos de ataques contra la infraestructura informática. En dependencia de su origen, tenemos los Externos (Outside), cuando vienen desde fuera de nuestra red local y los Internos (Inside), los se producen desde nuestra propia infraestructura, incluyendo nuestros servidores. También están los Directos e Indirectos (client-side attacks), basados en la forma del ataque. Puede leer sobre ellos en el portal thehackerway.com.
El más popular de los "Externos" es el de 'Denegación de Servicios' o (DoS o su variante DDos). Hay mucha documentación en Internet sobre estos ataques. Entrar en detalles sería muy extenso, pero puede consultar su funcionamiento AQUI y verlo en acción en un video publicado por la revista Enter.
Garantías... Ninguna. Hay que partir de la base que no existen soluciones 100% garantizadas. Todos son paños de agua tibia para un mal que crece cada día. Hay muchos "intentos", que van desde balancear las cargas con clusters (pool de servidores), rogarle a los ISP que ponga filtros para bloquear el Black Traffic, disminuir el tamaño de la pila TCP o un delay en el establecimiento de conexiones, hasta firewall dedicados por hardware o software, etc, etc... Sin embargo, si el ataque DDoS es superior a 1TB/s no lo para ni la NASA... (a no ser que apaguen los Backbones, Datacenters, Nodos, Botnet, Puntos Neutros, Tiers (Tier1 y Tier2) y demás puntos por donde circula el tráfico del ataque DDoS).
Ejemplo de ataque DoS mediano: Una “botnet” tiene 3000 máquinas zombies. Cada máquina utiliza una conexión hogareña (generalmente xDSL) con un promedio de 128 Kib/s de ancho de banda de subida (upstream). 3000 hosts * 128 KiB/s (upstream) = 384000 KiB/s = 375,00 MiB/s, el cual es suficiente para hacer caer cualquier sistema de rango medio.
Pero no debemos quedarnos con los brazos cruzados y ver cómo caen como moscas nuestro servidores. La mejor manera de protegernos hasta la fecha es aplicando un sistema de seguridad por capas (o niveles), que van desde la protección física primaria de la infraestructura informática, hasta el uso del sentido común.
He aquí algunas soluciones:
Gestión Unificada de Amenazas (UTM Unified Theat Management)
Es un Firewall avanzado que engloba múltiples funcionalidades, tales como Firewall, UDP, VPN, Antiphishing, Antispyware, Filtro de contenidos, Antivirus, Detección/Prevención de Intrusos (IDS/IPS), control de aplicaciones, acceso móvil, prevención de fuga de datos, información de la identidad, filtrado URL, Web, antibots, antispam & correo electrónico, read & clustering avanzados, software de emulación de amenazas, etc, etc, etc.
Hay una variedad de empresas que suministran este tipo de soluciones integradas tales como IBM FirewallCheckpoint Firewall o Stonesoft, (certificadas por ICSLABS), pero son productos muy costosos y requieren de soporte permanente. Hay alternativas Open Source, como Open UTM, pero aún está en fase de desarrollo.
Lectura recomendada: Seguridad Perimetral, UTM
Escudo de Red (NetShield o Network Shield)
Es la primera línea de defensa de tipo perimetral. Se define como un conjunto de técnicas y herramientas (integradas o independientes), de hardware y software, que vinculadas (o por separado) brindan la primera protección a una infraestructura informática. Puede estar conformada por sistemas IDS/IPS, uno o varios servidores (clusters) y diferentes tipos de hardware de red y equipos de comunicaciones, Firewalls, UnitSystemBox, proxy inverso, etc, en dependencia del esquema de protección que se pretenda brindar.
Su único objetivo es rechazar el Black traffic (Tráfico no deseado) hacia nuestras redes y solo dejar pasar el White Traffic (Tráfico solicitado), por lo que se convierte en un esquema ideal para blindar nuestros servidores locales de ataques, en especial los DDoS. He aquí algunos ejemplos de herramientas usadas en un Escudo de Red:
DDOS Deflate:  Un script de bash bastante efectivo para mitigar ataques DoS y DDoS pequeños y medianos, y muy útil en escenarios donde el servidor proxy solo se usa para filtrado de la red local y otros usos internos, y para pequeñas y medianas empresas y centros educativos.
Requerimientos
Conexión a internet para descargar el script y APF (si queremos usar que las IP´s sean baneadas a traves de APF). Este script se mantiene ejecutando en el servidor y puede detectar los ataques o conexiones originados desde múltiples direcciones IPs, mediante;
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Instalación
wget http://www.inetbase.com/scripts/ddos/install.sh
chmod 0700 install.sh
./install.sh
Desinstalación
wget http://www.inetbase.com/scripts/ddos/uninstall.ddos
chmod 0700 uninstall.ddos
./uninstall.ddos
Configuración
Edite el archivo de configuración:
/usr/local/ddos/ddos.conf:
Con los siguientes parámetros:
FREQ= "aqui ponemos la frecuencia en la que el O.S ejecuta dicho script en minutos" //Default =1
NO_OF_CONNECTIONS= "conexiones límites para una IP entrante al servidor" //Default =150
APF_BAN= "Si es igual a uno (1) se usará APF, sino lo tienes instalado, cámbialo por cero (0) para usar iptables" //Default =1
KILL= "Deniega la conexión a IPS de lista Negra" //Default =1
EMAIL_TO= "aquí ponemos el email a donde se nos enviaran las ips atacantes" //Default =root
BAN_PERIOD= "segundos de banneo tras realizar un ataque al servidor" //Default =600
Podría ser necesario cambiar la línea shebang de /bin/sh a /bin/bash en ddos.sh para que la primera línea quede como #!/bin/bash. Así mismo recomendamos instalar APF ya que es mucho mas preciso que mod_dosevasive/mod_evasive.
Para excluir IPs, incluyalas en el archivo ignore.ip.list
/usr/local/ddos/ignore.ip.list
Luego agregue el servicio al cron
sh /usr/local/ddos/ddos.sh -c
La entrada del cron job se añade en /etc/cron.d con el nombre ddos.cron
SHELL=/bin/sh
0-59/1 * * * * root /usr/local/ddos/ddos.sh >/dev/null 2>&1
Si el script detecta una ip atacante nos enviará un e-mail
root: administrador@maravento.com
Asunto “IP addresses banned”, con los datos de la ip baneada (fecha, ip, número de conexiones)
IP addresses banned on Mon Jan 25 10:30:09 CET 2014
Banned the following ip addresses on Mon Jan 25 10:30:09 CET 2014
xxx.xxx.xxx.xxx with 212 connections
Para mayor información visite RinconLejano
APF y BFD: También están los scripts APF (Políticas Avanzadas de Firewall) y BFD (Detección de Fuerza Bruta), que refuerzan a DDoS Deflate. Puede descargar el pack antiDDoS desde nuestra nube, el cual contiene DDos Deflate, APF y BFD. Para DDoS Deflate modifique el instalador para que busque los scripts dentro de una carpeta del pack antiDDoS. Puede ver su configuración AQUI
Otros scripts para protegerse de ataques DDOS basado en IPTables es el de Ruslan Abuzant y el de Citadel (similar a DDoS Deflate)
Reverse Proxy: Otra buena medida es un Proxy Inverso (Reverse Proxy). Un servidor proxy-caché pero "al revés". O sea, en lugar de permitir el acceso a Internet a usuarios internos, permite a usuarios de Internet acceder indirectamente a determinados servidores internos.
El Reverse Proxy, en vez de de bloquear las peticiones entrantes, trata consigo mismo. Esta estrategia ofrece una seguridad mucho más fuerte que un firewall tradicional, ya que un firewall comprueba la estructura del paquete de fuentes sospechosas de conexiones y lo deja pasar o lo rechaza, en dependencia de las reglas que tenga predeterminadas, pero el tráfico llega hasta el servidor y ahí se produce el filtrado; en cambio, el Proxy Inverso impide que la conexión no autorizada logre llegar al servidor de destino. Esto elimina cualquier posibilidad de un virus o spyware en el servidor. En este orden de ideas, un proxy-inverso protege a un proxy-caché (o a cualquier otro proxy que tengamos en la red local).
Tutoriales Cómo configurar un Proxy Inverso con Apache, y Qué es Reverse Proxy y cuándo usarlo?
Fail2ban y DenyHOST: De las mejores herramientas que han mostrado resultados efectivos en la prevención y supervisión de ataques por fuerza bruta (Tutorial Eng y Esp). Puede verlos juntos trabajando y con asterisk.
ARPon: De las mejores herramientas para impedir ataques por envenenamiento de la caché ARP (ARP Spoofing/Flooding/Poisoning or (ARP Poison Routing)) y MITM. No necesita de conocimientos avanzados para su configuración. Vea el Tutorial de instalación en Ubuntu
rkhunter: Un verificador de rootkits (mucho más completo y potente que chkrootkit). Se encarga de verificar el sistema de nuestro servidor por comparación de hashes MD5, búsqueda por archivos comunes usados por rootkits, permisos equivocados para binarios, búsqueda por cadenas de texto sospechosos en módulos LKM (Loadable Kernel Modules) y KLD (Kernel Loadable Device); búsqueda de archivos ocultos; opciones de escaneo dentro de archivos binarios y planos, etc. (Tutorial de instalación AQUI)
Hay ataques más peligrosos que el DDoS, que se desencadenan en nuestra red local y servidores, ya sea originado por un malware, una aplicación, u otro tipo de amenazas, en ocasiones casi imposibles de controlar por la proximidad teórica con el núcleo de la red.
Para blindar los puntos neurálgicos de la red local (servidores, bases de datos, etc) se debe contar con una protección adicional, más allá del Squid y el Iptables. En otras palabras, hay que evitar que el Black Traffic llegue a nuestro servidor principal, sin importar de donde venga. Para esto se pueden implementar medidas adicionales de seguridad perimetral. Dos de las más usadas son SELinuxAppArmor
SELinux: (del inglés Security-Enhanced Linux, Linux con Seguridad Mejorada) (Wiki) es un proyecto de la Agencia de Seguridad Nacional (NSA) de los Estados Unidos y de la comunidad SELinux.
Es una característica de seguridad de Linux que provee una variedad de políticas de seguridad, incluyendo controles de acceso a través del uso de módulos de Seguridad en el núcleo Linux. No es una distribución de Linux, sino un conjunto de modificaciones que puede ser aplicado a un sistema tipo Unix (como Linux y BSD). Por tanto activar este módulo es vital para proteger internamente nuestros servidores.
AppArmor: Fue creado en parte como alternativa a SELinux, que era criticado por los administradores por ser demasiado difícil de instalar y mantener. Al contrario que SELinux, que se basa en añadir etiquetas a los archivos, AppArmor trabaja con las rutas de los ficheros. Según sus autores, AppArmor es menos complejo y más fácil de aprender a utilizar para un usuario medio que SELinux. Añaden además que AppArmor necesita realizar pocas modificaciones en el sistema de ficheros mientras que SELinux necesita un sistema de ficheros que soporte sus atributos extendidos, lo que implica que no pueda controlar el acceso a archivos montados vía NFS. Con AppArmor no importa en qué clase de sistema de ficheros estén montados los archivos.
Lea los posts: Habilitando y Deshabilitando SELinux en FedoraSELinux TeoríaIntroducción a SELinuxSecure Ubuntu With AppArmor, Armado y protegido
Hay otras alternativas que ayudan a proteger el núcleo de nuestra red; entre ellas:
Systrace: Un sistema diseñado para "enjaular" las app que intenten correr en el servidor.
Sandboxes o Entornos de prueba: Similar a Systrace, con la diferencia que prueba las aplicaciones en un entorno virtual antes de dejarla ejecutar en el entorno real.
Secure Virtual Cloud (SVC es una plataforma completamente virtual (Open Source). Su función principal es correr todo tipo de tráfico cliente-servidor por la plataforma virtual en la nube, incluyendo sistemas operativos, aplicaciones, comunicaciones, transporte de datos, ejecutar archivos y programas, sistemas virtualizados, etc, con el objeto de que si se produce un daño por malware, ataques informáticos, aplicaciones corruptas, o factor humano (mal uso), simplemente se reemplaza el sistema completo (o el segmento virtual afectado), por otra plataforma en limpio, de manera transparente y transparente, sin que afecte ningún servicio, programas, ni comprometa los datos de la red local y usuarios. Esto se logra gracias a que tiene la capacidad de autoclonarse de manera incremental, según la programación del Administrador TI. Tampoco se afecta la seguridad, ya que posee un sistema de encriptación militar, siendo la encriptación de la capa de transporte la mejor alternativa en la actualidad.
Si bien los sistemas actuales de encriptación y los números aleatorios has sido fuertemente cuestionados por tener supuestos backdoors (incluso Linux ha caído en desgracia ante la posibilidad de estar penetrado por la NSA) la batalla por la privacidad no está perdida. En el caso de los sistemas basados en SVC, se crean tramas de datos conocidas como "miel"; o sea de introduce dentro del tráfico habitual codificado un volumen considerable de "datos no relacionados con los reales",  para que el atacante, en el supuesto caso que logre burlar la seguridad perimetral y entre al túnel, tarde años en "armar el rompecabezas", ya que la criptografía usada para proteger el tráfico real está basada en números aleatorios que se generan por una combinación de software y hardware (externo e interno), sin el patrón definido del chip y RDRand de Intel o la "piscina de entropía" de Linux.
EL FIN JUSTIFICA LOS MEDIOS
La única manera de saber realmente si nuestro trabajo de protección sirve de algo es haciéndole una auditoria. En otras palabras, bombardear nuestra defensa perimetral con todo lo que tengamos, sin importar qué sea, hasta que se reviente o aguante la embestida... Es mejor hacerlo uno mismo que esperar a que otro lo haga.
Existen muchas herramientas capaces de determinar qué tan sólida es nuestra defensa. Una muy buena es la Mega Suite Net Tools, que contiene casi todo lo necesario para probar una red.
En GNU/Linux las más usadas para capturar y analizar el tráfico son Wireshark (InstallManual), TCPDumpNmapIPTraf (Manual), Ettercap y NLAS, entre otras. Una descripción de estos programas puede encontrarla en Bloqueando IP atacante y Snifeando su proxy
FOCA es otra herramienta muy recomendada, que realiza procesos de fingerprinting e information gathering en trabajos de auditoría web. La versión Free realiza búsqueda de servidores, dominios, URLs y documentos publicados, así como el descubrimiento de versiones de software en servidores y clientes. FOCA se hizo famosa por la extracción de metadatos en documentos públicos, pero hoy en día es mucho más que eso.
También tenemos Suricata, Snort, Cutter, Metasploit, Anonymous High OrbitIon Cannon, Dawn of Darkness tool, Zap, DHCP ACK Injector, etc. Una gran cantidad de herramientas para pentest e instructivos pueden encontrarlos en los portales especializados SecurityByDefault e Informatica64
Podemos auto-ejecutarnos un ataque de DDoS contra nuestra propia infraestructura, de manera controlada. El objetivo es que el Administrador TI compruebe la capacidad de tráfico que sus servidores pueden soportar sin volverse inestables y afectar a los servicios que prestan, o sea, conocer la capacidad real de cada máquina.
Puede utilizar Low Orbit Ion Cannon (LOIC), que es una aplicación del proyecto Chanology, la cual realiza un ataque de denegación de servicio del objetivo enviando una gran cantidad de paquetes TCP, paquetes UDP o peticiones HTTP con objeto de determinar cuál es la cantidad de peticiones por segundo que puede resolver la red objetivo antes de dejar de funcionar. También puede usar Turbinas, o Hping3, Ping Flooding o cualquier otra herramienta hacking para explotar las vulnerabilidades de su propia red.
Ejemplo de ataque DDoS con Hping3
sudo apt-get install hping3
sudo hping3 --rand-source -p 80  -S --flood 192.168.1.1
o
sudo hping3 -S 192.168.1.1 --flood --rand-source -d 5000 -p 80
Donde 192.168.1.1 es la ip de nuestro servidor proxy que pretendemos hacer caer, -p 80 es el puerto que elegimos atacar, -S activa el flag Syn, --flood le indica a hping que envíe los paquetes a la máxima velocidad posible, --rand-source hace que se generan direcciones de origen ip al azar (para no saturar nuestra propia máquina con las respuestas (Spoofing) o también se puede usar -a ip_falsa (en reemplazo de --rand-source) para usar una ip diferente a la nuestra y finalmente -d, que indica el tamaño del cuerpo del paquete (expresado en bytes). Este valor puede variar.
Al cabo de unos pocos segundos, el servidor se volverá inaccesible dada la cantidad de requests que el servidor tiene que procesar. Al intentar acceder al servidor o sitio atacado por el puerto 80, se obtiene un timeout dado que no puede responder a peticiones genuinas por estar saturado de paquetes malformados.
Vea SYN Flood con Hping3 y Ataques coordinados DDos
Distribuciones especializadas GNU/Linux
Muchas de las tools descritas anteriormente se recogen en distros especializadas en seguridad perimetral, análisis forense, recuperación, penetración y filtrado. Una distro especializada y preconfigurada, no solo ahorra tiempo al Administrador TI, sino que garantiza que no pase por alto alguna protección esencial a la hora de la configuración.
Una buena alternativa es Zeroshell. Es una distribución GNU/Linux casi desconocida, pero muy profesional. Especial para servidores y dispositivos integrados destinados a proporcionar los servicios de red principal de una LAN requiere. Está disponible en forma de Live CD o de imagen de Compact Flash y se puede configurar y administrar utilizando el navegador web. La ventaja es que no es un folk sino una distro genuina independiente, ideal para equilibrio de cargas, tráfico 3g, servidor radius, proxy inverso, portal cautivo, etc, etc.
Existen muchas distribuciones de este tipo, tales como Backtrack, y su archicompetencia Kali LinuxNetwork Security Toolkit (NST) (Basada en Fedora y equipada con herramientas de análisis de seguridad de redes, programas de validación y monitoreo); Pentoo (creada para pruebas de penetración y asesoría de seguridad. Basada en Gentoo); Helix (Basada en Ubuntu y diseñada para análisis de sistemas, recuperación de datos, auditoría de seguridad, y respuesta a incidentes); WiFiSlax (diseñada para la auditoría de seguridad y relacionada con la seguridad informática en general); BackBox Linux (Basada en Ubuntu y diseñada específicamente para tareas vinculadas a seguridad de redes, análisis forense, ingeniería inversa, reportes, etc.) BeiniOperatorInside Security Rescue Toolkit, Deft Linux, Fire, Local Area Security LAS, PhlaknUbuntu (Network Ubuntu), entre otras.
En el artículo Distros de Seguridad y Firewall encontrará las distribuciones servidor con múltiples funcionalidades incorporadas, relacionadas con seguridad.
Con la tecnología de Blogger.