Desde hoy inicio una serie de post para la corrección de varias vulnerabilidades que se han presentado en las diferentes partes donde he trabajado. El propósito es seguir nutriendo el blog con más post como éstos, en la medida que me encuentre con más vulnerabilidades. Espero les sea de utilidad.

 

Vulnerabilidad: SSH Weak Algorithms Supported y SSH Server CBC Mode Ciphers Enabled

 

Descripción

 

Esto puede permitir que un atacante recupere el mensaje de texto claro del texto cifrado.

 

Solución

 

Para corregir las vulnerabilidades arriba escritas sobre Linux, se debe modificar el archivo /etc/ssh/sshd_config y agregar lo siguiente:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

Lo anterior se puede agregar al final del archivo o donde se encuentre el Ciphers. Una vez guardado el archivo se debe reiniciar el servicio de ssh. Dependiendo de la versión del S.O, se agregarán más opciones de cifrado o menos dependiendo el caso.

Saludos!!

 

 

Siempre hay una primera vez para todo y con IPv6 me tocó esa. Poco a poco se irá implementando en las compañías de todos los sectores y uno debe aprender a como convivir con éste protocolo. Les dejo como se hace la configuración de IPv6 en un servidor con Red Hat 7:

 

1. Chequear la conexión y las interfaces

 

# nmcli connection show 

 

2. Adicionar la dirección IPv6 a la interface que desees

 

# nmcli connection modify (interfaz_red) ipv6.addresses (IPv6)

 

#  nmcli connection modify (interfaz_red) ipv6.method manual

3. Se activa la conexión

# nmcli connection up (intefaz_red)

# nmcli connection reload

4. Verificar que haya quedado bien configurada la IPv6

# nmcli connection show (intefaz_red) | grep ipv6

5. Habilitar la interfaz para que inicie con el sistema operativo

# nmcli connection modify (intefaz_red) connection.autoconnect yes

6. Prueba haciendo ping a la IPv6

Saludos!!

El título lo dice todo, así que empecemos:

1. Crear en la ruta /etc/yum.repos.d el archivo de repolocal.repo o como lo quieran llamar.

2. Dentro del archivo agregar lo siguiente:

[InstallMedia]
name=Red Hat Enterprise Linux 7.2
#mediaid=1446216863.790260
metadata_expire=-1
gpgcheck=0
cost=500
enabled=1
baseurl=file:///media/cdrom/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

3. Guardar el archivo y darle: yum repolist para que cargue el nuevo repo

4. Montar la ISO o el cdrom en la ruta que dice el archivo. Después de ello, pueden instalar los paquetes que necesiten de la forma normal

Saludos!!

 

Jueputa Oracle RAC!

Si! Así y nada más... ¿y el por que de esa afirmación? Porque después de pasarme más de 5 horas tratando de sincronizar el servidor NTP para que Oracle RAC se dejara instalar... lo logré gracias a un consejo.

El problema empezó cuando uno de los DBA's que trabaja en un proyecto conmigo, necesitaba instalar Oracle RAC 12c en dos servidores. Se instalaron todas las cosas a nivel de sistema operativo que se necesitaban para instalar el producto de Oracle. Solo faltaba la sincronización del NTP y Oracle no la tomaba por el error que muestro en el título del post. Busqué en internet en las páginas de Oracle y otras y la solución que encontraba era detener el servicio del ntp, mira la hora en ambos nodos y arranca el servicio otra vez. Nada servía... hasta que una colega me dijo algo que no se me había ocurrido y así sincronizó el NTP con Oracle

 1. Como hay 2 nodos que se deben sincronizar con el servidor NTP, configura el ntp.conf con la IP del servidor principal NTP en el nodo1.

2. Dentro del nodo2, configura el ntp.conf el nombre o la IP del nodo1.

3. Reinicia el servicio ntp en ambos nodos, o si lo prefieren pueden reiniciar ambos servidores (si es que lo pueden hacer).

Con esa solución, pude sincronizar ambos nodos para que el DBA pudiera instalar el Oracle RAC.

Saludos!!

Hace varios minutos que estaba tratando de encontrar la solución al error que se muestra como título de éste post, hasta que al fin di con ella. El escenario era que desde el almacenamiento me presentaron una LUN de X GB de tamaño, ésta la descubrí y la logueé dentro del sistema con los comandos que trae el iSCSI. Se formateó como gfs2 y al tratar de montarla aparecía el error: /sbin/mount.gfs2: can't connect to gfs_controld: Connection refused

1. Lo primero que debemos hacer es chequear el nuevo disco con fsck

# fsck /dev/sda1

No tendría mucho sentido porque se acaba de formatear y es nueva pero de todas maneras se comprueba.

2. Al tratar de montarlo otra vez, aparece el mismo error:

 

3. El GFS2 utiliza un mecanismo de bloqueo para evitar colisiones. Éste mecanismo se necesita eliminar, ya que el servidor usa exclusivamente el disco presentado. Para ello ejecutamos:

 

4. Al tratar de montarlo nuevamente, nos saca el siguiente error:

5. El protocolo de bloqueo debería ser lock_nolock en vez de lock_none, entonces se realiza lo siguiente:

6. Ahora si, cuando se monta el filesystem lo deja pasar sin problemas:

Listo con ésto hemos dado solución al error comentado.

Saludos!!!

Sigo con OpenVas, ya que lo estoy utilizando muy amenudo en las tareas que estoy realizando. En uno de los trabajos que estoy haciendo la estoy usando sobre una máquina virtual Kali 2.0 y quería que no solo me pudiera conectar por la interfaz de Loopback... para hacerlo ésta es la solucion:

1. Detener los servicios de OpenVas

# openvas-stop

2. Configurar el OpenVas para que escuche por cualquier interfaz

# gsad --listen=0.0.0.0

3. Iniciar OpenVas

# openvas-start

Una vez haya iniciado, conectarse por cualquier navegador hacia la IP que tiene asignada el Kali Linux por el puerto de eschucha por default: https://IP-Kali 

Esta solución deja de funcionar cuando apagues la máquina Kali. Cuando vuelvas a encenderla debes hacer el mismo procedimiento.

Saludos!!

Hola a Todos!!!!

Hace rato que no escribo en el blog por estar ocupado... pero aprovecho el tiempo libre para publicar lo que me pasó hace poco. 

Estoy haciendo labores de hacking para un cliente y al momento de escanear con OpenVas me sacaba el siguiente error: Code: 503 Status message:Scanner loading nvts. Buscando en Internet encontré la siguiente solución:

1. Detener el escaner

systemctl stop openvas-scanner

2. Dentro del archivo /etc/openvas/openvassd.conf agregar la siguiente línea:

"log_plugins_name_at_load = yes" to 

3. Iniciar el escaner y mirar los logs del openvas para ver si comienza a realizar el escaner

tail -f /var/log/openvas/openvassd.messages  

Espero les sirva de ayuda...Saludos!!

Si es para mejorar, los cambios siempre serán buenos. Una vez más llegó el momento de renovar el blog y volverlo más profesional a como inició hace más de 5 años.

Como se dan cuenta es un nuevo aspecto donde se presenta la información más estética y de forma distinta a como estaba antes. Un detalle a mencionar es que en la página principal no aparece a simple vista la opción de buscar; ésta opción se encuentra en la parte superior izquierda como un ícono cuadrado con rayas:

 

Cuando se accede a cualquiera de los artículos, si aparece el botón de buscar a mano derecha. Espero sea de su agrado.

Saludos,

Estas vainas pasan cuando uno menos piensa. El resumen del problema es que tenía un servidor virtual el cual tiene varios discos presentados por VMWare. De un momento a otro, el S.O dejó de ver los discos a pesar de que los mostraba con un df -h. Se hicieron varias cosas y al final se quitaron los discos del VMWare dejando solo el del S.O... la máquina subió y se volvieron a añadir los discos por VMWare. 

Reescané los discos y se mostraron en el S.O. Al momento de hacer un lvscan mostraba lo siguiente: 

Después de mucho estudiar y gracias a la oportunidad que he tenido de trabajar con Linux desde hace tiempo... hoy puedo confirmar que me he certificado como Administrador de Sistemas en Red Hat versión 7. Mucho ha cambiado de las versiones 6 hacia abajo, sobretodo con el Systemd que viene a reemplazar al SystemV.

 

Advanced exploitation toolkit

Kali Linux is preloaded with some of the best and most advanced exploitation toolkits. The Metasploit framework (http://www.metasploit.com) is one of these. We have explained it in a greater detail and presented a number of scenarios that would effectively increase the productivity and enhance your experience with penetration testing.

El siguiente post es una solución a varios problemas que se me presentaron después de la instalación de la herramienta Bacula. Para saber como instalarlo en Linux, te puedes guiar de este enlace. 

Internet of Things (IoT) o Internet de las Cosas es un concepto que se refiere a la interconexión digital de objetos cotidianos con internet. Alternativamente, Internet de las cosas es el punto en el tiempo en el que se conectarían a internet más “cosas u objetos” que personas (Tomado de Wikipedia). Tenía en mente escribir sobre este tema, que se está afianzando cada día más en los productos que compramos de cualquier categoría; ya sean electrodomesticos, relojes, celulares (hace tiempo), etc. 

En estos días estuve montando un NFS (Network File System) sobre linux y a la hora de hacer el montanje desde el cliente me apareció el error que se ve en el título del post. La razón del error es que el FW interno del S.O esté bloqueando los puertos que usa el NFS.  ¿Como solucinarlo? Lo siguiente te puede ayudar y se hizo sobre RHEL:

En el servidor:

1. Edita el fichero /etc/sysconfig/nfs y descomenta las siguientes líneas:

LOCKD_TCPPORT=32803 

LOCKD_UDPPORT=32769 

MOUNTD_PORT=892 

STATD_PORT=662 

STATD_OUTGOING_PORT=2020

2. Reinicia los servicios de nfs

# /etc/init.d/nfs restart

# /etc/init.d/nfslock restart

3. Miramos si los puertos están abiertos: rpcinfo -p localhost

4. Editamos el archivo /etc/sysconfig/iptables, añadimos los siguientes puertos y reiniciamos el firewall para que tome los cambios:

-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 32769 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 32803 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 892 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 892 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 875 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 875 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 662 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 662 -j ACCEPT

# /etc/init.d/iptables restart

Del lado del cliente:

Montamos el filesystem compartido

# mount -a 

Con estos pasos hemos solucionado el problema presentado:

Hay que aclarar que para esta configuración, ya se tiene instalado y configurado el esquema de compartir archivos por NFS y que a la hora de montar el filesystema les ocurre el error que se comenta en el post.

Espero les sirva de ayuda

Saludos!!!

Fuente: http://notepad2.blogspot.com/2012/04/mountnfs-mount-to-nfs-server-failed.html