Más allá de las instrucciones técnicas Webmasters help for hacked sites también permite a los usuarios saber por qué ha sucedido algo como esto y como evitar la temida etiqueta ‘Este sitio puede dañar tu equipo’ incluido en los resultados de búsqueda.

El gigante de Internet ya ha publicado más de 80 minutos de vídeo en su canal Google Webmasterscon múltiples consejos de seguridad y mantenimiento para evitar que tu sitio sea colocado en la lista negra. Uno de ellos como muestra:

 
fuente: muycomputer

fuente:desarrolloweb

FUENTE: Canarias7

La opinión de la Seguridad Nacional estadounidense sobre Java no ha cambiado un ápice, desde que el pasado viernes se descubriese una vulnerabilidad crítica -de las conocidas como 0-day-, y como informan nuestros compañeros de MuySeguridad, mantienen su recomendación de no utilizar el software por motivos de seguridad.

Como sabes, Oracle tardó muy poco en lanzar una actualización para Java una vez se descubrió el agujero. O eso pareció, ya que la compañía tenía constancia del problema desde agosto, y no había hecho nada. Y ahora que lo ha hecho, dicen los expertos, siguen habiendo vulnerabilidades abiertas.

No todo es malo, o al menos no tan negativo, y la actualización de marras activa por fin, por defecto, un nuevo sistema de control por el que se pueden configurar diferentes niveles de seguridad de manera que solo se permita la ejecución de módulos firmados.

A pesar de todo, el consejo de los expertos no ha variado: mantener deshabilitado Java es la mejor protección (junto con Flash Player y Windows, el software que más agujeros de seguridad registra en todo el mundo, desde hace años).

fuente:muycomputer

Mucho se ha hablado de que Joomla! inseguro, y lo cierto es que muy pocas veces se han aportado datos que puedan confirmar esas hipótesis. La desinformación muchas veces ha provocado que asumamos como ciertas algunas opiniones de profesionales que no se han molestado en buscar la raíz de los problemas. Si te lo quieres demostrar a ti mismo, en este artículo se especificarán al final diversas acciones que podrás implementar para que Joomla! pueda ser utilizado con toda seguridad.

Por qué no se debe decir que Joomla es inseguro

Partamos del hecho que la inseguridad es una constante de todo sistema informático. Nunca podemos decir que un software es completamente seguro, igual que nadie puede asegurar que esté completamente libre de errores. La inseguridad existe, en Joomla!, igual que en cualquier otro CMS o pieza de software en general. Existen en Internet multitud de sitios basados en Joomla! que son inseguros ¿Pero realmente se puede generalizar y decir que por ello Joomla! es inseguro?

La seguridad o la inseguridad es realmente una responsabilidad de los desarrolladores, que muchas veces no hacemos correctamente nuestro trabajo. Pero no me refiero a la comunidad que realiza el propio CMS, sino más bien a quienes lo utilizamos para construir sitios basados en él. Los desarrolladores muchas veces dejamos huella de nuestro trabajo y con ello a veces quedan piezas de software que pueden comprometer un sistema. El ejemplo más típico, que ocurre en Joomla igual que en otros CMS, es el uso de determinadas extensiones que tienen un problema de seguridad o el uso de versiones antiguas de Joomla que no están actualizadas y que contienen agujeros de seguridad.

Pero hay casos todavía más básicos. Un sistema puede ser tremendamente seguro y sin embargo, escoger una clave corta o predecible lo puede dejar vulnerable. Aunque ojo, no solo debemos escoger claves complejas, sino realizar otras optimizaciones como cambiar los nombres a las tablas, tener cuidado con los permisos de los archivos o directorios, ofuscar las versiones del CMS o los nombres de los archivos que contienen código. Todas esas recomendaciones las revisaremos enseguida.

A veces se critica a Joomla diciendo que al ser software libre cualquiera puede saber los errores de seguridad que tiene, pero eso podría ser un crítica contra todas las herramientas de código abierto y sabemos que no es cierto. Existe una numerosa comunidad detrás que apenas aparece un agujero de seguridad publica nuevas versiones del software para solucionarlo. Nuevamente somos los desarrolladores los que debemos, concienzudamente, actualizar el CMS siempre que aparecen nuevas versiones estables seguras.

Durante el evento de seguridad en Joomla! #joomlaIO también se mencionó una estadística interesante. Solo el 5% de los errores de seguridad de Joomla! se dieron en el “core”, o sea, en la arquitectura básica del CMS. Esto quiere decir que el 95% de los agujeros de seguridad detectados en Joomla! pertenecen a otras piezas de software externas, con complementos como extensiones o plugins, temas, etc. En este sentido se puso énfasis en señalar que habitualmente los desarrolladores instalamostemas “piratas” que realmente tienen caballos de troya con scripts que roban contraseñas u otros datos sensibles. Por ello hay que tener siempre en cuenta descargar complementos o plantillas de fuentes seguras y desconfiar cuando un sitio web ofrece gratuitamente temas gratuitos que son de pago en otros sitios.

Nota: no es nuestra intención entrar en comparaciones sobre la seguridad con otros CMS populares, sean o no de código abierto. Solo decir que el 5% de agujeros en el core de Joomla! contrastan con el 20% de agujeros encontrados en el core de otro popular CMS.

Checklist de seguridad básica en Joomla!

A continuación encontraremos una serie de items fundamentales que tenemos que observar a la hora de implementar Joomla en un ambiente seguro. Es apenas un listado, que a buen seguro servirá de mucha utilidad, sin embargo, si se desea obtener mayores explicaciones, recordamos que está disponible el hangout donde el equipo de #joomlaIO ofreció muchos otros detalles, consejos y guías para implementación de estos items de seguridad.
Primeros pasos / Seguridad en el core de Joomla!:

• Descargar desde joomla.org o sitios de absoluta confianza
• Comprobar que estamos instalando la última versión estable de Joomla!
• Comprobar que no estamos utilizando el nombre de superusuario por defecto (admin)
• No establecer la contraseña de FTP (establecerla constituiría una vulneración de la seguridad)
• Activar el fichero .htaccess en servidores Linux (para ello debemos renombrar el fichero htacess.txt a .htaccess). Podemos ampliar la seguridad con docs.joomla.org Htaccess_examples_(security)
• Habilitar las URLs amigables para los motores de búsqueda (SEF)
• Comprobar que la duración de la sesión no excede de 15 minutos
• Eliminar plantillas que no sean necesarias
• Comprobar que los permisos de directorios están en 755 y los permisos de archivos en 644
• Utilizar un usuario de base de datos para la configuración de Joomla que no tenga acceso externo a la misma

Primeros pasos / Seguridad durante la instalación y mantenimiento de las extensiones Joomla!:

• Realizar un backup de la estructura FTP y la base de datos antes de instalar cualquier extensión. Utilizar Akeeba Backup / Admin Tools
• Descargar extensiones solo de sitios de confianza extensions.joomla.org
• Comprobar que las extensiones que instalamos son la última versión estable disponible
• Eliminar las extensiones que no vayan a ser utilizadas y no formen parte del CORE (conviene revisar manualmente que los directorios y archivos asociados a la extensión se han borrado correctamente)

Configuración del servidor / Directivas de PHP:

• Comprobar que register_globals está desactivada
• Comprobar que allow_url_fopen está desactivada
• Comprobar que allow_url_include está desactivada
• Comprobar que open_basedir está activada y las rutas asociadas (esta directiva limita los archivos que se pueden abrir por PHP al árbol de directorios especificado)
• Comprobar que están desactivadas show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
• Comprobar que safe_mode está desactivado

Configuración del servidor / Estructura de archivos:

• Comprobar que las carpetas del sitio están en 755
• Comprobar que los archivos del sitio están en 644
• Comprobar que no existen ficheros en la carpeta temporal /tmp

Configuración del servidor / Protección de archivos y carpetas críticas:
Para obtener una mejor protección del sitio web en Joomla, es conveniente sacar fuera de la estructura httpdocs el fichero configuration.php , para ello debemos modificar los siguientes archivos:

Motivo:Sacar fuera de la estructura httpdocs el fichero configuration.php y definir la ruta en la constante para que el fichero sea accesible por Joomla!

Ruta de los ficheros a modificar: /includes/defines.php y /administrator/includes/defines.php Línea de código a modificar: define(‘JPATH_CONFIGURATION’, JPATH_ROOT);

Extensiones recomendadas para mejorar la seguridad de Joomla

Hay varias extensiones que nos permiten añadir una capa extra de protección en Joomla! muchas de ellas son muy conocidas, algunas no tanto. Nombramos algunas de ellas con una pequeña descripción.

RSFirewall 
RSFirewall es una extensión que todos deberían usar. Correctamente configurada nos alertará de los intentos de intrusión en el sitio y nos permitirá realizar acciones como la denegación de IPs, o definir las ubicaciones desde la que se podrá acceder al backend, entre muchas otras funciones.

Admin Tools 
Una navaja suiza para la administración del sitio web en Joomla. Verificar y corregir los permisos de carpetas y directorios, proteger el acceso al panel de administración con una contraseña adicional, cambiar el prefijo de la base de datos o realizar su mantenimiento son algunas de las excelentes características de esta extensión. Además es del creador de Akeeba Backup, sin duda toda una garantía de la limpieza de su código y de sus posibilidades.

Akeeba Backup 
Un sitio web al que no asociamos ninguna política de backups es como un barco a la deriva. Es cuestión de tiempo que un fallo nos haga pasar un mal rato. Akeeba es una de esas extensiones que merece la pena pagar sin ningún género de dudas. La versión gratuita ya nos permite la realización de backups, pero es en la versión Pro donde encontramos todo el potencial de la extensión.

Aquí, Akeeba nos permitirá lanzar los backups directamente a diversos servicios de almacenamiento en nube, desvinculando la copia del servidor donde tenemos el sitio web. Creo recordar que su creador (Nicholas Dionysopoulos) en el manual de Akeeba nos indica en tono “jocoso” que una buena copia de seguridad es la que se realiza en una placa tectónica diferente (por si los terremotos).
Algo altamente recomendable es instalar o solicitar que nos instalen en el servidor la extensión MyCript.php, ya que es utilizada por akeeba para encriptar los paquetes de copia de seguridad aportando mayor seguridad.

Encrypt configuration 
A menos que utilicemos un certificado de seguridad SSL, un usuario que se registra en Joomla enviará su contraseña en texto plano a través de la red. Un usuario malintencionado podría aprovechar esta vulnerabilidad y obtener acceso al back-end.
Este plugin es una alternativa a SSL. Se utiliza RSA para cifrar las contraseñas o cualquier otra información que desees en los componentes.
Hay que tener la extensión bcmath. Funciona con nombre de señal, Login JTP Horizontal, PWC sesión, inicio de sesión en línea y módulos VTJ inicio de sesión. Para otras extensiones de Joomla, como Alpha Registro, Community Builder, Core Design Módulo sesión, Yoo sesión, YJ Módulo Login Pop puedes encontrar plugins en www.ratmilwebsolutions.com/downloads/encryption-plugins.html. No hay necesidad de configurar. Sólo tienes que instalar los plugins necesarios.

Conclusión

Creemos que después de estas notas se habrán despejado algunas dudas y mitos sobre la seguridad en Joomla!. Quizás los desarrolladores que critican el popular CMS no lo hacen con mala intención, pero sí por desinformación.

Aquellos profesionales que implementan Joomla son los mayores responsables de crear sistemas seguros, mediante la meticulosa revisión de diversas recomendaciones comentadas anteriormente y el uso de alguna que otra extensión de enorme utilidad. Esperamos que este documento haya resultado de utilidad.

fuente:desarrolloweb

La desarrolladora de software de seguridad, Avast, afirma que Internet Explorer no es seguro desde la versión 6 del navegador de Microsoft.

Y no solo eso, sino que además recomiendan encarecidamente el uso de Google Chrome como navegador para nuestro equipo siempre, debido a su “mayor velocidad y a su seguridad”, según explican en su blog oficial. La verdad es que razón no les falta, ya que desde la versión 6 en adelante todo han sido problemas de seguridad en el más famoso navegador de todos los tiempos.

Según el mencionado blog de Avast, creadora del famoso antivirus Avast Free, “desde la versión Internet Explorer 6 existe una vulnerabilidad a través de la cual un hacker con fines maliciosos puede tomar el control de nuestro PC“. Este problema ha sido resuelto en la versión 9 del navegador de Microsoft y por supuesto en la versión 10 tampoco aparece, pero aún así desde Avast recomiendan a los usuarios de Windows y de cualquier plataforma en general no utilizar bajo ningún concepto IE.

Además de esto, en la última parte de la nota aconsejan el uso de Google Chrome, navegador que está comiendo terreno al resto a pasos agigantados y acabando con el dominio anterior de Mozilla Firefox y sobre todo el cuasi-monopolio que tenía hace años Internet Explorer. Desde Avast afirman que Google Chrome es totalmente seguro y que, además de eso, es muchísimo más rápido que IE.

La verdad es que es cuanto menos sospechoso que afirmen esto cuando mientras instalas su antivirus, Avast Free, te dan la opción de instalar la barra de navegación de Google, lo cual indica que existe algún tipo de alianza o contrato entre los de Mountain View y Avast.

Veremos como afectan estas críticas a Internet Explorer 10, que hasta ahora no ha sido muy bien recibidocayendo por debajo incluso que Safari, aunque estas cifras siempre hay que cogerlas con pinzas. Personalmente no recomiendo IE, más que por la seguridad o la velocidad, porque pasa por completo de los estándares en la web.

Fuente: blog de informática

El próximo martes Microsoft lanzará las actualizaciones mensuales de seguridad. Así, lanzará siete actualizaciones de seguridad (cuatro han sido catalogadas como importantes y tres como críticas y entre ellas se incluye una considerada como crítica para Windows 8 y Windows RT), para “parchear” 12 vulnerabilidades que afectan a Windows (XP, 2003, 2008, Server 2012, Vista, Windows 7), a Office (versiones 2003 y 2007), SharePoint Server y al software de diseño de la compañía. Además, Microsoft también ha advertido que los hackers están utilizando certificados digitales que han sido obtenidos de una autoridad de certificación turca (CA). En respuesta a esta amenaza, Microsoft ha eliminado estos certificados digitales de la lista de certificados de confianza de Windows y ha instado a los usuarios a verificar que tienen instaladas las actualizaciones de junio de 2012, las cuales automatizan el proceso de certificación.

En las siete actualizaciones no se encuentra la solución a la vulnerabilidad de día-cero que afecta a varias versiones de Internet Explorer y que fue descubierta el pasado 7 de diciembre. Microsoft alertó de la misma el pasado sábado y lanzó un parche de seguridad de emergencia el miércoles. El agujero de seguridad afectaba a las versiones 6, 7 y 8 de Internet Explorer

En un mensaje de correo electrónico, Dustin Childs, director en el grupo de seguridad de Microsoft, ha asegurado que el agujero “sólo ha afectado a un limitado número de clientes”.

Fuente: csospain

Recientemente se ha detectado una vulnerabilidad de XML-RPC en WordPress, o “vulnerabilidad Pingback”, por la cual un atacante tendría 4 formas potenciales de provocar daños a través de xmlrpc.php, el archivo incluído en WordPress para dar soporte al protocolo XML-RPC (que se ocupa, por ejemplo, de los “pingbacks”).

Me refiero, a ese protocolo que viene activo por defecto en WordPress 3.5 y sin modo aparente de desactivarlo.

Pero, antes de nada …

¿Qué es la “vulnerabilidad Pingback”?

Según este artículo hay 4 maneras en que la API XML-RPC de WordPress (y en particular el método pingback.ping) puede ser atacada por  un hacker:

• Recolección interna: El atacante puede probar puertos específicos en la red interna objetivo. WordPress trata de resolver la URL de origen y devuelve distintos mensajes de error si la URL de origen existe (si existe el host) o no. Esto lo pueden usar los atacantes para tratar de acceder a hosts dentro de la red interna. De este modo, los atacantes podrían usar URLs como http://subversion/ o http://bugzilla/ o http://dev/ para ver si el host existe en la red interna.
• Escaneo de puertos: El atacante puede escanear hosts en la red interna. Si se detecta la URL original, WordPress tratará de conectar con el puerto específico en esa URL. Por tanto, si un atacante usa una URL del tipo http://subversion:22/ WordPress tratará de conectarse al host subversion en el puerto 22. Las respuestas serán diferentes si el puerto está cerrado o abierto, y precisamente por eso esta funcionalidad puede usarse para escanear hosts dentro de la red interna.
• Ataques DoS (denegación de servicio: El atacante puede hacer pingback desde una enorme cantidad de sitios, o pedírselo a blogueros compinches, o usar PCs zombies, para hacerte un ataque DoS
• Hackeo del router: El atacante puede reconfigurar un router interno de la red. Y es que WordPress soporta URLs con credenciales. O sea, que un atacante puede usar una URL del tipo http://admin:admin@192.168.0.1/changeDNS.asp?newDNS=aaaa para reconfigurar el router interno, ahí es nada.

Como ves no es para tomárselo a la ligera, la vulnerabilidad es de aupa.

Cómo protegerse de la “vulnerabilidad Pingback” de WordPress

Si no usas en absoluto el protocolo XML-RPC y quieres protegerte de cualquier vulnerabilidad de su API puedes bloquearlo con unas simples líneas en el archivo .htaccess.

Vamos a ver una técnica sencilla de .htaccess para protegernos frente a vulnerabilidades del archivo xmlrpc.php. Ahora bien, si usas pingbacks o cualquier otro servicio que use el protocolo XML-RPC con este truco dejará de funcionar:

Incluye esas líneas después de cualesquiera otras que estés usando en el archivo .htaccess de la carpeta raíz de tu web y te puedes olvidar de esta vulnerabilidad, pues desactivas completamente XML-RPC.

Si quieres, para asegurarte que funciona, trata de acceder al archivo xmlrpc.php desde tu navegador. Si funciona verás un mensaje del tipo “403 – Forbidden”.

Truco adicional: si quieres redirigir las peticiones al archivo xmlrpc.php hacia una página personalizada modifica la línea RedirectMatch así:

Por supuesto, tendrás que crear la página a tu gusto, y una copia de 404.php de tu tema sería una buena opción.

Método alternativo de .htaccess

Otro modo de denegar todo tipo de acceso al archivo xmlrpc.php desde .htaccess sería añadirle estas líneas:

Lo bueno de este método, menos radical, es que te permite acceder al archivo xmlrpc.php para direcciones IP específicas. Por ejemplo, si sabes las IPs de tu Blogger o MovableType puedes añadirlas a la lista blanca mediante una línea de “Allow” para cada una, de este modo:

Nota: Si usas alguno de estos métodos de .htaccess recuerda quitarlos una vez esta vulnerabilidad se solucione en una futura versión de WordPress. Mientras tanto ya estás tardando.

fuente:ayudawordpress

¿Ha perdido usted información de su correo electrónico o de su computadora debido a la acción de un virus?

¿El sistema operativo de su máquina se ha desinstalado sin causa aparente o el sitio web al que quiso acceder en algún momento mostró un diseño “raro”?

Tal vez ha llegado a un banco a realizar alguna acción monetaria o a cualquier otra entidad para determinada gestión y ha debido cambiar de planes porque “el servicio está interrumpido” o “estamos enfrentando dificultades con el sistema”.

Estas son solo algunas de las distintas modalidades en las que pueden cometerse delitos informáticos, los que pueden ocurrir en Cuba, al igual que en el resto del mundo, aunque a menor escala, sin que esto implique menos perjuicios, alertó el M.Sc. Gonzalo García Pierrat, director de Organización y Control de la Oficina de Seguridad de Redes Informáticas (OSRI), del Ministerio de la Informática y las Comunicaciones en conversación con Cubahora en el marco del XI Encuentro Internacional de Ciencias Penales 2012, que se celebra en el Palacio de Convenciones de La Habana hasta el próximo 4 de octubre.

“Los delitos en el ciberespacio pueden catalogarse en amenazas no estructuradas, como las que ofrecen los individuos y en amenazas estructuradas, cuando ocurre desde estados extranjeros y en cualquiera de los casos no pueden considerarse estrictamente locales, pues en ese escenario las fronteras son difusas y los conceptos de espacio y tiempo adquieren otras dimensiones.

“Puede darse el caso, por ejemplo, de que las autoridades suizas detecten la intrusión en el sistema de un banco y que determinen, tras investigaciones realizadas, que se originó el delito en Argentina y que luego las autoridades de este país suramericano descubran que realmente fue en Corea del Sur y que sea desde esta nación que se determine que se produjo en Canadá, donde se proceda a arrestar al autor del delito. Casos así han sucedido y gracias a la cooperación internacional y a la compatibilización de las leyes de los distintos países se ha procedido”, explicó García Pierrat.

En la comisión de este tipo de delito, al igual que sucede con los tradicionales, intervienen tres factores fundamentales, añadió. La motivación para violentar la seguridad por razones económicas, políticas, de venganza o frustración es uno de ellos; los medios que se emplean, no solo desde el punto de vista cognitivo sino también los relacionado con las herramientas a las que se puede acceder fácilmente a través de Internet y la oportunidad, por supuesto, que se ofrece cuando hay fallos en la seguridad.

“Los blancos potenciales son, por lo general, aplicaciones financieras y comerciales, cuentas de acceso a los servicios, documentos, bases de datos, configuraciones del sistema, correos electrónicos de los directivos, entre otros”.

Cuba no está exenta de los delitos informáticos, insiste García Pierrat. Es cierto que se tiene un desarrollo de la informática menor en comparación con el resto del mundo y que la dependencia de la tecnología en el funcionamiento de los servicios esenciales no está del todo generalizada, pero no por eso debe pensarse que no sucede.

“En enero del 2004, por ejemplo, se atacó el sitio web de la empresa comercial CUPET. Se desconfiguró la pantalla de inicio y se colocó un comunicado que afectaba además gráficamente la imagen de la entidad, firmado por Kuban Hacherz Group. Entre marzo de ese año y julio 2006 se propagó el programa maligno Libertad por el correo falso segurmaticadecuba@yahoo.com, que afectó redes informáticas del país.

“En enero del 2009 un ciudadano español denunció un robo de su cuenta y a partir de ahí se determinó que desde varios números de teléfono se accedía a redes de seis instituciones, con la consiguiente afectación de 17 organismos de la administración central del Estado. Al comienzo del presente año se atacó a la red corporativa de una empresa nacional a través de redes inalámbricas que se conectaban a diferentes hoteles y más recientemente, entre mayo y junio último, se penetró ilegalmente a las bases de datos y a la casa financiera de una corporación, con lo que se obtuvo información sensible para su funcionamiento”, detalló el especialista.

—¿Cómo es el enfrentamiento a este tipo de delitos?

—Muy complejo, pues aunque en el país se cuenta con la tecnología necesaria para “seguirle” la pista a los comisores del delito y cada vez esta se perfecciona más, en el enfrentamiento intervienen muchos factores.  Por ejemplo, el anonimato de los actores del delito dificulta mucho el enfrentamiento, sobre todo porque transcurre el tiempo entre su ejecución y su detección. No hay límites, puede producirse de un país a otro; la velocidad del desarrollo es variable y el costo de las herramientas es muy bajo, pues hay que tener en cuenta que quienes realizan estas acciones no son “genios” como se creía antes.

“Hoy cualquier persona con ciertas habilidades y capacidades puede hacerlo, sobre todo porque en Internet pueden obtenerse con facilidad las herramientas y la manera de usarlas. Generalmente, incluso en nuestro país, son jóvenes, mayoritariamente hombres, con un nivel educacional elevado aunque no necesariamente con un grado académico superior. Y no podemos perder de vista que esos hackers o crackers, como se les identifica, pueden ser insider, es decir, pueden encontrarse en el interior de la entidad afectada, como ha sucedido en más del 70 por ciento de los casoss.

—Desde el punto de vista penal, ¿cómo se asume este tipo de delitos?

 —Lo primero es que hay que entender el delito informático y prepararse para ello. Se necesita además de que se unifiquen esfuerzos y que se asuma el enfrentamiento de manera dual, en la que los profesionales de la ley y los especialistas en informática trabajen juntos.

“Los primeros necesitan saber mucho de ese “mundo” y además de conocer los métodos tradicionales de investigación del delito, conocer cómo recoger y preservar las evidencias digitales, así como aspectos técnicos relacionados con la comisión de estos delitos. Los informáticos, por su parte, sí conocen las computadoras, las redes y su funcionamiento, pero carecen de la preparación en relación con la investigación legal y sus cuestiones, por lo que el trabajo en conjunto es lo ideal para obtener resultados exitosos en el enfrentamiento al delito.

“Lamentablemente, y a pesar de que el país ha avanzado notablemente en la seguridad informática, es una debilidad del Sistema Judicial Cubano que  no estén tipificados los delitos informáticos en nuestro código penal, como sí sucede en otros países. Desde hace alrededor de una década se presenta y discute un proyecto relacionado con esto para incluir modificaciones en el código vigente pero mientras se aprueba, los daños continúan, principalmente en organismos de la administración central del Estado, más vulnerables a esto”.

Es imprescindible entonces la redacción de leyes claras que se puedan hacer cumplir cuando sea necesario enfrentar delitos informáticos no contemplados en la legislación actual y propiciar la concienciación y exigencia de la preparación de todos los que se relacionan con este tipo de delito o pueden ser víctimas de él, porque lo que sí está claro es que, teniendo en cuenta sus perjuicios, no pueden quedar fuera de la ley, concluyó García Pierrat.

Mantenerse informado vs. sentido común

No podemos proteger lo desconocido o luchar contra lo que ni imaginamos. Debemos saber la “mecánica básica” del sistema operativo, y estar al tanto de las últimas tendencias en el malware. Aconsejar “sentido común” es muy sensato, pero si probamos a preguntarle a un usuario cualquiera qué significa usar un sistema con “sentido común”, es más que probable que no tenga muy claro qué hacer.

Quizás, como mucho, mencione que sabe que no tiene que dar sus datos a cualquier página o que no debe creer todos los correos que le llegan. Pero eso cubre un minúsculo espectro de todo lo que está ahí fuera. Incluso para los que saben qué significa el sentido común en la red, quizás lo sobrevaloren.

Al insistir en el sentido común como el arma más efectiva contra todo mal en la red, parece que basta con no ejecutar los adjuntos del email para mantenerse a salvo. El sentido común, aunque imprescindible, no te va a proteger cuando un atacante cuele en la publicidad de una página web de confianza, un exploit que aproveche un fallo en Flash del navegador para el que todavía no existe parche. No has hecho nada extraño, has aplicado el sentido común de manera impecable… pero acabarás infectado.

A Internet no se llega con el mismo concepto de sentido común que se presupone en la vida real. En la vida real, el sentido común es un resultado de todas esas experiencias vitales que se ha afinado durante el desarrollo de muchos “experimentos” propios y ajenos ocurridos durante buena parte de nuestra juventud y adolescencia. Pero cuando un usuario accede a Internet por primera vez o lo hace ocasionalmente, no tiene por qué tener la más mínima experiencia en la red, y por tanto apelar solo a su sentido común es sano, pero quizás prematuro e incompleto.

Mantenerse informado sobre las amenazas y las nuevas protecciones, sin embargo, es invertir en “ganar y mejorar” el sentido común con el tiempo, conocer en qué momentos es recomendable aplicar más cuidado con ciertas situaciones (cuando aparecen nuevas vulnerabilidades o tipos de estafa renovados)…. y lo que es más importante: saber las limitaciones de cada medida que se toma.

Cortafuegos vs. todo lo demás

Es habitual ver largas listas de anti-todo que se pueden instalar en el sistema para “estar protegido”. La mayoría, sin embargo, suelen apuntar al mismo eslabón de la cadena: la detección o detección temprana (que sigue sin ser “prevención” real). Pero es mucho más interesante conocer para qué sirve cada programa y sobre todo, las fases más comunes de una infección.

Para cubrir esas fases es necesario (esencial) fortificar el sistema operativo (que para eso viene con decenas de interesantes protecciones… la mayoría desactivados por defecto) y aplicar prevención real contra todas las fases de una infección: actualización de los programas (para eliminar vulnerabilidades), antiexploits (para evitar que, si no hay parche, esas vulnerabilidades sean aprovechadas), antipayloads (para evitar que, incluso si los exploits tienen éxito, instalen el malware) y sandboxes (para evitar que si incluso el antipayload fracasa, el malware dañe el sistema). Así se pueden cubrir muchas de las “capas” previas al antivirus.

Con respecto al cortafuegos, en realidad no juega un papel decisivo contra el contra el malware actual en entornos domésticos (porque da por hecho que está instalado y lo evita). Podría servir de algo el firewall saliente… pero no se inyecta en los procesos habituales. Y aun así, seguiría siendo un sistema que intenta limitar la actividad del malware, no la infección en sí. Por último, manejar un cortafuegos saliente, para el usuario medio, es extremadamente tedioso.

Antivirus vs. malware

Finalmente, si absolutamente todo lo anterior fallase, sería interesante que el antivirus (o el anti-todo de turno) pasara a la acción y reconociera el bicho que se cuela en el sistema. Pero es el último que debe entrar en juego, porque el antivirus es el medicamento contra la enfermedad que ya, al menos, ha entrado en contacto con tu organismo. Pero si ha llegado hasta ahí, el antivirus es una tecnología a la que bien puedes encomendarte para detectarlo y eliminarlo.

Dejar de lado todas las fases anteriores significa repartir toda la responsabilidad de mantener un sistema a salvo entre muy pocos actores a los que se sobrecarga (y quizás, sobrevalora) mientras otros factores y herramientas que pueden ser mucho más eficaces, son directamente ignorados.

Fuente: http://unaaldia.hispasec.com/2012/12/el-sentido-comun-contra-el-malware-y-ii.html

OWASP “The Open Web Application Security Project” a determinado una lista de top 10 ataques que ocurren en la web: OWASP Top 10 2010 – Spanish PDF

En esta serie de entradas, conoceremos de manera simple, como funcionan y como podemos protegernos de este tipo de ataques.

Como regla principal siempre debemos tener en cuenta nunca confiar en los datos que interaccionan con nuestros servicios.

INYECCION SQL

Es un método de infiltración de código intruso que se vale de una vulnerabilidad informatica presente en una aplicación en el nivel de validación de las entradas para realizar consultas a una base de datos.

El origen de la vulnerabilidad radica en el incorrecto chequeo y/o filtrado de las variables utilizadas en un programa que contiene, o bien genera, código SQL. Es, de hecho, un error de una clase más general de vulnerabilidades que puede ocurrir en cualquier lenguaje de programación o script que esté embebido dentro de otro.

Se conoce como Inyección SQL, indistintamente, al tipo de vulnerabilidad, al método de infiltración, al hecho de incrustar código SQL intruso y a la porción de código incrustado.

Para ejemplificarlo hemos creado un ambiente de ingreso de usuarios:

<?php

// Conección a la base de datos usando la libreria "mysql".
$config = array(
    'host'      =>  'localhost',
    'user'      =>  'root',
    'password'  =>  'root',
    'dbname'    =>  'usuarios'
);
mysql_connect($config['host'],$config['user'],$config['password']);
mysql_select_db($config['dbname']);

//Si el usuario ingresó datos en los campos se realiza la consulta.
if(isset($_POST['usuario'], $_POST['password'])){
    $usuario    = $_POST['usuario'];
    $password   = md5($_POST['password']);

    //Mostramos como se a construido la consulta con los datos proporcionados por el usuario.
    echo "SELECT COUNT(`id`) FROM `usuarios` WHERE `usuario` = '{$usuario}' AND `password` = '{$password}' ";

    $query      = mysql_query("SELECT COUNT(`id`) FROM `usuarios` WHERE `usuario` = '{$usuario}' AND `password` = '{$password}' ");
    $resultado  = mysql_result($query, 0);
}
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns="http://www.w3.org/1999/html">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Seguridad PHP: Injeccion SQL</title>
</head>
<body>
<p>

<?php
//Si el ingreso es correcto se muestra el mensaje "Bienvenido!".
if (isset($resultado)) {
    if ($resultado == 0) {
        echo 'Password incorrecta';
    }
    else {
        echo 'Bienvenido!';
    }
}
?>
<!--Formulario, paso de datos por metodo POST-->
</p>
<p>
    <form action="" method="post">
    <p>
        <label>Usuario: </label>
        <input type="name" name="usuario" id="usuario">
    </p>
    <p>
        <label>Password: </label>
        <input type="password" name="password" id="password">
    </p>
    <p>
        <input type="submit" value="acceder">
    </p>
    </form>
</p>
</body>
</html>

En nuestra base de datos tenemos un usuario llamado “administrador” con “password” como contraseña. Nos muestra el mensaje de “Bienvenido!”, pues el acceso es correcto.

Podemos observar como esta construida la consulta:

SELECT COUNT(`id`) FROM `usuarios` WHERE `usuario` = 'administrador' AND `password` = '5f4dcc3b5aa765d61d8327deb882cf99'

ATAQUE

Para realizar la injección probemos escribiendo como usuario: “administrador’ – “ y como contraseña: “cualquiera”:

En este caso tambien nos permite el acceso. Analicemos la consulta:

SELECT COUNT(`id`) FROM `usuarios` WHERE `usuario` = 'administrador' -- ' AND `password` = '32d064da8114739ce7ba481b78a8f868'

Despues de “administrador” estamos delimitando el campo de usuario con una comilla simple seguida por dos guiones. En lenguaje SQL los dos guiones es la etiqueta usada para comentar, por lo tanto el resto de nuestra consulta no es considerada.De esta manera, cualquier usuario es capaz de inyectar código a partir de nuestra consulta. Veamos algunas medidas que podemos tomar para hacer nuestro script mas seguro.

CONTRAMEDIDA

Para asegurarnos que los datos ingresados por el usuario sean adecuados, debemos validar o escapar (agregar una diagonal invertida) para remover el significado de los caracteres de control.

La libreria “mysql” nos proporciona para este caso la función: “mysql_real_escape_string()” http://php.net/manual/en/function.mysql-real-escape-string.php

Usemosla en el ingreso de usuario:

if(isset($_POST['usuario'], $_POST['password'])){
    $usuario    = mysql_real_escape_string($_POST['usuario']);
    $password   = md5($_POST['password']);

Por lo tanto, la inyeccion por el uso de caracteres de control ya no es posible.

A su vez PHP cuenta con la función para el escape caracteres: “addslashes()” http://php.net/manual/en/function.addslashes.php

Cabe destacar que PHP a partir de su versión 5.4 cuenta con la directiva: “magic_quotes_gpc” activa, que realiza el escape de caracteres en los datos ingresados por métodos GET, POST y COOKIE. El uso de las funciones en conjunto resulta en un doble escape de caracteres.

La función get_magic_quotes() http://www.php.net/manual/en/function.get-magic-quotes-gpc.php comprueba si la directiva se encuentra activa.

fuente:codelan.com

Nos avisa el bueno de Andrew Nacin de un grave error en sitios que han actualizado a WordPress 3.5 que, aunque no afecta a todos, es un potencial peligro de inyecciones SQL, así que no hay que tomarlo con ligereza.

El asunto es que hay usuarios que, debido a plugins o temas, están recibiendo un aviso bastante feo, este:

“PHP Warning: Missing argument 2 for wpdb::prepare().”

Pues bien, como se ha apuntado en los foros de soporte, esto es debido a que algo o alguien (un plugin) está usando incorrectamente la función $wpdb->prepare. Es un aviso de algo gordo, porque también indica un uso indebido de prepare(), y eso es un riesgo de seguridad.

No es un error de WordPress, más bien al revés, pues el equipo de desarrollo ha preferido que estos errores se muestren a que tengamos un agujero de seguridad por un plugin y no nos enteremos, así que en realidad está hecho por nuestro bien, mal que le pese a algún desarrollador que ahora tendrá que revisar su código.

Un ejemplo de esto sería esta línea de código en un plugin:

$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->comments SET comment_parent=$parentID WHERE comment_ID=$commentID;" ) );

El problema es que no se ha usado la declaración de prepare correctamente, pues incluye las variables $parentID y $commentID directamente en el SQL. Para hacerlo bien se tendrían que usar “placeholders” y luego ya incluir las variables.

El ejemplo anterior es un código peligroso, ya que conlleva la posibilidad de que abra la puerta a un exploit de inyección SQL, o sea, el primer paso para hackear tu sitio web.

El código anterior se puede solucionar de este modo:

$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->comments SET comment_parent=%d WHERE comment_ID=%d;", $parentID, $commentID ) );

Como ambos se supone que son integradores, se han reemplazado las variables en la declaración con el %d, y luego se ponen las variables al final de la declaración prepare(). Así es como se supone que se debe usar prepare. Si fueran cadenas entonces usas %s.

O sea, que si quieres arreglar momentáneamente el error tienes que encontrar la línea de código con el problema y corregirla. Con eso eliminas el exploit y el mensaje de aviso tan feo.

Por supuesto, lo anterior es un apaño temporal que solo te sirve a ti, no a toda la comunidad ni a WordPress en su conjunto, lo que hay que hacer en realidad si ves este error es lo siguiente:

1. Desactivar todos los plugins
2. Ir activando uno a uno hasta detectar el que provoca el error
3. Avisar al desarrollador indicándole el enlace del artículo de Andrew Nacin para que lo arregle y suba una versión segura

Lo mismo también puede pasar con un tema WordPress así que si tras hacer lo anterior sigue el error cambia de tema para comprobarlo.

La peor solución es ocultar los errores, aunque puedes hacerlo simplemente añadiendo estas líneas al fichero wp-config.php:

ini_set( 'display_errors', false );
error_reporting( 0 );

Un ejemplo de este error, lamentablemente, es el plugin Akismet, pues aunque acaban de actualizalo ahora mismo y soluciona el fallo deberían haber estado más pendientes, por la estrecha relación de Automattic con el desarrollo de WordPress.

fuente:<a href="http://ayudawordpress.com/wordpress-3-5-peligro-de-inyeccion-sql-si-ves-php-warning-missing-argument-2-for-wpdbprepare/" title="WordPress 3.5: peligro de inyección SQL si ves “PHP Warning: Missing argument 2 for wpdb::prepare()”" target="_blank">desarrolloweb</a>

twitter

Un fallo de seguridad pone en riesgo a determinados usuarios del popular servicio de microblogging.

Tras detectar un problema de seguridad durante el pasado mes de agosto y comunicarlo a los responsables de Twitter, el experto en la materia, Jonathan Rudenberg, ha dado a conocer la existencia de una vulnerabilidad en el servicio de SMS habilitado en la red de microblogging.

El problema que solo afecta a aquellos usuarios que tienen activado el servicio de envío de tweets a través de SMS permite que cualquier intruso pueda llegar a suplantar la identidad del legitmo propietario de una cuenta.

Esta vulnerabilidad no solo deja al atacante twittear en nombre del suplantado sino incluso cambiar las opciones de configuración de la cuenta por lo que podría ser bastante comprometido ser victima de uno de estos ataques.

Rudenberg ha asegurado que Facebook también sufría la misma vulnerabilidad, pero después de llamar la atención sobre el bug, el equipo de seguridad de la red social se puso a trabajar hasta resolver el el problema el pasado mes de noviembre.

En el caso de Twitter, no ha sido hasta hace poco cuando su equipo de ingenieros ha reconocido el problema, señalando que la mayor preocupación se centra en que si un usuario tiene una cuenta configurada para recibir actualizaciones a través de SMS, y un atacante conoce el número que el usuario del teléfono, éste podría suplantar la identidad del usuario legitmo para realizar publicaciones en el servicio de 140 caracteres de forma remota.

Hasta que sea parcheada la vulnerabilidad, la solución más simple es la de deshabilitar el servicio de envío de tweets a través de SMS. También cabe la posibilidad de activar un nivel superior de seguridad mayor en el que al usar el servicio se nos pida adjuntar un código de seguridad que certifique el tweet, no obstante esta opción no está disponible en todos los países.

fuente:desarrolloweb

Mi consejo para evita este tipo de ataques, cada vez mas frecuentes, sería seguir estos pasos:

1. Cambia el prefijo de la base de datos
2. Cambia el nombre de usuario admin por otro distinto y elige una contraseña segura.
3. Añade las siguientes líneas al archivo .htaccess de la carpeta de tu instalación de WordPress:

# proteger contra inyecciones sql
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

4. <a title="seguridad wordpress" href="http://ayudawordpress.com/proteger-wordpress-contra-malware/" target="_blank">Instala un plugin de seguridad</a> para comprobar regularmente WordPress.

fuente:ayudawordpress

Los foros en internet que utilizan los hackers últimamente se centran en tutoriales y formación sobre cómo realizar ese tipo de acciones delictivas.

Además, el estudio desvela que menos del cinco por ciento del presupuesto en Tecnología de las empresas  se dedica a paliar los ataques en los centros de datos.

Amichai Shulman, CTO de Imperva, asegura que gracias a la información que comparten los hackers en esos foros, pueden conocer en que aspectos centran sus esfuerzos los cibercriminales.

Según parece, las empresas y organizaciones no tienen en cuenta el peligro que entrañan los ataques de inyección de código SQL y los hackers se están aprovechando de ello.

El informe de Imperva también señala que el 19 por ciento de los ataques de los cibercriminales se realizan a través de métodos como la denegación de servicio (DDoS) o las citadas acciones con código SQL.

Por otro lado, se destaca que en los foros de hackers se suele hablar principalmente de acciones en Facebook (39 por ciento) o Twitter (37 por ciento).

En ese sentido, el informe de Imperva asegura que hay un mercado negro en el que se comercia con seguidores, los populares “Me gusta” de Facebook o las recomendaciones positivas.

Por último, señalar que el 28 por ciento de los posts localizados en los foros de hackers trataban sobre temas de formación para novatos.

fuente: Theinquirer

Para usuarios de PC, desde el menú de Firefox, selecciona Opciones, haz clic en la pestaña Seguridad (cuyo ícono es un candado). Aquí tienes algunos de los ajustes que puedes elegir para incrementar (o disminuir) tu seguridad en Firefox y te explicamos cómo pueden protegerte:

• dvertir cuando algún sitio intente instalar complementos: Firefox siempre te pedirá confirmación a la hora de instalar complementos (esos pequeños programas que mejoran tu experiencia con Firefox, la lista completa la tienes aquí). Para evitar avisos de instalación no solicitados, Firefox te avisa cuando una página intenta instalar un complemento y lo bloquea. Puedes añadir excepciones a esta regla para los sitios en los que confíes: tan solo haz clic en Excepciones, escribe el nombre de la página y haz clic de nuevo en Permitir.
• Bloquear sitios reportados como atacantes: Selecciona esta opción si quieres que Firefox verifique si el sitio web que vas a visitar puede ser un intento de interferir con las funciones normales de tu equipo o de enviar tu información personal a partes no autorizadas a través de Internet (la ausencia de un aviso no garantiza que la página sea de confianza).
• Bloquear sitios reportados como falsificados: Elige esta opción si quieres que Firefox compruebe activamente si el sitio web que estás visitando puede ser un intento de engaño para que proveas información personal (también llamado phishing). (La ausencia de un aviso no garantiza que la página sea de confianza. Para más información, mira Cómo funciona la protección contra phishing y malware en Firefox).
• Recordar las contraseñas de los sitios: Firefox puede guardar de manera segura las contraseñas que introduces en formularios en línea haciendo más fácil el acceso a los sitios web. No selecciones este recuadro si no quieres que Firefox recuerde tus contraseñas (por ejemplo, si estás en un equipo público). Pero incluso con la opción activada, se te preguntará si quieres guardar las contraseñas de una página cuando la visites por primera vez de todos modos. Si eliges Nunca para esta página, ésta será añadida a una lista de excepciones. Utiliza Excepciones para acceder a esta lista.
• Usar una contraseña maestra: Firefox puede proteger información confidencial como contraseñas guardadas y certificados, cifrándolos a través de una contraseña maestra. Si creas una contraseña maestra, cada vez que inicies Firefox, el navegador te pedirá que introduzcas la contraseña la primera vez que necesite acceder a un certificado o contraseña guardada. Puedes establecer, cambiar o eliminar la contraseña maestra seleccionando o desmarcando esta preferencia, o bien haciendo clic en el botón de Cambiar contraseña maestra. Si ya hay establecida una contraseña maestra, tendrás que introducirla para modificarla o suprimirla.

¡Y esto es tan solo lo que tienes disponible en el menú de Ajustes de seguridad de Firefox! Firefox tiene que ver y está estrechamente relacionado con defender tu privacidad y seguridad en Internet con características como Navegación privada y No quiero ser rastreado, entre otras.

fuente:firefoxmania

Igual no habías caído pero en realidad es bastante fácil meter comentarios en un sitio WordPress usando credenciales de un usuario registrado y, de este modo, saltarte los filtros de moderación de comentarios.

Y es que WordPress realiza la comprobación mediante el nombre de usuario (visible siempre) y el email del usuario registrado (más complicado de conseguir pero no imposible), así que si alguien rellena el formulario de comentarios, ya sea directamente o mediante scripts, con los datos de un usuario registrado se saltaría este control y sus comentarios aparecerían directamente, sin moderación previa. Miedito ¿no?

El resultado puede ser variado, dependiendo de las intenciones del impostor, pudiendo ser desde una simple broma haciéndose pasar por un usuario habitual a meter spam a kilos o incluso meterte en problemas legales realizando amenazas o insultos, así que no es cosa para tomársela a la ligera.

Son muchas las maneras en que personas malintencionadas pueden “adivinar” emails de usuarios registrados, ya sabes, hay listas por ahí, coincidencia de perfiles, gravatar, etc. En serio, échate a temblar.

Afortunadamente acaba de salir un plugin que nos quitará más de un quebradero de cabeza. Descargar desde HaciendoWeb impostercide (10) no tiene ajustes, simplemente lo instalas y lo activas. A partir de este momento, cuando alguien trate de hacerse pasar por un usuario registrado rellenando sus datos en el formulario de comentarios recibirá un bonito mensaje de “posible impostor“, no permitiendo la publicación del comentario.

En el mismo mensaje se anima al usuario a que, si quiere publicar un comentario con esas credenciales acceda normalmente antes con su usuario y contraseña. Muy efectivo y efectista, además de sencillo de usar.

La única pega es que si quieres personalizar el mensaje tienes que editar el plugin directamente, al no tener página de ajustes. Por lo demás, en serio, merece la pena.

fuente : ayudawordpress

El agujero de seguridad es capaz de permitir que un atacante con los debidos conocimientos acceda al historial de URL visitadas de un usuario a través del ataque desde un sitio malicioso. Por el momento no se conocen casos que indiquen que esta vulnerabilidad ha sido explotada.

Consecuencia de este último problema Firefox ha sido retirado de la página de descargas y los usuarios no serán actualizados a la nueva versión hasta que esta sea solucionada la vulnerabilidad.

Como medida de precaución Mozilla ha sugerido a los usuarios que hayan descargado Firefox 16 que lleven a cabo un downgrade a la versión 15.0.1 siguiendo los pasos indicados en  www.mozilla.org.

Hay quien responsabiliza de este último incidente de seguridad a la política de continuos lanzamientos que Mozilla ha venido usando durante los últimos tiempo en un intento por competir contra Google Chrome y que aparentemente concede más importancia a cuestiones relacionadas con el marketing que a estabilidad del código.

Fuente: DesarrolloWeb

Como señalan en MuyLinux, los desarrolladores de Mozilla llevan tiempo trabajando en un sistema de inicio de sesión -antes conocido como BrowserID- que solo haga necesaria la introducción del correo electrónico, y tras varios meses de desarrollo acaban de publicar la primera versión beta de Mozilla Persona.

Este sistema evita el tener que usar contraseñas en todo tipo de sitios y servicios web, y según los ingenieros de Mozilla se trata de una plataforma segura y fácil de usar que por fin ha pasado de la fase experimental a esta primera versión beta, mucho más probada y estable.

Mozilla Persona se puede usar para proporcionar un servicio de autenticación y de inicio de sessión seguro, que funciona en todos los principales navegadores para PCs, portátiles, tablets y smartphones, además de tratarse de un proyecto Open Source.

En esta nueva versión se ha desarrollado una nueva API, se ha mejorado la primera experiencia de usuario, y se ha añadido soporte para mostrar el nombre y logo de nuestra empresa o servicio en la página de login, entre otras novedades.

La puesta en marcha de Persona es relativamente sencilla, y veremos si esta alternativa que toma ideas de OpenID pero las simplifica en gran medida puede triunfar y simplificar el acceso seguro a todo tipo de servicios web.

Podéis obtener más información en la página oficial del proyecto, en el anuncio oficial y en la documentación oficial de Mozilla Persona, desde la cual podréis consultar como implantar e instalar esta solución tanto en el cliente como en el servidor donde se hospeda el servicio al que queréis acceder mediante Persona.

Fuente: MuyComputer