linux

Enjualar usuario SFTP en un directorio en modo lectura en centos.

por

Escribo esta entrada que me surge por la necesidad de tener un usuario SFTP enjaulado en un directorio y que solo pueda acceder a los ficheros en modo lectura.

He encotrado muchos tutoriales en internet de como enjaular usuarios SFTP y como gestionar directorios en modo lectura, pero ninguno que fusioanara ambas opciones, con lo que paso a explicarlo en esta entrada.

Para realizar el tutorial es necesario tener instalado el openssh-server, que viene en casi todas las distribuciones linux, de no estar instalado se puede instalar con este comando.

yum –y install openssh-server
  1. Creamos el grupo SFTP que gestionara los accesos
groupadd sftp

2. Creamos el directorio SFTP y el directorio del usuario y los permisos adecuados.

##directorio sftp
mkdir /var/sftp
chgrp sftp /var/sftp
chmod 750 /var/sftp/

##directorio usuario sftp
mkdir /var/sftp/prueba
chmod 770 /var/sftp/prueba
chgrp sftp /var/sftp/prueba

3. Creamos el usuario prueba, añadiendolo al grupo sftp, sin accesos shell y con el home del directorio creado.

useradd -g sftp -s /bin/false -d /var/sftp/prueba prueba ; echo "Password" | passwd --stdin prueba

4. Editamos la configuracion del ssh ( /etc/ssh/sshd_config ), donde cambiamos el modo SFTP sftp-server por internal-sftp ( Subsystem sftp internal-sftp ), añadimos el grupo sftp ( Subsystem sftp internal-sftp ), asignamos el directorio del SFTP ( ChrootDirectory /var/sftp ) y configuramos el SFTP en modo solo lectura ( ForceCommand internal-sftp -R ).

vim /etc/ssh/sshd_config

# Comentamos original
### Subsystem       sftp    /usr/libexec/openssh/sftp-server

# Add sftp group. directory. only read
    Subsystem sftp internal-sftp
    Match group sftp
    ChrootDirectory /var/sftp
    ForceCommand internal-sftp -R

5. Reiniciamos el servicio ssh.

service sshd restart

6. Comprobamos a conectarnos con cualquier sofware SFTP (como winscp) y vemos como funciona correctamente.

Acceso SFTP solo lenctura

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

por

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

por

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.

Configurar DKIM para prevenir el spoofing de correo electrónico, con opendkim, postfix y centos7

por

DKIM (DomainKeys Identified Mail) es un método para firmar correos electrónicos utilizando una clave pública-privada.

DKIM se utiliza al recibir el servidor de correo para identificar el correo electrónico, que son enviados por servidores de correo autorizados, minimizando la posibilidad de recibir correos electrónicos SPAM.

Con este tutorial voy a explicar como realiziar en centos7 con postfix y opendkim.

Instalamos el software necesario.

yum install postfix opendkim

Ahora creamos la pareja de claves DKIM (publica y privada) utilizando el comando opendkim-genkey proporcionada por el paquete dkim-milter, con el dominio y selector a utilizar.

mkdir -p /etc/opendkim/keys/barrabinbarrabash.es
cd /etc/opendkim/keys/barrabinbarrabash.es

opendkim-genkey -r --domain=barrabinbarrabash.es --selector=barrabinbarrabash

Ahora asignamos los permisos correctos a la pareja de claves.

chown -R opendkim:opendkim /etc/opendkim
chmod go-rw /etc/opendkim/keys

Editamos el archivo de configuración /etc/opendkim.conf y agreguamos / actualizamos las siguientes lineas.

vim /etc/opendkim.conf
Mode     sv
Domain barrabinbarrabash.es
#KeyFile      /etc/opendkim/keys/default.private
KeyTable        /etc/opendkim/KeyTable
SigningTable   refile:/etc/opendkim/SigningTable
ExternalIgnoreList    refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts

Luego edite el archivo de configuración de listas de claves de dominio /etc/opendkim/KeyTable y agregamos el dominio y la clave privada creada.

vim /etc/opendkim/KeyTable

barrabinbarrabash._domainkey.barrabinbarrabash.es barrabinbarrabash.es:barrabinbarrabash:/etc/opendkim/keys/barrabinbarrabash.es/barrabinbarrabash.private

A continuación, editamos el archivo /etc/opendkim/SigningTable añadiendo el dominio a utilizar.

vim /etc/opendkim/SigningTable

*@barrabinbarrabash.es barrabinbarrabash._domainkey.barrabinbarrabash.es

Editamos el archivo /etc/opendkim/TrustedHosts y añadimos el dominio autorizado.

vim /etc/opendkim/TrustedHosts

barrabinbarrabash.es

Ahora edite el archivo de configuración POSTFIX /etc/postfix/main.cf, habilitando el opendkim.

vim /etc/postfix/main.cf

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

Para finalizar la configuración arrancamos el servicio opendkim y reiniciamos postfix.

service opendkim start
postfix restart

Por ultimo solo nos faltaria incluir la entrada de dominio con la clave publica para validar los correos firmados.

cat /etc/opendkim/keys/barrabinbarrabash.es/barrabinbarrabash.txt
 
barrabinbarrabash._domainkey       IN      TXT     ( "v=DKIM1; k=rsa; s=email; "
          "p=dEp+wJKP+VUbhc9GigmK34ZjrSqqdKjIEWr2q9QEBAQUAA4GNADCBiQKBgQCdTtV/L65Gqm/rvBz1d6CCp8A2515DvSVp1H1bZs4t050mMA0GCSqGSIbGNADCBic9GigmK34ZjrSqqdKjIEWrQKBgQCdTtEqM8FqndiFYOderzljMMMqBdEp+wJKP+VUbhc9GigmK34ZjrIAocOD6pKDAQAB" )  ; ----- DKIM key barrabinbarrabash for barrabinbarrabash.es

Como solucionar el error al usar yum: “There was a problem importing one of the Python modules required to run yum.”

por

Estaba yo intentendo instalar com yum mi amado vim y me salto ese terror: “There was a problem importing one of the Python modules required to run yum.”

[root@pruebas~]# yum install vim
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   No module named yum

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.6

Total que me puse a investigar y se debia a que habia actualiza la version de python y no reconoce el modulo yum.

La solucion es bastante sencilla, buscamos con un whereis python las diferentes versiones de python instaladas.

[root@pruebas~]# whereis python
python: /usr/bin/python2.6 /usr/bin/python /usr/lib/python2.6  /usr/local/bin/python /usr/include/python2.6 /usr/share/man/man1/python.1.gz

Ahora sabiendo donde se encuentra la ruta del binario del python que necesitamos (en el ejemplo 2.6), bastara con indicarselo en el binario /usr/bin/yum .

vi /usr/bin/yum
#!/usr/bin/python2.6

Como solucionar error, Device eth0 does not seem to be present, delaying initialization

por

Dolores de cabeza me ha dado este error, hasta que pude dar con la solución.

Siempre me ha aparecido copiando maquinas virtuales de centos 6, pero a saber en cuantas ocasiones se puede dar.

Es debido que al copiar una maquina virtual y querer asignar otra ip, el s.o chifla con la mac de la interface de red, apareciendo el siguiente error, al hace el service network start

error Device eth0 does not seem to be present

El causante es el fichero /etc/udev/rules.d/70-persistent-net.rules , que no actualiza la mac nueva y muestra la anterior.

Fichero: /etc/udev/rules.d/70-persistent-net.rules

La solucion es tan sencilla como borrar el fichero y reiniciar el sistema operativo.

rm /etc/udev/rules.d/70-persistent-net.rules y reboot

Y con esto conseguimos que el centos pueda arrancar la interface de red

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

por

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

por

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

por

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.

Cómo solucionar el error “Too many open files (errno: 24) “o “Can’t open file (errno: 24)” de MySQL

por

Se trata de un error bastante común y a la vez un buen quebradero de cabeza.

Esto es debido a que que mysqld está tratando de mantener abiertos demasiados archivos simultáneamente.

Para resolverlo basta con modificar el numero de ficheros abiertos en la variable open_files_limit.

Primero realizaremos la siguiente consulta pra saber cual es el limit actual:

SHOW VARIABLES LIKE 'open%';

Pongamos que nos devuelve 20000, pues lo que haremos sera modificar el limite a 40000.

Primero lo haremos editando el fichero de configuración de mysql /etc/my.cnf :

[mysqld]
open_files_limit = 40000

Después editamos el fichero del sistema, /etc/security/limits.conf  y añadimos el mismo límite :

mysql soft nofile 40000
mysql hard nofile 40000

A continuación reiniciamos el servicio mysql, y el error dejara de mostrarse y solo habra que cambiar la configuración segun las necesidades de la aplicación.