CageFS: CloudLinux – Issues

La onda es que el CageFS, hace un skeleton de todos los archivos de config y hace que los usuarios esen ese… en vez del original: esto resguarda todos los archivos de sistema: pero existe un problema menor: si se actualiza el php.ini, es necesario actualizarlo del skeleton que éste hace; para que actualice.
Es simple:

# cagefsctl –update

Regards, Amaro.

suPHP: Solucionar 500 Internal Server Error.

Acomodando los permisos de carpetas, dueño de archivos/carpetas y permisos de achivos, solucionamos todos los problemas que pueda traer suPHP a nuestra web:

Despues de internet suPHP corré:
find /home/*/public_html -type d -exec chmod 755 {} \;
Este comando arregla todos los permisos de carpetas.

find /home/*/public_html -name '*.php' -o -name '*.php[345]' -o -name '*.phtml'| xargs chmod -v 644
Este comando arregla todos los permisos de archivos
Por ultimo, pero no menos importante:

#!/bin/bash
cd /var/cpanel/users
for user in *
do
chown -R $user.$user /home/$user/public_html/*
done

Este script arregla todos los problemas de dueño de archivos.

SSHd: Config varias

En el archivo: /etc/ssh/sshd_config
Primero: cambiamos el puerto por seguridad:

Port xxxx
Listen xxx.xxx.xxx.xxx
TCPKeepAlive yes
UseDNS no
ClientAliveInterval 30
ClientAliveCountMax 100

y en /etc/ssh/ssh_config
Añadir:
ServerAliveInterval 60

 

 

FlashPolicyd + Ruby en CentOS con CPanel

CPanel modifica el yum.conf y exclude a Ruby… de su instalacion: si no sabes eso, te comes un viaje porque no se explica como con: yum install ruby
no se instala…
asi que para instalar Ruby, primero ejecutamos este comando: /scripts/installruby
(asi de corta y esperar.. )

Ahora, con Ruby instalado, podemos instalar el Flash Policyd:

> wget http://www.lightirc.com/release/flashpolicyd.zip
> unzip flashpolicyd.zip
> cd flashpolicyd
> wget https://raw.github.com/ripienaar/flashpolicyd/master/flashpolicyd.rb --no-check-certificate -O flashpolicyd.rb
> chmod a+x flashpolicyd.rb

flashpolicyd (ambos archivos)

Ejecutamos:

 ./flashpolicyd.rb --xml flashpolicy.xml --logfile flashpolicyd.log

 

 

Pure-FTPd: PassivePortRang para controlar los puertos utilizados por el demonio y firewalling

Es simple: no quiero que el demonio de FTP haga random en un puerto cualquiera para las conexiones pasivas (osea, las normales de cualquier cliente ftp)

nano /etc/pure-ftpd.conf

# Port range for passive connections replies. – for firewalling.

PassivePortRange 30000 35000

Extracto de Readme de CSF (ConfigServer Security & Firewall (csf))

13. A note about FTP Connection Issues
######################################

It is important when using an SPI firewall to ensure FTP client applications
are configured to use Passive (PASV) mode connections to the server.

On servers running Monolithic kernels (e.g. VPS Virtuozzo/OpenVZ and custom
built kernels) ip_conntrack and ip_conntrack_ftp iptables kernel modules may
not be available or fully functional. If this happens, FTP passive mode (PASV)
won't work. In such circumstances you will have to open a hole in your firewall
and configure the FTP server to use that same hole.

For example, with pure-ftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/pure-ftpd.conf and then restart pure-ftpd:
PassivePortRange	30000 35000

For example, with proftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/proftpd.conf and then restart proftpd:
PassivePorts	30000 35000

FTP over SSL/TLS will usually fail when using an SPI firewall. This is because
of the way the FTP protocol established a connection between client and server.
iptables fails to establish a related connection when using FTP over SSL
because the FTP control connection is encrypted and so cannot track the
relationship between the connection and the allocation of an ephemeral port.

If you need to use FTP over SSL, you will have to open up a passive port block
in both csf and your FTP server configuration (see above).

Perversely, this makes your firewall less secure, while trying to make FTP
connections more secure.

Ahora, desde el CSF, habilitamos el rango de puertos:
/etc/csf/csf.conf
TCP_IN = «22,21,20,30000:35000»

Solo es necesario en el IN … porque el OUT, el servidor usa el 21 y el 20.

Joya, con esto aseguramos el FTPd.

Amaro.

Cambiar de Kernel de OVH a CentOS original…

Los tipo de OVH cuando instalas CentOS te meten un kernel de ellos…
Esto complica un poco el tema de la seguridad (No permite instalar CSF que utiliza: xt_connlimit ) en el servidor y su estabilidad: prefiero utilizar el orishinal que ya conozco su buen funcionamiento.

uname -r
3.2.13-grsec-xxxx-grs-ipv6-64

Este es el kernel de ellos.. para cambiarlo:

yum install kernel

Vamos a ver, se creo en /boot:

initramfs-2.6.32-431.20.3.el6.x86_64.img
vmlinuz-2.6.32-431.20.3.el6.x86_64

Ejecutá esto en el terminal:
cd /boot/grub
cp grub.conf grub.conf.bak | echo ‘Backup del archivo de conf hecho’

Ahora, ATENCION:

root@master [~]# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/md2 / ext3 errors=remount-ro 0 1
/dev/md3 /home ext3 defaults 1 2
/dev/sda4 swap swap defaults 0 0
/dev/sdb4 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
root@master [~]

/dev/md2 —> es nuestro punto de montaje de /
entonces, a tener en cuenta. Vamos a modificar el grub.conf ahora….

nano /boot/grub/grub.conf

Tiene que quedar así:

default=0
timeout=5
title linux centos6_64
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.20.3.el6.x86_64 root=/dev/md2
initrd /boot/initramfs-2.6.32-431.20.3.el6.x86_64.img

Listo… dale: shutdown -r now
Cuando reinicie….

root@master [~]# uname -r
2.6.32-431.20.3.el6.x86_64
root@master [~]#

Joya, tenemos el kernel original de CentOS, ready to ride.

Best Regards… Amaro

 

 

DSO VS. CGI VS. SUPHP VS. FASTCGI, Diferencias entre los manejadores de PHP

Esto es interesante para saber como se debe definir los manejadores en el servidor… Según pa que se va a usar…

Una de las cosas más importantes que debe hacer un buen administrador de sistemas es adaptar el software al entorno al que está destinado, porque no tiene las mismas necesidades un servidor dedicado a sistemas de blogs que uno dedicado a streaming de vídeo o a juegos online, cada uno ha de ser configurado de la forma más óptima para su entorno.

En entornos de hosting compartido la configuración se adapta con el objetivo de satisfacer las necesidades de la mayoría de los usuarios, pero en un servidor dedicado, resulta fundamental una configuración óptima, por lo que vamos a ver las diferencias entre los handlers.

Un detalle importante es que podemos asignar un handler diferente a cada versión, de forma que podríamos tener PHP 5 con un handler de CGI y PHP 4 con un handler DSO. Vamos a ver las diferencias entre ellos.

DSO

DSO, también conocido como mod_php, cuyas siglas significan “Dynamic Shard Object”. Está considerada como la configuración más rápida, ejecutando PHP como un módulo de Apache, lo que conlleva que todos los scripts se ejecutan con el usuario “nobody”.

El problema del usuario “nobody” es que si un hacker ejecuta un exploit de PHP puede conseguir acceder a otras áreas del sistema donde el usuario “nobody” pueda tener acceso, por lo que resulta un sistema altamente vulnerable en hosting compartido o donde varios usuarios tienen acceso.

Todos los ficheros creados con un script de PHP no serán accesibles desde la web, lo que significa por ejemplo, que si subimos una imagen mediante WordPress, no podremos acceder a ella. Esto conlleva un serio problema de permisos con casi todos los sistemas CMS.

DSO es indudablemente más rápido que el resto de handlers y tiene un consumo de CPU muy bajo, pero en cuentas de hosting compartido se desaconseja por completo su uso.

CGI

CGI, cuyas siglas significan “Common Gateway Interface”, ejecuta PHP como un módulo de CGI. Por desgracia, CGI también ejecuta los procesos de PHP como el usuario “nobody”, aunque si tenemos suEXEC habilitado, podremos ver que usuario ha realizado la petición.

Este método no es más rápido ni más seguro que DSO, simplemente existe para entornos donde DSO no es posible.

suPHP

suPHP o “single user PHP”, ejecuta PHP como un módulo de CGI, pero con la principal diferencia de que los usuarios ejecutan los procesos con su nombre y no con “nobody”, por lo que la seguridad es notablemente más elevada. suPHP es la configuración por defecto en entornos como cPanel y es la más recomendada para entornos con varios usuarios, ya que conocemos en todo momento quien está ejecutando cada script.

suPHP establece correctamente los permisos de los ficheros al subirlos desde algún script como WordPress. Además, si una cuenta es comprometida, no puede afectar al resto ya que no tendría permisos para efectuar dicha escalada en el servidor.

La contrapartida es que su consumo de CPU es alto en comparación a otros métodos, y no se pueden usar sistemas de cache como Xcache o APC.

FastCGI

FastCGI, también conocido como “mod_fcgid” o FCGI, es una variación de alto rendimiento de CGI. Tiene las ventajas y los beneficios de suPHP (cada usuario ejecuta los scripts con su nombre y no con “nobody”), además de reducir notablemente el consumo de CPU y ofrecer velocidades similares a DSO. Por último, es compatible con sistemas de caché como APC o eAccelerator.

La pega de FastCGI es un elevado consumo de memoria (cada petición permanece abierta de fondo, lo que permite que los sistemas de cache puedan funcionar), pero no debería ser un problema en los servidores actuales con grandes cantidades de memoria. Si dispones de gran cantidad de ella, es la opción más recomendada.

Cambios entre sistemas

Si se modifica el handler a FastCGI o suPHP, es necesario actualizar los permisos y la propiedad de los ficheros. Para ello se han creados scripts que lo realizan de forma automatizada, como este.

Comparativa

DSO CGI SuPHP FastCGI
Bajo consumo de CPU
Bajo consumo de memoria
Ejecuta PHP con su usuario

Sólo con suEXEC
Seguridad óptima