Fallo de seguridad en Samba (3.2.0 – 3.2.6)

Es posible acceder al directorio raíz del recurso compartido conectando a “” (ua cadena vacía de caracteres) usando smbclient, por ejemplo con:

smbclient //server/ -U user%pass

El acceso al sistema se produce con los permisos del usuario autenticado. Este problema únicamente ocurre con la variable registry_shares = yes la cual también implica tener include = registry y config backend = registry pero no es la configuración por defecto. Un parche está disponible en la página web de Samba. Lo recomendable sería actualizar, aplicar este parche o bien deshabilitar la variable en cuestión (registry shares = no).

Podéis encontrar más información al respecto aquí.

Cómo asegurar un servidor cPanel.

Como creo que mucha gente usa este tipo de páneles de control, intentaré traducir un documento acerca de la seguridad de este panel de control sobre Cent OS, realizado por Krun!x y que me encontré aquí.

Bueno, comenzamos.

1. Actualizar Apache/PHP, MySQL, OpenSSH, OpenSSL, CP/WHM, etc.

2. Configuración cP/WHM.

3. Acceso SSH.

4. Mod_Security.

5. Firewall.

6. Proteción contra DDoS.

7. RootKits.

8. Configuración PHP.

9. Otros.

10. Fin.

Hola a todos, en primer lugar os pido perdón por mi inglés, ya que no es mi lengua nativa. He escrito un tutorial sobre la seguridad en los servidores, cómo securizar servidores web. Uso Cent OS, Apache y cP/WHM. Explicaré cómo asegurarlos.

Empecemos :)

  • 1. Actualizar Apache/PHP, MySQL, OpenSSH, OpenSSL, CP/WHM, etc.

Actualiza tu Apache/PHP, MySQL, OpenSSH, OpenSSL, cP/WHM y asegúrate de que tengas la última versión segura y estable.

  • 2. Configuración cP/WHM.

WHM – Configuración de servidor – Parámetros de seguridad:

- Activar: php_openbase_dir, mod_userdir, proteción contra shell bombs y/o memory bombs.

- Desactivar: Compilador, excepto para el usuario root.

WHM – Ajustes en las cuentas.

- Desactivar: Modo demostración del panel de control, acceso (a través del shell) de todas las cuentas menos al usuario root.

WHM – Configuración de servicios – Configuración de FTP.

- Desactivar: Acceso al FTP como usuario anónimo.

WHM – MySQL.

- Escoge una password para tu servidor MySQL (no pongas la misma que usas para el usuario root). Si no eliges una contraseña para MySQL y alguien sube una shell como c99 al servidor podrá hacer login al servidor de bases de datos como root sin contraseña y podrá eliminar, borrar o bajar cualquier base de datos del servidor.

WHM – Configuración del servidor.

- Activa suEXEC y PHPsuEXEC.

Cuando PHP se ejecuta como módulo en Apache, éste se ejecuta normalmente como usuario “apache” o “nobody”.

PHPsuEXEC cambia esto y ejecuta los scripts como CGI’s. Esto significa que los scripts son ejecutados con los permisos del usuario que creó el script. Los permisos del script no podrán ser 777 (ejecución, lectura y escritura para todos).

  • 3. Acceso SSH.

Cambia el puerto de acceso para SSH (pon algo como 1334). Pudes cambiarlo en /etc/ssh/sshd_conf. Hay un montón de Script Kiddiez con programas brute force e intentan crackear nuestra password porque ellos saben que el nombre de usuario es root y el puerto es el 22. Pero como somos más inteligentes, vamos a cambiar este puerto. Este proceso de brute force puede consumir ancho de banda, por lo que hará más lento el tiempo de respuesta del servidor.

El mensaje legal de SSH. Edita /etc/motd y escribe algo como esto:

“¡Alerta! Esto es un área restringida y el administrador ha sido notificado.”

Cuando alguien intente entrar al servidor a través de SSH, le aparecerá el mismo mensaje que acabas de editar. Finalmente, deberás reiniciar SSH con la orden: service sshd restart

  • 4. Mod Security.

ModSecurity es una aplicación que funciona como un cortafuegos para tu web y que puede asegurarla contra: RFI, LFI, XSS, SQL Injection, etc. Si usas cP/WHM puedes habilitarlo fácilmente: Plugins, activar ModSecurity y salva los cambios.

Ahora explicaré cómo instalar ModSecurity desde el código. No podrás instalar ModSecurity si no tienes los siguientes paquetes ya instalados: libxml2 y la librería http-devel. También tendrás que activar mod_unique_id en los módulos de Apache, pero no te preocupes, te explicaré cómo hacerlo :) .

Accede a través de SSH y escribe:

yum install limxml2 libxml2-devel http-devel

Esto instalará estos paquetes.

Ahora necesitas editar el archivo de configuración de Apache que lo puedes encontrar en: /etc/httpd/conf/httpd.conf

Necesitas añadir lo siguiente:

LoadModule unique_id_module modules/mod_unique_id.so

Ahora descarga la última versión de ModSecurity para Apache v2 desde http://modsecurity.org:

cd /root/downloads/

wget http://modsecurity.org/download/modsecurity-apache_2.5.6.tar.gz

tar xzf modsecurity-apache_2.5.6.tar.gz

cd modsecurity-apache_2.5.6.tar.gz

cd apache2

./configure
make
make install

De nuevo edita httpd.conf y añade:

LoadFile /usr/lib/libxml2.so

LoadModule security2_module modules/mod_security2.so

Include /etc/httpd/conf/modsecurity.conf

El contenido del modsecurity.conf lo tenéis en la fuente original, a partir de la línea en donde pone: content of /etc/httpd/conf/modsecurity.conf. Analizarlo detenidamente antes de incluirlo para saber bien cómo funciona y si os puede ocasionar algún problema cualquier de las reglas que contiene.

Ahora, reinicia Apache:

service httpd restart

  • 5. Firewall

Instalaremos APF (Advanced Policy Firewall). APF es un cortafuegos basado en IP Tables diseñado para ser fácil de usar y configurar.

Entra en el servidor y escribe:

cd /root/downloads/

wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz

tar -xfvz apf-current.tar.gz

cd apf-0.9.5-1 // O cualquiera que sea la versión.

./install.sh

Os aparecerá un mensaje de que ha sido instalado con éxito, y algunas rutas acerca de las configuraciones. Ahora pasemos a configurar nuestro nuevo cortafuegos. Necesitamos editar apf.conf, que está en /etc/apf/conf.apf

Si usas cP/WHM, como yo, necesitas configurar APF de la siguiente manera (para que podamos acceder a cP/WHM, ya que por defecto APF bloquea el acceso a estos puertos).

La configuración también la tenéis en la fuente original. Empieza en donde aparece: “common ingress (inbound ports)” y termina hasta donde está marcado con una línea de guiones bajos. Revisadla bien por si acaso y sobre todo si tenéis los puertos diferentes a éstos.

Luego en el fichero: apf.conf deberéis cambiar la variable DEVM de 0 a 1. Ahora nos toca arrancar APF:

apf -s

Otros parámetros:

-r reinicia APF.

-f Vacía el firewall (limpia las reglas).

-st Muestra un status del firewall.

-d IP Banea dirección IP.

-u IP Elimina el baneo de una dirección IP.

  • 6. Protección DDoS.

Instalaremos el módulo para Apache mod_evasive, que sirve para prevenir este tipo de ataques al servidor. Para instalarlo entra por SSH a tu servidor y escribe:

cd /root/downloads

wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz

tar xfvz mod_evasive_1.10.1.tar.gz

cd mod_evasive

/usr/sbin/apxs -cia mod_evasive20.c

Cuando mod_evasive esté instalado, pon las siguientes líneas en tu httpd.conf

--------------------------------
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
</IfModule>
--------------------------------

Ahora vamos a proceder a instalar DoS Deflate. Para hacerlo, haz lo siguiente:

wget http://www.inetbase.com/scripts/ddos/install.sh
chmod 0700 install.sh
./install.sh

Y para desinstalarlo haremos esto otro:

wget http://www.inetbase.com/scripts/ddos/uninstall.ddos
chmod 0700 uninstall.ddos
./uninstall.ddos
  • 7. Rootkits.

Bien, vamos a instalar rootkithunter. RootkitHunter es una herramienta que te asegura al 99% de que estás limpio de programas peligrosos. Busca rootkits, backdoors y exploits locales haciendo pruebas como comparar MD5, ficheros ocultos, etc.

  • 8. Configuración PHP.

Necesitamos modificar php.ini, el cual puedes encontrar en /usr/local/lib/php.ini:

safe_mode = On
expose_php = Off
magic_quotes = On
register_globals = off
display errors = off
disable_functions = show_source, system, proc_terminate,
shell_exec, exec, passthru, proc_open, phpinfo, popen

Si estás usando cP/WHM puedes configurarlo desde el mismo en configuración de servicio y posteriormente en editor de configuración para PHP.

  • 9. Otros.

Si estás usando NAMED (BIND), tienes que editar /etc/named.conf y añadir:

recursion no;

bajo la opción Options {

Ahora reinicia BIND con: service named restart. Ésto bloqueará las peticiones desde dnstools.com y similares que causan lentitud en el servidor.

Ahora lo que haremos será prevenir el IP Spoofing editando el fichero /etc/host.conf y añadiendo:

order bind,hosts

nospoof on

También ocultaremos la versión de Apache con la siguiente opción en httpd.conf:

ServerSignature Off

Deshabilitaremos telnet editando /etc/xinetd.d/telnet:

disable = yes

  • 10. Fin.

Este es el final del artículo acerca de cómo asegurar un servidor y espero que te haya ayudado a hacer más seguro tu servidor.

Autor original: Krun!x

Fuente original en inglés: http://packetstormsecurity.nl/papers/general/server_security.txt

El FBI ayuda a encerrar al hacker neozelandés Howick.

Un hacker del este de Auckland que robó cientos y cientos de dólares y llevó al FBI hasta Nueva Zelanda ha sido encarcelado por tres años. Thomasz Grygoruk, de 22 años, fue encarcelado con 5 cargos de correo fraudulento, fraude con computadora y documentación falsa cuando visitó la corte de Aucklad el 23 de Mayo.Grygoruk estuvo cinco años usando software malicioso para hacer con datos personales de terceros para hacer tarjetas ATM, con las que estafó más de 300.000 $La corte supo que también accedió a una cuenta de correo electrónico de un profesor americano de Pennsylvania al que le envió correo con malware para captar información acerca de una relación con un estudiante.El hacker había amenazado al profesor con contárselo todo a la policía local y a los demás profesores dándolo a conocer como un pedófilo que tenía una relación romántica con un estudiante. Éste llamó al FBI, y uno de los agentes se hizo pasar por el profesor, localizando la situación desde la que el hacker se conectaba.El FBI envió un agente a Nueva Zelanda para ayudar con el caso.Por más de cinco años Grygoruk uso troyanos y virus para obtener información a través de internet de cientos de personas. El método usado era el clásico sitio del banco (phising) en donde los usuarios introducían su nombre de usuario y su respectivo PIN para acceder cuando en realidad el que obtenía los datos era el hacker. Más información aquí, en la fuente de la noticia.

Debian y SSL.

Muchos de vosotros sabréis del problema que ha tenido la gente de Debian con SSL. Resulta que el generador de números aleatorios de OpenSSL es predecible. Cualquier cosa que se genere con él es predecible y como muchos dicen lo peor es que esto durará años y tendrá muchos efectos colaterales en otras muchas distribuciones. Sólo es posible por lo visto generar un total de 65536 combinaciones. Ésto combinado con las llaves previamente calculadas hace posible un ataque de fuerza bruta a través de SSH.Y juntando todo esto, nuestro amigo Markus Mueller lo demuestra con este exploit hecho en perl en donde según él se puede sacar algo sustancioso en menos de 20 minutos.Creo que no hace falta decir que esta información es con fines educativos (aunque no sea yo el autor) únicamente.

El sitio web de la tienda de PlayStation posiblemente comprometido.

Leo en 1up la noticia, e inmediatamente después en las consecuencias: miles de datos sensibles de los usuarios al descubierto. Bueno, como siempre os traduzco la noticia y me dejo de historias:

Una potencial brecha de seguridad en el website de la tienda de PlayStation ha podido dejar al descubierto información sensible de un “pequeño porcentaje” de usuarios, anunció Sony Computer Entertainment en sus dos sitios: PlayStation Reino Unido y PlayStation US (via ShackNews).

“Hemos encontrado que existe la posibilidad de que exista un acceso no autorizado a información personal” de los clientes de la tienda PlayStation, según la noticia del día de Sony. Mientras Sony no maneja números de tarjetas de crédito, Sony afirma que es muy poco probable que información bancaria sensible haya sido robada. Sin embargo, admite que es posible que la contraseña de un porcentaje pequeño de usuarios ha podido ser cambiada, haciendo posible al atacante ver la información del usuario y/o hacer uso de la maleta para la tienda de Sony.

También afirma en la noticia que “han sido tomadas acciones inmediatas para solventar el error y la seguridad del sistema ha sido restablecida”. Contactarán a cualquier usuario que haya sido afectado, para que éste se loguee en la tienda y pueda comprobar que su contraseña no ha sido cambiada (si puedes entrar, estás “limpio”).

La noticia fue originalmente posteada en el sitio del Reino Unido de Sony únicamente, pero un mensaje adicional desde USA confirmó que era una brecha global. Sólo para confirmar si estás a salvo, cualquier usuario de la tienda de Sony deberá logearse para asegurarse, hasta que publiquen los detalles del incidente.

La noticia completa y en inglés haciendo click aquí (Vía 1up.com)