Plesk, seguridad, Proxmox, cloud, Manuales, tips, Servidores, scripts bash, sysadmin, Linux, Centos, Ubuntu, MySQL,
Si detectectamos en el servidor Linux con CentOS y notas que tienes muchos procesos del tipo:
/var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/
Es posible que el servidor no resuelva correctamente las DNS de los dominios, por lo cual el sistemas de listas negras tarda mucho en cerrarse y se acumulan los procesos.
Continuar leyendo «Error en Qmail con demasiados procesos /var/qmail/bin/relaylock»
Mediante los túneles SSH podemos asegurar casi todo tipo de protocolos, al conectarnos a una red insegura, como puede ser la red WiFi de un hotel, restaurante o las típicas redes públicas que algunos ayuntamientos ofrecen de forma gratuita (que por cierto, no sé cuanto durará), estamos expuesto a diferentes ataques por parte de otros usuarios conectados a la misma red.
El escenario por norma general es poner la tarjeta en modo “promiscuo” y estar mirando todos los paquetes que pasan por nuestra tarjeta de red, que puede tratarse de información sensible, desde usuarios y claves hasta números de cuentas bancarias.
Para éste ejemplo he usado un servidor VPS de tipo “budget” (precios bajos – prestaciones bajas) para realizar el artículo. Lo primero será asegurarnos de que el servidor SSH, en mi caso OpenSSH, está correctamente configurado para soportar los túneles.
Procedemos a mirar la configuración del servicio SSH en /etc/ssh/sshd_config y buscamos las siguientes directivas:
AllowTcpForwarding yes GatewayPorts yes TCPKeepAlive yes
Donde el primer parámetro activa el redireccionamiento y encapsulación de los diferentes protolocos basado en TCP y el segundo hace que la conexión se mantenga de forma continua, normalmente después de un tiempo, que suele ser aproximadamente unas dos horas, la conexión TCP se desconecta de forma automática.
Una vez editado el fichero de configuración, procedemos a reiniciar el servicio:
/etc/init.d/ssh restart
En otros sistemas operativos como CentOS, los demonios se encuentran en rc.d.
El siguiente paso es conectarnos y crear el túnel en el puerto que pasaremos como argumento al cliente ssh:
>ssh -D 8080 mad@servidor-personal.com
Con el comando de arriba, estamos creando un túnel en el puerto 8080 de nuestro propio equipo hacia el servidor SSH. Si queremos aprovechar el puerto y navegar de forma segura, tendremos que configurar nuestro navegador para al conectarse a los servidores web, use como servidor SOCKS nuestro propio equipo local y el puerto 8080.
Por ejemplo en Firefox se hace en la Configuración de Red:
Después de guardar los cambios, es recomendable reiniciar el navegador. El proceso es similar en la mayoría de los demás navegadores, para crear el túnel SSH, si estamos en Windows, en la parte final de artículo encontrarás otros artículos de apoyo para hacerlo desde Windows mediante el cliente SSH PuTTy.
Podemos ver un claro ejemplo si empleamos un sniffer, en éste caso WireShark, las diferencias entre el envío de datos cifrados y en claro.
En el ejemplo de arriba los datos están cifrados, mientras que en el de abajo no.
El uso de túneles no se limita sólo al ámbito web, podemos tunelizar cualquier protocolo, si queremos acceder de forma segura a nuestro servidor de correo, también podemos tunelizar POP, SMTP, IMAP y demás.
ssh -f usuario@servidor-personal.com -L 2000:smtp.gmail.com:25 -N
En éste ejemplo, estamos haciendo un túnel desde el puerto 2000 del servidor-personal al puerto 25 del servidor SMTP de gmail.com. El uso es ilimitado, sólo depende de nuestra imaginación.
Recursos y Documentación:
_SSH Port Forwarding [Symantec]
_Port Forwarding [The SSH Definitive Guide]
_How to tunnel Web Traffic with SSH Secure Shell [Using PuTTy]
_Breaking Firewalls with OpenSSH and PuTTy
Nota:
No hace falta tener un VPS o un servidor dedicado, podemos usar nuestro propio equipo que tenemos en casa, claro está, que habrá que mantenerlo encendido continuamente.
Podeis usar tambien una shell gratuita, yo uso la de http://shellmix.com
Con la necesidad de hacer un script en bash, me ví con la obligación de hacer una conexion ssh y no queria que me pidiera contraseña cada vez que lo ejecutara.
Tenia la opcion por claves publicas y privada pero creo que iba a perder mucho tiempo, asi que opte por la siguiente:
Nos bajamos el paquete llamado sshpass de sourceproject
wget http://heanet.dl.sourceforge.net/project/sshpass/sshpass/1.05/sshpass-1.05.tar.gz tar xvf sshpass-1.05.tar.gz cd sshpass-1.05 ./configure make sudo make install
Ahora una vez instalado sshpass en nuestro sistema o servidor, la sentencia para conectarnos a ssh es la siguiente:
sshpass -p 'passwd' ssh root@192.168.1.54
Este procedimiento deberia funcionar en las distribuciones RedHat Linux 7.x/9, RHEL, Fedora y CentOS sin problemas porque todas tienen similar configuración. El objetivo es nunca reiniciar sin necesidad y mantener el tiempo de uptime del servidor intacto y por supuesto no interrumpir los otros servicios.
nano /etc/sysconfig/network
HOSTNAME=central
nano /etc/hosts
192.168.0.1 centralhostname redhat9hostname
service network restart
Rápido, sin problemas y no interrumpimos los servicios del servidor ni tampoco perdemos el uptime de nuestro servidor.
Cuando utilizamos MySQL es común optimizar tablas con muchos registros con cierta periodicidad, esto para solventar problemas de fragmentación, entre otros. La verdad esta es una de las cosas del modelo de PostgreSQL que echo en falta, quizás no es tan «amigable» pero todo queda claro desde el inicio.
En PostgreSQL hay un proceso de aspiradora (vacuum) que va eliminando periódicamente registros inutilizados en tablas, su configuración, pan nuestro de cada día para un admin de BBDD que debe ajustarlo con frecuencia.
Bueno…. Volviendo a MySQL, si necesita optimizar tablas InnoDB, lo mejor que puede utilizar son ALTER nulos, estas son instrucciones DDL de tipo ALTER sin parámetros que permiten seguir trabajando con las BBDD, porque realiza copias temporales en disco. La cuestión es que esta herramienta «reconstruye» la tabla y elimina, entre otros, los problemas de fragmentación.
Aquí les dejo un script para optimizar de «un sólo golpe» varias tablas InnoDB:
#!/bin/bash
if [ $# -lt 2 ]; then
echo "You must specify database host"
echo "Eg. script.sh MY_DATABSE 192.168.10.1"
exit
fi
db="$1"
host="$2"
user="root"
declare -a tables=(Table1 Table2 Table3)
stty -echo
read -p "Enter MySQL's Admin password: " password
stty echo
for table in ${tables[@]}; do
echo $table &&
time mysql -u $user --password=$password -h $host $db -e "ALTER TABLE $table ENGINE=INNODB"
done
Básicamente optimizamos las tablas especificadas (en un arreglo) e imprimimos el tiempo que toma cada instrucción (time).
Si tiene la certeza de que todas las tablas de una BD son InnoDB y quiere optimizarlas todas aún más rápido, puede hacerlo valiéndose del comando «show tables»…
#!/bin/bash
if [ $# -lt 2 ]; then
echo "You must specify database host"
echo "Eg. script.sh MY_DATABSE 192.168.10.1"
exit
fi
db="$1"
host="$2"
user="root"
stty -echo
read -p "Enter MySQL's Admin password: " password
stty echo
mysql -u $user --password=$password -h $host --batch --skip-column-names $db -e "SHOW TABLES" |
while read table; do
echo $table &&
time mysql -u $user --password=$password -h $host $db -e "ALTER TABLE $table ENGINE=INNODB"
done
La única diferencia es que las tablas ya no son especificadas a través de un arreglo (que recomiendo para BBDD grandes, donde optimizar todas las tablas podría demorar toda la vida), sino que se toman directamente del comando «SHOW TABLES» para una BD especificada.