Plesk, seguridad, Proxmox, cloud, Manuales, tips, Servidores, scripts bash, sysadmin, Linux, Centos, Ubuntu, MySQL,
Hace unos días me encontre problemas con el Sitebuilder que al actualizar el panel control plesk de 8.4 a 8.6.
Razón de más para eliminarlo para evitar que pueda darnos algún problema o que este siempre corriendo en nuestro servidor por pocos recursos que consuma.
Para desinstalarlo solo tenemos que utilizar YUM:
Para más información consultar “Uninstall SiteBuilder“
El proceso es casi idéntico tanto para Linux como Windows, solo hay un paso que difiere a la hora de buscar el modulo PKCS#11 (el driver del DNI).
Al igual que con el post sobre Gmail, asumo que ya tienes el DNI digital configurado en tu PC y te funciona en Firefox y/o Explorer.
Sin mas preámbulos, empezamos:
Nos situamos en el menú Editar –> Preferencias, una vez ahí, nos vamos a ‘Avanzadas’, pinchamos en ‘Dispositivos de seguridad’
Una vez ahí, pulsamos en ‘Cargar’
Le ponemos como nombre al nuevo modulo ‘Dni Digital’ y, atención, aquí viene la diferencia entre Linux y Windows. En linux debemos localizar la ruta del fichero opensc-pkcs11.so lo podemos localizar con el comando
$ locate opensc-pkcs11.so
/usr/local/lib/opensc-pkcs11.so
En el caso de Windows el fichero que debemos poner es:
C:\WINDOWS\system32\UsrPkcs11.dll
Si todo ha ido bien se nos pedirá que confirmemos el nuevo modulo que hemos añadido
Thunderbird nos informa que ya tenemos disponible el DNI
Podemos ver que Thunderbird ya reconoce el DNI, en mi caso aparece asociado a mi lector de tarjetas que viene integrado en el teclado Dell (si, el teclado de la película Firewall 😉
Ahora tenemos que asociar un certificado digital a nuestra cuenta de correo para poder realizar el firmado de correos. Nos situamos en el menú Editar –> Configuración de las cuentas. Una vez ahí, pinchamos en ‘Seguridad’. Como se puede ver en la parte derecha, podemos asociar un certificado para realizar la firma de correos, pinchamos en ‘Seleccionar’
Dado que el DNI-E pide el PIN para poder acceder a los certificados digitales, nos solicita que introduzcamos el susodicho PIN.
Si el PIN es correcto, veremos los dos certificados digitales que hay en el DNI-E, uno para Firma y otro para autenticación. Seleccionamos el de firma
Ahora Thunderbird nos informa que podemos también asociar un certificado para recibir correos electrónicos cifrados. Como decía en mi anterior post sobre Gmail, el DNI no tiene certificados digitales validos para cifrado, así que pulsamos en ‘Cancelar’ (de lo contrario aparecerá un mensaje de error)
Con todos los pasos anteriores ya dados, podemos enviar nuestro primer correo electrónico que lleve una firma digital en Thunderbird. Para ello nos vamos a ‘Redactar’ (como si fuéramos a escribir un email normal y corriente)
Para activar el firmado digital del correo, hemos de ir al candado de ‘Seguridad’ y entre las opciones que aparecen: ‘Firmar digitalmente este mensaje’
Una vez le demos a enviar, se nos pedirá el PIN del Dni para realizar la firma del correo
Ahi lo tienes¡¡¡¡ ya hemos enviado un mail firmado digitalmente con Thunderbird
Logrep es una solución de código libre para centralizar los logs de tus servidores, tanto para Linux como para Windows.
Los logs se presentar en formato HTML a través del componente cliente de esta utilidad que como ya hemos comentado es totalmente multiplataforma. El cliente es capaz de recoletar logs de 30 sistemas diferentes entre los que están: Snort, Squid, Postfix, Apache, syslog, ipchains, Qmail, Sendmail, iptables, Servidores Windows, Firewall-1, wtmp, xferlog, Oracle y Pix.
Entre las características de Logrep podemos citar:
Logrep es sin duda la herramienta ideal para administradores de sistemas que necesiten centralizar la gestión de logs y tener una sistema de acceso rápido a todos ellos. La mejor forma de analizar por ejemplo una posible intrusión en la red.
Enlaces de referencia:
Este pequeño tip en el user apache me lo encontre en varios servidores a los que «analice» :D, esta bien pensando por el admin que se lo ingenio pero se olvido de securizar otros servicios/usuarios.
Consultamos el directorio de apache en /etc/passwd y aparece algo como
apache:x:48:48:Apache:/var/www:/bin/false
Ai se puede apreciar que su directorio del usuario es /var/www
Me dirijo a ese directorio y creo un archivo llamado .bashrc y en el solo escribo exit
lo guardo y listo; lo mismo con los otros usuarios que se deseen bloquear
Cuando el script del spammer es un script realizado en php, el problema que tenemos para localizarlo es que el usuario será apache (a no ser que el servidor use su_exec o similares) y será más dificultoso encontrarlo ya que no puede ser identificado con el nombre de usuario del dominio.
Si se usa Plesk hay dos procedimientos estándares creando wrappers de Sendmail y que suelen funcionar. El propio Plesk lo describe en estos dos artículos:
http://kb.parallels.com/article_22_1711_en.html
http://kb.parallels.com/en/766
Podemos dejar el wrapper funcionando durante algún día para intentar localizar al spammer. Adicionalmente podemos dejar un cron que dispare un fichero con greps del tipo:
grep X-Additional /var/tmp/mail.send | grep `cat /etc/psa/psa.conf | grep HTTPD_VHOSTS_D | sed -e ’s/HTTPD_VHOSTS_D//’ ` | awk ‘{print $2}’ | awk ‘BEGIN {FS=”|”} {print $1}’ | sort|uniq -c | sort -rn
y que nos envié por email los resultados del wrapper.
Una vez conocido el directorio o fichero desde donde se envía el spam, tendremos que comprobar en los logs como se ha logrado el acceso para subir el citado fichero. Normalmente suele haber aplicaciones php muy antiguas que no han sido actualizadas a versiones nuevas. Tendremos que advertir al propietario del sitio que actualice sus aplicaciones, cambie sus claves, revise todos los ficheros e incluso suba un backup anterior. Habrá que eliminar los ficheros maliciosos y colocar restricciones más fuertes al dominio creando un fichero .htaccess o en el propio /conf/vhosts.conf del dominio.
Tales restricciones podrían ser:
php_flag register_globals off
php_flag allow_url_fopen off
php_flag file_uploads off
php_flag magic_quotes_gpc on
php_flag safe_mode on
php_flag disable_functions show_source
php_flag disable_functions system
php_flag disable_functions shell_exec
php_flag disable_functions passthru
php_flag disable_functions exec
php_flag disable_functions phpinfo
php_flag disable_functions popen
php_flag disable_functions proc_open
Adicionalmente habría que revisar los directorios temporales /tmp para comprobar que no hay scripts con usuario apache que estén enviando spam.
Igualmente siempre es utilizar las reglas actualizadas de mod_security para prevenir ataques comunes vía web (el 95% de los ataques son vía web) y herramientas de deteción de intrusos como OSSEC, y Atomic Secure Linux
Sería recomendable añadir a iptables las ips de las maquinas que realizaron el ataque, aunque el atacante atacará desde otras ips sin complicaciones. Incluso puede ser interesante bloquear rangos de ips de forma momentanea si hay un ataque en progreso.