Memcached la seguridad es un tema candente desde que los chicos de sensepost publicaron go-derper en blackhat.
La presentación fue bastante buena e informativa, pero parece que el bombo que se le ha dado ha dejado a mucha gente confusa. Aunque gran parte de este tema se trató en la presentación, es necesario repetirlo en la medida de lo posible.
Primero y siempre, cortafuegos
Esto es realmente parte de la prueba de nivel sysadmin y no tiene nada que ver con memcached en particular, pero voy a seguir adelante y mencionarlo de todos modos.
Siempre se empieza por un cortafuegos todo y luego permitir que sólo las cosas que necesitas pasen por los lugares que necesitas que pasen.
No voy a enseñarte a usar tu cortafuegos, pero empieza con la configuración que desactiva toda conectividad a tu caja.
Si está ejecutando un servidor web, permita conexiones al puerto 443. Si también desea conexiones no SSL, permita el puerto 80. Si ese es el único servicio que presta, su cortafuegos ya está completo.
Me gustaría señalar que Amazon EC2 hace esto por defectoSin embargo, hay suficientes cortafuegos mal configurados como para que hayan sentido la necesidad de enviar un formulario a muchos de sus usuarios para hacerles saber que "tienen al menos un grupo de seguridad que permite que todo Internet tenga acceso al puerto más utilizado por...". memcached (11211)".
Compruebe sus fijaciones
Si su aplicación sólo se ejecuta en un servidor (con la app y el memcached en el mismo equipo), puede enlazarlo a localhost añadiendo
a la memcached banderas. Ahora, a pesar de que ha firewall acceso a memcachedTienes que ser en la máquina para contactar incluso con la caché cuando alguien rompe la configuración de su cortafuegos.
Si lo necesita, utilice SASL
Las últimas versiones de memcached admite cifrado SASL autentificación.
Aunque ya haya protegido su memcached desactivados, puede exigir a los clientes que realicen una autenticación fuerte antes de utilizar el servicio.
Por favor, Por favor, No ejecutar como root
Bajo ninguna circunstancia debe intentar ejecutar memcached como raíz; se no quiere ejecutar como root. Se esfuerza por evitarlo. Sin embargo, muchas personas tienen una "solución" que permite memcached para iniciar como root (que no voy a repetir) sólo por el bien de hacer su infraestructura menos segura.
Si alguien se salta de algún modo el cortafuegos que ha configurado para impedir el acceso a memcached y de alguna manera se las arregla para encontrar un agujero de seguridad en memcached permitiendo la ejecución de código, ¿ realmente ¿Quieres entregar el acceso root?
No hay problemas conocidos, pero no auditamos el código para asegurarnos de que es seguro ejecutarlo como root. Eso está bien, porque ningún administrador de sistemas responsable ejecutaría un servicio como root sin una justificación muy sólida, y probablemente mucho trabajo en la creación de un entorno enjaulado.
Compruebe la configuración del cortafuegos
Mira, no estoy dudando de que sepas cómo configurar tu cortafuegos, pero ten paciencia conmigo.
Agarra nmap o similar. Ejecute un escaneo completo de puertos en su equipo: uno desde un sistema fiable, otro desde un sistema semiconfiable y otro desde un sistema completamente no fiable.
Si hay alguna respuesta para algún servicio que no puedas justificar, ahora lo sabes y puedes solucionarlo.
Eso es no sólo memcached - es decir, gearman, beanstalkd, snmpd, un servidor de correo, un servidor DNS, un servidor LDAP, etc.
Para cualquier servicio que do tienen en funcionamiento y a disposición del público, asegúrese de completamente comprender las implicaciones de seguridad de la ejecución de este servicio.
No te avergüences de preguntar si no lo entiendes todo. Es mucho mejor que ser un ejemplo en una presentación en el próximo black hat porque estás ejecutando un servicio que no tenías previsto y filtraste información importante.
