Editar y reinicar crontab vmware esxi

El otro dia estube cambiando el crontab en un esxi y me volvi loco porque no se ejecutaban las tareas, al final descubri que era debido a que despues de editar el crontab hay que reiniciar el servicio y no lo estaba haciendo.

Siendo tan sencillo como realizar los siguientes pasos:

Editamos el crontab:

vi /var/spool/cron/crontabs/root

Comprobamos el id del demonio / servicio crontab:

cat /var/run/crond.pid

Matamos el proceso:

/bin/kill $(cat /var/run/crond.pid)

Reiniciamos el servicio crontab (esxi 5.0 o menor)

/bin/busybox crond

Reiniciamos el servicio crontab (esxi 5.1en adelante)

/usr/lib/vmware/busybox/bin/busybox crond 

Comprobamos que el id del servicio crontab ha cambiado:

cat /var/run/crond.pid

Con estos sencillo pasos , podemos editar el crontab y actualizar el servicio asociado.

Configuración de un proxy inverso en Apache

Últimamente esas apareciendo numerosos servicios web que se ejecutan en puertos diferentes de los standar 80/443, grafana por el 3000, rpimonitor 8888, o el conocido del tomcat 8080.

Pues con esta entrada voy a explicar cómo hacer una redirección de puertos de una manera muy sencilla con el apache y los módulos proxy_module y proxy_http_module.

Editamos el fichero de configuración del apache y habilitamos los módulos, para sistemas centos / red-hat.

vi /etc/apache/conf/httpd.conf

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Para sistemas debian / ubuntu habilitamos con los comandos.

a2enmod proxy
a2enmod proxy_http

Y a continuación editamos el fichero del apache donde tengamos los host y configuramos el proxy para que apunta al puerto donde publiquemos la web (ej, grafana).

vi /etc/apache/conf/httpd.conf (centos / red-hat)
vi /etc/apache2/sites-enabled/000-default.conf (debian / ubuntu)

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

Reiniciamos el servidor apache y el grafana como en el ejemplo ya se publicara por el puerto 80.

Raspberry PI no arranca después de editar el fstab

Es sabido por todos que editar el fichero fstab conlleva su peligro ya que podemos dejar el sistema operativo inconsistente y no poder arrancarlo debidamente.

Y eso es lo que me paso intentando montar un recurso compartido en la raspberry PI obteniendo el siguiente error al arrancar el sistema operativo.

Cannot open access to console, the root account is locked.

Por suerte la raspberry PI ya viene preparada para estas posibles muñonadas y os voy a explicar cómo solucionarlo.

Montamos la tarjeta SD en otro equipo.

En el directorio boot editamos el fichero cmdline.txt añadiendo al final el arranque por línea de comandos.

init = /bin/bash

Volvemos a poner la SD en la raspberry PI y arrancamos obteniendo el control por línea de comandos.

Si Intentamos editar directamente el fichero /etc/fstab obtendremos el siguiente error:

mount: can't find PARTUUID=f2d3cb4f-02.

Y si intentamos montar la partición raíz “mount -o remount,rw /” no dará error de partición de solo lectura.

Lo que tendremos que hacer es montar parcialmente la partición que contiene el fichero /etc/fstab.

mount -o remount,rw /dev/mmcblk0p2 /

Ahora ya podremos editar el fichero /etc/fstab y devolverlo al estado anterior.

Ya solo nos faltara volver montar la SD para editar el fichero cmdline.txt y quitar el arranque por terminal.

Con estos sencillos pasos hemos recuperado la raspberry PI después de dejar un fstab inconsistente.

Deshabilitar el visual mode en vim

Los que llevéis tiempo usando linux, estamos familiarizados con el editor vim y sus magníficos atajos de teclado.

Seguramente habréis notado que en nuevas versiones de centos/debian cuando quieres pegar con el botón derecho del ratón no os lo permite y sale un horrendo mensaje que pone “visual mode”

El visual mode es una de las “mejoras” que se le puso al vim, pero para que los que seáis de la vieja escuela y no os gusten las moderneces, os voy a explicar cómo deshabilitarlo.

Creamos el fichero ~/.vimrc para el usuario en uso (si no existe) y añadimos set mouse-=a

Con el siguiente comando:

echo "set mouse-=a" >> ~/.vimrc

Con este sencillo comando desactivaremos el horrendo “visual mode” del vim, pudiendo realizarlo en cada uno de los usuarios que así lo deseemos.

Borrar kernels antiguos en centos 7

Es muy recurrente que despues de diversan actualizaciones del sistema operativo, se vaya quedando sin espacion el la partición raiz y no sabes de donde rascar para encontrar espacio, pues una de las maneras mas sencillas es borrando kernels antiguos.

Lo primero que haremos es instalar las yum-utils para hacer uso del package-cleanup.

yum install yum-utils

A continuación listamos las versiones sin uso del kernel.

[root@barrabinbarrabash]# rpm -qa|grep kernel
kernel-3.10.0-862.11.6.el7.x86_64
kernel-3.10.0-957.1.3.el7.x86_64
kernel-tools-3.10.0-1127.18.2.el7.x86_64
kernel-tools-libs-3.10.0-1127.18.2.el7.x86_64
kernel-3.10.0-1127.18.2.el7.x86_64
kernel-3.10.0-862.14.4.el7.x86_64
kernel-headers-3.10.0-1127.19.1.el7.x86_64
kernel-3.10.0-1062.4.3.el7.x86_64

Y lanzaremos el package-cleanup indicando el numero de versiones que deseamos mantener (en el ejemplo una).

package-cleanup --oldkernels --count=1

Con este habremos eliminado versiones del kernel sin uso y recuperado unos megas bien preciados.

Como solucionar el error: unable to negotiate wit port 22: no matching key exchange method found

Ya estamos con los errores atipicos, si te ha parecido alguna vez el error unable to negotiate wit port 22: no matching key exchange method found, voy a explicarte de manera sencilla como solucionarlo.

Esto es debido a que el origen y destino tienen diferentes librerias ssl y no puden realizar correctamente la negociación para la conexión ssh, saltano un error de este tipo.

[root@pruebas~]# ssh pruebas@192.168.1.2
unable to negotiate wit port 22: no matching key exchange method found. Their offer : diffie-hellman-group-exchange-sha1,diffie-hellman-group14-exchange-sha1, diffie-hellman-group1-exchange-sha1

La solucion es bastante sencilla y solo ahce falta añadir el cifrado del algoritmo a utilizar, como muestro en el ejemplo a continuación.

[root@pruebas~]# ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 pruebas@192.168.1.2

Solucionar error: cannot set groups operation not permitted

Si te ha aparecido este error cannot set groups operation not permitted en un centos 7, red hat 7 o parecido y no puedes loguear como root manten la calma que tiene solución.

Esto es debido a un “cambio accidental” en los permisos del fichero /bin/su, una de las tipicas burradas que permite hacer en linux y te puede meter en un buen lio.

La solución es tan facil como asignar los siguientes permisos especiales al fichero /bin/su:

chmod 4755 /bin/su 

Una vez cambiados los permisos quedaran de la forma siguiente pudiendo loguear sin problemas.

Vulnerabilidades SSL/TLS en Apache – corregir ataques POODLE / BEAST / SWEET32 y deshabilitar SSL

Escribo esta entrada para tener actualizado al día el apache de posibles ataques.

Comprobando con nmap el puerto 443, se puede ver como muchos apaches utilizan cifrados inseguros (incluso en sistemas robustos como centos 7).

Ejemplo:

nmap -p 443 --script ssl-enum-ciphers 192.168.1.2
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-27 08:59 Hora de ver. Europa Occidental
Nmap scan report for 192.168.1.2
Host is up (0.18s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher IDEA vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity

Como podemos ver, son unos cuantos los cifrados inseguros.

Para corregirlo lo que haremos es añadir estas dos directivas en el fichero de configuración del apache. (excluir cifrado ssl y cifrados vulnerables)

SSLProtocol ALL -SSLv2 -SSLv3
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL:!3DES:!MD5:!IDEA:!RC4:!DES:!DES40:!aNULL

Reiniciando el apache ya lo tendremos protegido de vulnerabilidades.

Rotar los logs de sistema en /var/log en linux

Los logs del sistemas se generan en el directorio /var/log, aquí se van guardando los accesos al sistema (secure), tareas de cron (cron), envíos de correo (maillog), eventos del sistema (messages), etc.

Y ya sea por falta de espacio, o por querer mantener un histórico, los sistemas vienen con la herramienta logrotate configurada.

En el fichero /etc/logrotate.conf , podemos ver la configuración standard, aquí un ejemplo de centos 7.

##/etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

En la configuración podemos ver como se ejecuta semanalmente (weekly), que se crea un fichero nuevo en cada rotado (create), etc

En el caso de no tener espacio con el comando /usr/sbin/logrotate -f /etc/logrotate.conf , podemos forzar la rotación y aliviar el espacio del sistema al comprimirse los ficheros generarse los nuevos.

Y en el caso de querer mantener un histórico de eventos, podemos programar en el crontab diariamente este pequeño script.

#!/bin/bash

### /home/admin/rotate_system_logs.sh

#Dia, mes anio
DAY=$(date +%d)
MONTH=$(date +%m)
YEAR=$(date +%Y)

#Directorio logs
LOGDIR="/var/log";

#Directorio historico logs
DESTDIR="/home/admin/system_logs/$YEAR/$MONTH/$DAY/";

# comprobar que existen los directorios destino y sino lo creamos
if [ ! -d $DESTDIR ]; then
        mkdir -p $DESTDIR
fi

#forzamos rotado logs
/usr/sbin/logrotate -f /etc/logrotate.conf

#mover los ficheros logs a directorio backup con fecha actual
mv -f $LOGDIR/*gz $DESTDIR

Cómo resetear contraseña root en CentOS 6 y 7

No es la primera vez que nos ha pasado (ni la ultima), que hemos olvidado la contraseña del usuario root.

Por eso con esta entrada voy a explicar a resetear la contraseña con unos sencillos pasos.

Lo primero que hareos es reiniciar el equipo y en la pantalla de seleccion de sistema operativo del grub, pulsaremos la tecla “e“, para entrar en el menu de edición.

Pulsamos “e”, en el menu del grub

Nos aparecere una pantalla como la siguiente:

Pantalla edición

Buscaremos la linea 16 donde aparece el sigueinte texto “ro

“ro” subrayado en amarillo

En este punto debemos cambiar el texto “ro” por lo siguiente:

 rw init=/sysroot/bin/sh

Debe de quedar como en la siguiente captura.

rw init=/sysroot/bin/sh subrayado en amarillo

A continuación pulsamos “ctrl + x“, para salir del menu de edición.

Accedemos al sistema con el siguiente comando:

chroot /sysroot

Y ya podemos cambiar la contraseña con el comando:

passwd root
Cambiamos contraseña root

Ahora ya tendriamos la contraseña cambiada y utilizando el comando “reboot“, ya podriamos utilizar la contraseña recien cambiada.