Centraliza los logs de tus servidores con Logrep

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:

  • Protocolo de comunicación segura entre cliente servidor a través de SSH.
  • Completa ayuda para la interpretación de logs.
  • Guardar copias de todos los logs en un sistema central.
  • El cliente extrator de datos consume realmente pocos recursos.
  • Tus logs con representación gráfica.

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:

Logrep en SourceForge.

Descargar de Logrep.

Sistemas de los logs que puede interpretar Logrep.

Manual Instalación de Logrep

Protección para el usuario apache

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

Encontrar scripts spammers en el servidor

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.

Como borrarse de una lista negra

Es una tarea habitual en los proveedores de alojamiento web  encontrarnos con ips de clientes que se insertan en listas negras. Las razones pueden ser variadas:

a) Un cliente en un servidor compartido o dedicado realiza un envío masivo de emails y alguien legítimamente o nó lo denuncia en una de las páginas que manejan estas listas negras.

b) Un spammer utiliza scripts de envío ilegítimos y realiza envíos masivos desde su dominio habiéndose aprovechado de alguna vulnerabilidad en el mismo dominio (aplicaciones php inseguras, mal programadas..etc.)

C) Su ordenador local tiene algún virus o troyano y está siendo utilizado para enviar emails y realizar diversas actividades maliciosas.

El resultado es que la IP del servidor de correo saliente es prohibida en alguna lista y los proveedores de internet y otros proveedores de internet que usan servicio de listas negras para su propio filtrado, no podrán recibir su correo, este será eliminado y filtrado directamente antes de llegar a su destinatario. El cliente que envía el correo recibirá normalmente un mensaje devuelto indicando que su email no ha podido ser entregado debido a que su IP (la del servidor de correo saliente o o la de su conexión adsl) se encuentra en alguna lista negra.

¿Qué podemos hacer?

1) Primero necesitamos comprobar que efectivamente la ip está listada.

Para comprobarlo podemos ir a esta URL http://www.mxtoolbox.com/blacklists.aspx?AG=GBL ó http://www.us.sorbs.net/lookup.shtml o directamente a la listas más importante como

http://www.spamcop.net/bl.shtml o http://www.spamhaus.org/lookup.lasso e introducir la IP de nuestro dominio y también, para salir de dudas, de nuestra IP local de conexión ADSL.

Si está listado podemos solicitar la baja de esa lista en esas webs citadas. El deslistado puede tardar 24-48 horas.  El caso más grave es estar listado en Hotmail. En este caso hay que escribir a Hotmail directamente para solicitar el deslitado en el formulario http://www.hotmail.msn.com/cgi-bin/dasp/ua_info.asp?pg=contact_hotmail&_lang=ES.

En el caso de estar listados por telefónica es necesario contactarles vía email en nemesys@telefonica.es

En cualquier caso antes de contactarles es necesario asegurarse que el envío de spam ha cesado y que hemos encontrado al responsable del envío del correo. En la mayoría de casos, un script en php o perl que ha sido subido desde la web aprovechándose de una vulnerabilidad de sus aplicaciones y scripts.

2) Si la Ip listada es de nuestra conexión y nuestra IP es fija, entonces deberíamos realizar  comprobar que en nuestros PCs no existen virus y no hay troyanos u otros bots que estén usando nuestra conexión para enviar spam.

3) Si la ip es del servidor,  es el proveedor web el que debe  de deslistar esa IP y averiguar quien ha sido el responsable del envío tomando las medidas necesarias para que no se vuelva a repetir ese tipo de abuso.

Fuente: http://blog.digitalvalley.com

Mostrar información del certificado SSL desde consola (CLI)

Este pequeño post que os escribo hoy os va a servir a todos aquellos sysadmins, que quieran monitorizar en (nagios por ejemplo) o simplemente ver las fechas de expiración u otros datos de los certificados SSL desde consola.

Para ver la fecha de expiración, usamos nmap:


 nmap -p 443 --script ssl-cert www.dominioquesea.com



Output

Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-19 13:01 CET
Nmap scan report for dominioquesea.com (x.x.x.x)
Host is up (0.050s latency).

PORT STATE SERVICE
443/tcp open https
| ssl-cert: Subject: commonName=dominioquesea.com
| Subject Alternative Name: DNS:dominioquesea.com, DNS:dominioquesea.com
| Issuer: commonName=COMODO RSA Domain Validation Secure Server CA/organizationName=COMODO CA Limited/stateOrProvinceName=Greater Manchester/countryName=GB
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2018-11-19T00:00:00
| Not valid after: 2019-12-19T23:59:59
| MD5: f9a5 d0be 54fe 6409 86aa cb99 2f3f 0575
|_SHA-1: e213 f74b 41a9 2a3d fbe5 398e 8fed 9708 9500 feb3



curl --insecure -v https://www.google.com 2>&1 | awk 'BEGIN { cert=0 } /^\* SSL connection/ { cert=1 } /^\*/ { if (cert) print }'



Output:

* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification SKIPPED
* server certificate status verification SKIPPED
* common name: www.google.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com
* start date: Wed, 24 May 2017 17:39:15 GMT
* expire date: Wed, 16 Aug 2017 17:13:00 GMT
* issuer: C=US,O=Google Inc,CN=Google Internet Authority G2
* compression: NULL
* ALPN, server accepted to use http/1.1
* Connection #0 to host www.google.com left intact

echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -enddate
Output:
notAfter=Jan 22 13:15:00 2019 GMT