Error “502 Bad Gateway” en Nginx

por webstudio el 10 diciembre, 2015

A veces Nginx nos sorprende con estos errores. Lo que sucede no es nada extraño; es que algunos límites se han quedado “cortos” y es necesario ampliarlos un poco más.

En estos casos basta con agregar estas líneas en el nginx.conf (/usr/local/nginx/nginx.conf). Es importante saber que cada uno puede ir modificando estos valores de acuerdo a las necesidades y usos de su máquina, aquí exponemos unos valores generales:

fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;

No olvides reiniciar nginx después: service nginx restart

Error “504 Gateway Time-out” en Nginx

por webstudio el 10 diciembre, 2015

Si recibes este error es probable que Nginx tenga unos valores un poco conservadores para el consumo que está teniendo tu máquina.

En estos casos basta con aumentar los tiempos de timeout de Nginx, cada uno puede ir modificando estos valores de acuerdo a las necesidades y usos de su máquina, aquí exponemos unos valores generales:

proxy_connect_timeout       500;
proxy_send_timeout          500;
proxy_read_timeout          500;
send_timeout                500;

En el siguiente instructivo cubriremos el error 502 Bad Gateway de Nginx.

Cambiar puerto de SSH en CentOS 7

por webstudio el 10 diciembre, 2015

La siguiente entrada tiene la intención explicar los pasos a seguir para poder cambiar el puerto de escucha del servicio de ssh en CentOS 7.

vi /etc/ssh/sshd_config

#Port 2220

– Pasa a ser:

#
Port 2220

El siguiente paso es añadir permiso SELINUX a ssh para abrir otro puerto

semanage port -a -t ssh_port_t -p tcp 2220

Añadimos una regla al firewall de CentOS 7

firewall-cmd –permanent –zone=public –add-port=2220/tcp
firewall-cmd –reload

Instalar memcached a través de PECL con Plesk

por webstudio el 10 diciembre, 2015

Memcached es uno de los mejores sistemas de cache en la actualidad. Por supuesto, no es el mejor y dependiendo de cada necesidad y uso, existen otras alternativas como APC (o APCu) o Redis entre otros, sin olvidar claro a opCache para PHP 5.6 o superior, pero no deja de ser una alternativa de cache muy fácil de instalar, configurar y utilizar.

Hoy os explicaremos cómo instalar Memcached a través de PECL con Plesk.

# Instalamos el paquete:

yum install memcached

# Editamos el archivo de configuración:

vi /etc/sysconfig/memcached

Esta es la configuración de ejemplo para un cache de 256MB:

PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="256"
OPTIONS=""

# Inicia el servicio memcached:

/etc/init.d/memcached restart

# Configura memcached para que se ejecute al inicio

 chkconfig memcached on

# Revisa que esté funcionando

memcached-tool  127.0.0.1:11211 stats

# Instala memcached (extensión PECL para PHP)

 yum install php-pecl-memcache

# Ahora reinicia memcached y apache

/etc/init.d/memcached restart

/etc/init.d/httpd restart

Informe de Seguridad, Octubre 2015

por webstudio el 3 noviembre, 2015

Informe de ataques detenidos a nivel de defensa perimetral durante el mes de octubre de 2015

Incluimos sólo los más importantes en términos de volumen.

Ataques de fuerza bruta

Durante el mes de octubre continúan los ataques de fuerza bruta contra instalaciones WordPress. Si bien con menos intensidad que en los meses anteriores tras haber sido bloqueadas varias botnets por parte de nuestro equipo de seguridad liderado por Adolfo Doliwa.

Recordamos la grave problemática de las páginas con WordPress. Si se dedice a utilizar WordPress, o si ya lo está utilizando, es extremadamente importante que lo securice, lo mantenga actualizado y lo monitorice. Si no sabe cómo hacerlo, no utilice WordPress o contrate los servicios de un profesional. ADW le ofrece un servicio específico para securizar su wordpress desde http://www.adw.es/soporte.html o directamente desde https://intranet.adw.es/intranet/cart.php?a=confproduct&i=2

Por favor, no instale WordPress de mala manera y se olvide de él: probablemente tendremos que cortarle el servicio que tenga contratado.

Procedencia de los ataques de fuerza bruta

Si más comentarios. Rusia sigue al frente de países atacantes. Parece que nadie controla la seguridad de las redes de ese país. Pero España le sigue a la zaga. Da que pensar. Lo hemos comentado muchas veces: ni se invierte en seguridad ni se le hace mucho caso y teniendo en cuenta que la mayoría de redes atacantes pertenecen a proveedores de hosting…. asusta (no vamos a mencionar nombres, porque prácticamente son todos).

Ataques de seguridad

Procedencia de los ataques de seguridad

Si bien los ataques de fuerza bruta proceden casi todos de botnets Rusas y de equipos infectados en manos de grandes botnets, los ataques de seguridad (injects, backdoors, DOS y DDoS) son un poco más “selectivos” y EEUU se lleva la palma en este caso, seguido este mes de México, pero debido a un caso muy concreto contra un cliente determinado que fue atacado de forma intencionada desde ese país (se intentó un DDoS de miles de conexiones simultáneas por segundo).  A nivel perimetral conseguimos detener más del 90% de los ataques, pero – por favor – no baje la guardia: no todos los ataques son susceptibles de ser detenidos y hay casos en los que no queda más remedio que sacar de la red el sistema atacado.