Seguridad

Mac, Seguridad

Un fallo enorme en macOS High Sierra permite acceder como administrador sin contraseña

/

Ayer un usuario de Twitter mandó un mensaje a Apple indicando que había encontrado un GRAN fallo de seguridad en la última versión del sistema operativo, High Sierra. El fallo hace que cualquiera, con unos pocos clics, pueda ser administrador de tu equipo (y por lo tanto hacer todos los cambios que quiera) de manera muy sencilla. Lo hemos probado y funciona. 🤣🍎👾💀☠️ pic.twitter.com/4TBh5NetIS — Patrick Wardle (@patrickwardle) November 28, 2017 Apple lo ha confirmado y mandado lo siguiente: “We are working on a software update to address this issue. In the meantime, setting a root password prevents unauthorized access to your Mac. To enable the Root User and set a password, please follow the instructions here. If a Root User is already enabled, to ensure a blank password is not set, please follow the instructions from the ‘Change the root password’ section.” Esto afecta a todos los usuarios que tengan este sistema operativo. El fallo es muy sencillo de aprovechar (en el vídeo del post encima de estas líneas se muestra). Entras en Preferencias del Sistema > Usuarios y Grupos y ahí entra con el usuario root  (es el administrador de los sistemas Unix/Linux) y sin contraseña. Tras unos pocos intentos te permite acceso. Solución: La solución que recomendamos los técnicos, y Apple, es ponerle una contraseña a este usuario root. Para ello sigue las instrucciones de este artículo: https://support.apple.com/es-es/HT204012 donde pone Cambiar la contraseña root. Nota: no deshabiliteis el usuario root como han hecho algunos porque no soluciona el problema. Lo tienes explicado en este vídeo también: https://twitter.com/reneritchie/status/935627307565355014?ref_src=twsrc%5Etfw No está claro si Apple va a mandar una actualización pero con el fallo de seguridad tan enorme (de los más sencillos y evidentes que hemos visto últimamente) que es, deberían. Y para acabar, para los frikis, os dejo una imagen de un twittero que nos ha encantado:  

Noticias Informáticas, Seguridad

La policía desactivado los certificados de los DNIe emitidos a partir del 2015 por fallo de seguridad

/

El DNIe ha sido una de esas grandes ideas que nunca llegó a salir bien. En teoría facilita mucho la vida poder tener un certificado en algo que llevas como tu DNI, y que te permita realizar operaciones online certificadas. Sin embargo, en la práctica no es nada cómodo. Muchos no sabían esta funcionalidad, y cuando se enteraron ya había caducado el certificado (porque caduca). Los que consiguieron que funcionara se quejan de fallos continuos en su uso, que el chip se estropea etc. A esto se une la noticia de hace unos días: la Policía Nacional se ha visto forzada a desactivar todos los certificados de los DNIe expedidos a partir del 2015. Aunque te lo hayas sacado hace poco, tu certificado ya no vale. La noticia saltó a partir de un estudio publicado por una Universidad de la República Checa, y no ha afectado sólo a los DNIe españoles. En ese estudio se informaba de una vulnerabilidad de seguridad (antigua pero descubierta ahora) en dichos certificados. “La vulnerabilidad, conocida como ROCA, consiste en que la parte pública contiene información suficiente para que, mediante un proceso conocido como factorización, se pueda descifrar el código privado” Como la policía no tiene los mecanismos técnicos implementados para resolverlo, han optado por desactivar todos estos certificados hasta que activen la solución. De manera preventiva. Una vez tengan la solución, los usuarios serán informados y tendrán que renovar los certificados en las oficinas de documentación (sin tener que renovar el DNI). Los DNIe afectos son los de numeración (debajo de la fecha de nacimiento) posteriores a ASG160.000. Nota: los DNI seguirán siendo válidos como identificació clásica. Esto sólo afecta a la certificación electrónica. Sinceramente, me parece una solución más fiable usar el certificado digital de la FMNT en tu ordenador o la Cl@ve PIN.    

Noticias Informáticas, Seguridad, Soporte, Trucos

Control de acceso a carpetas. Gran opción de Windows para proteger contra ransomware.

/

Si leéis este blog de vez en cuando (deberíais, es muy recomendable :-D), o estáis minimamente al día en el mundo informático, ya sabéis que los virus ransomware son una de las grandes amenazas a empresas y particulares de los últimos años. En su nueva actualización para Windows 10, Fall Creators Update, Microsoft ha incluido una funcionalidad muy útil para evitar estos virus: el Control de acceso a carpetas. Hoy os enseñamos a activarlo y manejarlo. Nota: los que tenéis otro antivirus instalado (tipo Avast, Avira etc) no podréis usar esta funcionalidad, aparecerá desactivada en gris. Esto es porque requiere ser el único antivirus del sistema. En próximos artículos os daremos alternativas similares con otro tipo de sofware.      

Seguridad, Soporte, Trucos

Windows Smartscreen impidió el inicio de una aplicación desconocida. Solución

/

Hoy, dando soporte a un cliente, al iniciar una aplicación inocua (si se puede llamar inocua a iTunes), salió un mensaje que decía: Windows Protegió Su PC. Windows Smartscreen impidió el inicio de una aplicación desconocida. Si ejecuta esta aplicación, podría poner en riesgo su PC. Y un botón que dice No Ejecutar. Os dejamos la solución. Lo primero es decir que justo debajo del mensaje aparece  Más información.  Si le damos ahí nos aparecerá otra opción que dice Ejecutar de todos modos. Esto nos permite ejecutarlo si estamos seguros que es de confianza. Esta es la primera solución. La otra opción es desactivar la causa que provoca estas restricciones. Es una medida de seguridad de Microsoft llamada SmartScreen que protege de páginas web que puedan haber estado infectadas. En clientes que no saben mucho cada medida de seguridad es otra capa más de protección. Pero si sabes lo que haces puedes optar por desactivarla (y que el filtro seas tú). Para desactivar SmartScreen ve al  Centro de seguridad de Windows Defender (puedes buscarlo en la barra de búsqueda). Elegimos la penúltima opción (la que parece una caja)  Control de aplicaciones y navegador. Aquí tenemos Smartscreen para aplicaciones y archivos, para Microsoft Edge y para Tienda. Escoge el que quieres desactivar. Con eso tienes solucionado el tema del bloqueo. Nuestra recomendación es dejar SmartScreen activado y tomar la decisión si sale algún aviso (que no debería). Desactivándolo quitamos una capa de seguridad y hacemos nuestro ordenador más vulnerable. Más aún si no somos usuarios avanzados.    

Seguridad, Sistemas, Soporte, Trucos

SyncBackFree: una excelente solución de copia de seguridad y sincronización

/

Hace tiempo escribimos un artículo sobre posibles soluciones de copia de seguridad una vez que Cobian ya se había abandonado. Esas soluciones siguen siendo muy válidas, pero hoy queremos compartir otra que nos ha encantado. Por cierto,¿ tenemos que recalcar lo importante de tener una copia de seguridad automática de tus datos?  SyncBackFree es un producto gratuito que lleva ya mucho tiempo (desde el 2004). Y va a seguir siendo gratuito por lo que parece. El programa no es de los más simples para configurar a priori, aunque tiene un modo usuario y uno avanzado. Hay que crear un perfil de copia, decir el modo (a elegir entre copia, sincronización bidireccional y espejo) y después podemos escoger entre muchísimas opciones. Si queremos algo simple sólo tenemos que decir origen, destino y frecuencia. Pero si lo queremos más complicado podemos hacer muchísimos filtros (para no respaldar ciertos ficheros o directorios), programar comportamiento automáticos en caso de conflictos, avisos por correo, acciones a realizar antes o después de la copia, apagado del ordenador tras la copia, compresión, codificación…. y muchísimo más. Obviamente la copia puede ser en unidades locales, unidades de red, FTP, la nube ….donde queramos. Como veis una solución gratuita y muy potente. Si no queréis complicaros también tenéis una versión Lite para usuarios domésticos. Os recomendamos a todos tener copia automática (al menos una). No cuesta nada poner un programa como estos y hacer copia o espejo en uno o dos discos duros conectados (cuestan poco ahora) o en un disco duro y la nube. No hay excusa para perder datos con soluciones como esta.

Información Tecnica, Internet, Noticias Informáticas, Seguridad

KRACK: el ataque que ha vuelto todas las claves wifi actuales (WPA2) inservibles

/

Hace unos días un investigador belga, Mathy Vanhoef, ha sorprendido al mundo informático “cargándose” todas las contraseñas Wifi actuales (WPA2) de un plumazo. Además con una solución muy elegante. Su ataque, llamado KRACK (Key Reinstallation AttaCK) no descubre la contraseña, sino que engaña al protocolo de Wifi, y le permite conectarse, pudiendo obtener toda la información que pasa sin cifrar por esa red. Es, por lo tanto, un fallo grave que afecta a todas las redes wifi y a todos los dispositivos (porque no es a nivel de dispositivo, sino de protocolo). WPA2, lo que se ha roto, es el protocolo que hace la negociación con los dispositivos para ver si se pueden conectar a una red o no. Esta negociación la hace en 4 pasos, y es en el tercero en el que KRACK engaña al sistema. KRACK intercepta los paquetes de negociación, hace que se reenvíen y lo hace con la misma clave. Al reenviar los paquetes con la clave original de nuevo es posible descifrar esos, y cualquier otro que se envíe con esa clave. Aquí está explicado en detalle por Vanhoef. ¿Qué puedo hacer para evitarlo? Lo primero es navegar siempre de manera segura. Es decir por páginas https o usando VPN. Porque este hack permite al criminal conectarse a la red y ver su contenido en texto plano. Pero no aquel contenido que esté, a su vez, cifrado. En ese caso, él estará en la red, pero verá el contenido cifrado. Lo segundo es esperar, como este es un ataque al protocolo directamente, tenemos que esperar a que los desarrolladores y fabricantes lo arreglen. De hecho ya lo están haciendo: Microsoft ha anunciado que los sistemas con soporte (Windows 7 hasta Windows 10) ya lo tiene solucionado desde el 10 de Octubre. Si instaláis actualizaciones. Los sistemas anteriores seguramente sean vulnerables (pero no deberías estar usándolos). Apple también ha anunciado que lo tiene solucionado en todos sus dispositivos y que los usuarios tienen que actualizarlos lo antes posible. Es de esperar que las diferentes distribuciones de Linux lo vayan actualizando el los próximos días. Todos deberíamos verificar si nuestros routers, móviles, tablets etc tiene firmwares nuevos o actualizaciones y, de ser así, actualizar lo antes posible. ¿Que riesgo real tenemos? Evidentemente en tu casa nadie va a intentar usar este ataque. Requiere ciertos conocimientos. Eso si, no sabéis la cantidad de chavalines que hay en cafeterías o desde su casa probando estos métodos para ganar experiencia. Y más en redes públicas. Como siempre, recomendamos usar https y vpns. Cada día tiene más sentido. Porque aunque hayan arreglado esto…saldrán otros fallos.    

Diseño Web, Seguridad, Servidores, Sistemas

Cómo poner certificado SSL en tu web usando Cloudflare

/

Hace unos días un cliente nos dijo que por qué no activábamos SSL en su web ( dados los cambios de Google ) a través de Cloudflare porque era “muy fácil”. Es fácil, pero queremos explicaros las ventajas y desventajas. Cloudflare ofrece varias opciones para activar los certificados. Os lo dejamos de manera sencilla: Si no tienes certificado en tu servidor y o ni ganas o ni conocimiento sobre cómo instalarlo:  Flexible SSL. Este modo es el más sencillo. No requiere configuración, ni conocimientos ni instalación. Damos a un botoncito en nuestro panel de Cloudflare y, como por arte de magia, tenemos https (SSL). ¿Fácil no? Pues como siempre no es oro todo lo que reluce. Este método sólo cifra desde Cloudflare hasta el visitante. Pero el trayecto de Cloudflare a tu servidor está sin cifrar. Si, en teoría todo debería pasar por Cloudflare, pero de la teoría a la práctica hay mucho trecho. Realmente no tienes un certificado, pero el cliente (y Google etc) ven como si lo tuvieras porque Cloudflare lo emula. Pero si se cae ésta, o dejas de usarlo, ya no lo tienes. Hasta ellos dicen que : “It should only be used as a last resort if you are not able to setup SSL on your own web server, but it is less secure than any other option…..(…) This option is not recommended if you have any sensitive information on your website” En resumen es una “chapucilla” que puede servir, si no puedes instalar un certificado, para salir del paso. Pero recomendamos que sea sólo momentáneo. Si puedes instalar un certificado en tu servidor: Full SSL. Esta es la opción clásica y más segura para activar SSL. Se instala el certificado (del tipo que sea) en tu servidor y así todo el trayecto está cifrado. Requiere que tengas un certificado válido. Puedes usar los de LetsEncrypt o alguno de pago. Pero también Cloudflare emite certificados Es lo que llama Origin CA , en el que es Cloudflare la que actúa como entidad certificadora. Eso si en Free y Pro son compartidos, a partir de Business creo que es ya un certificado personalizado. Eso si, instalar un certificado en un servidor no es muy sencillo, requiere conocer el proceso. Y luego, una vez activado, podemos tener que revisar los enlaces y cambiar código en base de datos o por código porque tendremos muchos que estén puestos por http. Por ejemplo los enlaces puestos a mano tendrán que cambiarse a manos. Strict (SSL-Only Origin Pull):  Esto es sólo para las cuentas Enterprise. Lo que hace es que si tienes alguna petición http en tu web, te la devuelve como https aunque no lo hayas configurado así. Así que Cloudflare te puede ayudar a pasar a SSL si no tienes ni idea de cómo hacerlo, con la opción sencilla. Si no, te proporciona un certificado, o puedes hacerlo por tus medios.

Navegadores, Noticias Informáticas, Seguridad

En Octubre Chrome marcará muchas más páginas que no tienen https como inseguras

/

Ya lo dijimos el año pasado, Google está empeñado (y con razón) en convertir Internet en una red de páginas cifradas (https) y eliminar al máximo las páginas por http. Para ello tiene una hoja de ruta muy bien marcada. Y no es sólo Chrome, Firefox marca cualquier página sin certificado como insegura. Chrome primero marcó las páginas que pedían contraseñas o datos de tarjeta de crédito. Ahora, a partir de Octubre,en su versión 62 del navegador, marcarán como inseguras: cualquier página que solicite cualquier dato (ya no sólo contraseñas y datos de tarjeta) por http. Hay que tener en cuenta que casi todas las páginas tienen un formulario de contacto o una página de inicio de sesión. Cuando visitas cualquier página por http en una pestaña de incógnito. Al final, son lentejas. Es algo imparable. Si tienes una página web, y no lo has hecho ya, tienes que migrarla a https. Tienes varios métodos, tienes certificados gratis (muchos proveedores también los dan ahora con el hosting), os hemos explicado cómo activarlo en WordPress, y pronto en alguna página más. Es barato y necesario, no tienes excusa.

Seguridad, Servidores, Trucos

Proteger una web en Nginx contra ataques de fuerza bruta: rate limiting

/

Uno de los peligros que corren las páginas web es el ataque por fuerza bruta, y los ataque DDOS. Básicamente son muchas peticiones a la web por segundo, lo que bloquea los procesadores y “tira” la web (no se pueden procesar más peticiones y el servidor se cuelga). Evidentemente tenemos que proteger nuestra web de estos ataques. Cloudflare tiene unas protecciones mínimas para evitar estos ataques, pero en los modos gratis y Pro hemos hecho pruebas y no son muy efectivos (en modo alto, no se en modo ataque). Tenemos que pensar en Cloudflare como una capa más de seguridad, pero no algo 100% efectivo. Así que nos queda proteger el servidor, hoy os contamos cómo hacerlo con Nginx. Nginx tiene una directiva llamada limit_req_zone , que se puede usar junto con  limit_req para controlar el número de peticiones. Para comprenderlo podemos usar la analogía de un cubo de agua con agujeros. Si no tuviera agujeros y sigue llegando agua, el cubo rebosará (servidor caído). Si ponemos agujeros, podremos seguir metiendo agua sin que el servidor rebose, hasta un límite (donde ya rebosará). El agua que sale de los agujeros es la información que meteremos en los buffers. El agua que rebosa son las peticiones que no se atenderán, pero serán menos que sin agujeros. Esto nos permite controlar un poco ataques. Para configurar este parámetro hay que hacer lo siguiente: En el fichero de configuración tienes que añadir una línea como esta, configurando la zona y los límites. Juega con esos límites, sobre todo la última parte que son las peticiones por segundo. Puedes dejarlo en 10 o ponerlo en 1. Por defecto empieza en 10 y prueba. El nombre de la zona (mylimit) podemos cambiarlo también. limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; Esta línea la puedes añadir tanto en el fichero de configuración del sitio, como en el directorio conf.d en un fichero llamado limits.conf. Después en el fichero de configuración del sitio (sites-enabled) tenemos que aplicar ese límite con limit_req donde queramos (por ejemplo un wp-admin de wordpress en este caso). server { location /wp-admin/ { limit_req zone=mylimit; } } También podemos ponerlo sólo para un tipo de ficheros: location ~ \.php$ { limit_req zone=one burst=5 nodelay;}   Con esto al reinciar Nginx (prueba la configuración primero) deberías poder hacer pruebas de muchas llamadas al servidor y no debería haber problemas. Cualquier exceso o se guardará en la cola o no se procesará, sin tirar el servidor. Más información aquí.

Seguridad, Servidores, Sistemas, Trucos

Cómo proteger un servidor web para que sólo acedan las IPs de Cloudflare

/

 Ya hemos hablado de Cloudflare, el servicio web que sirve cono CDN, cahcé, firewall y mucho más. Tiene varios planes, gratis y de pago. Pero para la mayoría de las páginas web el modo gratis es suficiente. Mientras seáis conscientes de los límites de subida que establece Cloudflare. Hoy os vamos a enseñar “un truco” por el que vamos a limitar a nuestro servidor a que acepte sólo peticiones web que accedan de las IPs de Cloudflare. Esto aumentará la seguridad en nuestra web, porque eliminará cualquier petición que no proceda de Cloudflare, y las que procedan de ahí vienen filtradas por sus sistemas de seguridad. Además, también aprovechamos la caché de Cloudflare lo que hace que el rendimiento de nuestra página y la experiencia de usuario mejore. Cómo hacerlo. 1. Lo primero que debemos hacer es activar Cloudflare. Nos registramos en ese servicio, damos de alta nuestra web y nos dirá los DNS que tenemos que poner en nuestro dominio. Después tenemos que ir al proveedor de nuestro dominio y cambiar los DNS. Apunta todos los registros de DNS que tienes para copiarlos en Cloudflare. Nota: si tienes el correo con tu proveedor, puede que tengas problemas al cambiar los DNS a otro proveedor. Consulta con ellos antes. Seguramente también se puede hacer todo esto sin cambiar los DNS a Cloudflare, pero explicamos la manera más sencilla. Una vez que hayas cambiado los DNS a Cloudflare ya podemos gestionar todo desde su panel. Tenemos que activar para nuestro dominio y para www.nuestrodominio el servicio de Cloudflare. Aseguraos que en el DNS tienen la nube en naranja, no en gris. Eso significa que pasa por sus sistemas. 2. Ya tenemos el que cualquier persona de fuera que escriba nuestro dominio irá por Cloudlfare. Ahora tenemos que asegurarnos que nuestro servidor no admita peticiones de ningún otra fuente. 2.1 Por IpTables. Para eso nos vamos a nuestro servidor (suponemos que es dedicado o Cloud). Tenemos que activar en iptables el filtro para que sólo acepte las IPs de Cloudflare. Tenemos siempre un listado actualizado de las mismas aquí. Cuidado: siempre que manejes un firewall corres riesgo. Asegúrate que pruebas todo antes de activarlo y que luego tienes una manera de retroceder. Si queremos hacer esto directamente por iptables podemos hacerlo de esta manera que sugiere Cloudflare.  Sin embargo ya hemos dicho que es más fácil realizar todas estas gestiones por programas como Firehol. En Firehol abrimos el fichero firehol.conf y después de los primeros comentarios añadimos las ips de cloudflare así (una por línea). Los puntos suspensivos indican que está el resto de ips: cloudfl_ips=”103.21.244.0/22 103.22.200.0/22 ….. “ Después, en la interfaz que esté conectada al exterior ponemos: server http accept src “$cloudfl_ips” server https accept src “$cloudfl_ips” Con esto graba el fichero y asegúrate de probar la configuración antes de reiniciar el servicio. 2.2 Por configuración del servidor web (Nginx en este caso). Podemos restringir las ips de Cloudflare en el servidor web. Hoy lo mostraremos en Nginx. Para ello creamos el fichero: etc/nginx/cloudflare-allow.conf  con un contenido como este: # https://www.cloudflare.com/ips # IPv4 allow 199.27.128.0/21; allow 173.245.48.0/20; allow 103.21.244.0/22; allow 103.22.200.0/22; allow 103.31.4.0/22; allow 141.101.64.0/18; allow 108.162.192.0/18; allow 190.93.240.0/20; allow 188.114.96.0/20; allow 197.234.240.0/22; allow 198.41.128.0/17; allow 162.158.0.0/15; # IPv6 allow 2400:cb00::/32; allow 2606:4700::/32; allow 2803:f800::/32; allow 2405:b500::/32; allow 2405:8100::/32; Después, en la carpeta sites-available (o sites-enabled), editamos el fichero de configuración de tu dominio y en el apartado server ponemos: include /etc/nginx/cloudflare-allow.conf; deny all; Y reiniciamos nginx. Esto debería restringir las ips a sólo las de Cloudflare y rechazar el resto. También se puede hacer así.

Scroll al inicio