Recuperar contraseña de root en FreeBSD
Ya no recuerdo cuántos posts de recuperación de contraseña he escrito, se ve que es bastante común que me equivoque al cambiarla…
Por suerte, el procedimiento con FreeBSD es extremadamente sencillo. Sólo basta con iniciar el sistema en modo monousuario, elegir la terminal a ejecutar (por defecto es /bin/sh) y luego:
# mount -a # passwd # reboot
Eso sí, siempre es conveniente recordar la contraseña que se ingresó, para no volver a tener que pasar por el mismo proceso!
Problema con CentOS y OpenSSL
Intentando habilitar HTTPS en el servidor web me encontré con el siguiente problema:
(network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
Los certificados estaban bien, el servidor contaba con soporte para SSL, la librería de SSL estaba instalada. Todo el chequeo de rutina se veía bien. Al buscar en Internet me encontré con que aparentemente el problema estaría asociado a la versión 5_4.6 de OpenSSL en CentOS. Cuando chequeé mi sistema esa era la versión que estaba utilizando.
Por fortuna, la solución es bastante sencilla y se puede resumir en los siguientes pasos:
- Eliminar las dependencias del paquete openssl-0.9.8e-12.el5_4.6.i686.
- Instalar el paquete openssl-0.9.8e-12.el5_4.1.i686.
En mi caso, la única dependencia del paquete mencionado era openssl-devel.i386, paquete que, como no necesitaba, eliminé del sistema. Luego, simplemente instalé el anterior paquete de openssl con el siguiente comando:
rpm -Uhv --force openssl-0.9.8e-12.el5_4.1.i686.rpm
He decidido subir al servidor de NetStorming el paquete tanto para la arquitectura i386 como para la arquitectura x86_64. No probé en x86_64, pero presumo que la solución debe funcionar de la misma manera; de lo contrario agradecería que me lo hicieran saber.
Lista negra de phishers con Postfix
El problema
En el lugar donde trabajo nos ocurrió que desde hace un tiempo al día de hoy recibimos muy seguido mails solicitando nombre de usuario y contraseña de nuestras casillas de correo. Desde el punto de vista del usuario, responder este tipo de mails suministrando los datos reales es peligroso porque se facilita el robo de identidad; desde la óptica del administrador del equipo se abre una puerta para realizar spam.
Como administrador de un servidor de mail, es posible aprovechar dichos correos para que las cuentas de nuestros usuarios no sean vulneradas. Por ello, comparto con ustedes la solución que encontramos con un compañero que, si bien no es el remedio definitivo para estos problemas, sí se la puede utilizar como un medio para minimizar los casos éxitosos del atacante.
La solución
La solución de la que les hablo consiste básicamente en interceptar los mails que los usuarios respondan de manera que nunca lleguen a destino. Para ello son necesarias dos cosas:
- Crear una lista con las direcciones de mail de los phishers: esto se puede hacer obteniendo el campo reply-to de los mails que se reciben solicitando información sensible. En este punto, el administrador puede incorporar cada dirección a mano o buscar la forma de automatizar el proceso.
- Interceptar los mails dirigidos a dichas direcciones: para ello, a la lista creada es necesario indicarle la cuenta a la cuál se quiere redirigir los mails. Luego hay que incorporar dicha lista en Postfix.
Manos a la obra
Crear la lista negra con direcciones y la cuenta a la cuál se redigirán:
vi /etc/postfix/blacklist dir1@example.com phishers dir2@example.com phishers
Generar, a partir de dicho archivo, la Berkeley DB que utilizará Postfix.
postmap /etc/postfix/blacklist
El comando anterior dejará como resultado un archivo con extensión .db en el mismo directorio donde se encuentra el fuente:
file /etc/postfix/blacklist.db /etc/postfix/blacklist.db: Berkeley DB (Hash, version 8, native byte-order)
Luego, indicarle a Postfix que lea dicha lista:
vi /etc/postfix/main.cf virtual_alias_maps = hash:/etc/postfix/blacklist
Ahora bien, al armar la lista redirigimos los mails que van a cada dirección de mail de un phisher a una cuenta especial llamada phishers. Esa cuenta puede ser uno de tres casos:
- Una cuenta en el sistema.
- Un alias a la cuenta del administrador.
- Una redirección a /dev/null.
De las opciones anteriores, la ventaja de la primera o la segunda es que si el administrador recibe un mail donde ve que un usuario contestó con sus datos puede ponerse en contacto con el mismo para aconsejarle cómo actuar en esa situación y así evitar que la misma se vuelva a repetir. No obstante, con una redirección a /dev/null y un análisis de los logs podría lograrse el mismo resultado de forma menos invasiva. Optaremos en este caso por la última opción y por ello agregaremos la entrada phishers a los alias de Postfix.
vi /etc/aliases phishers: /dev/null
Regenerar la base de datos de los alias.
newaliases
Finalmente es necesario reiniciar Postfix para que lea la nueva configuración por los cambios efectuados en /etc/postfix/main.cf. A partir de este momento, cada vez que se tenga una nueva dirección de correo de un phisher bastará con agregarla a la lista negra y ejecutar el comando postmap.
Firewall en Mac OS X (parte 1)
Todos los usuarios nuevos de Mac OS X acostumbrados a trabajar con Linux probablemente sientan como yo la falta de control sobre el firewall utilizando la aplicación gráfica incluida en el sistema. Incluso peor si les gusta trabajar en modo texto. Pero a no desesperar, porque el firewall en Mac OS X puede ser administrado vía ipfw. El uso de la herramienta y la construcción de un firewall elemental serán el objeto de este post.
Sintaxis y funcionamiento de IPFW
IPFW funciona de la misma manera que iptables en el sentido que si un paquete matchea con una regla es procesado en base al criterio de la misma y se analiza el siguiente paquete. Por tal motivo, existe una regla especial que está hardcodeada en el firewall de Mac OS X que permite todo el tráfico IP en todas las direcciones. La misma puede verse teniendo incluso el firewall desactivado:
sh-3.2# ipfw list 65535 allow ip from any to any
El comando ipfw con argumento list nos muestra todas nuestras reglas de firewall. Se ve allí que la regla anterior permite todo el tráfico IP con cualquier origen y destino. Algo curioso a notar es el número al principio. Cada regla tiene un número que indica su posición y le da orden a las mismas. Este número puede especificarse manualmente o de forma automática, siendo 65535 el más alto (es decir que la regla anterior va a quedar siempre al final). La forma básica de una regla es la siguiente:
[orden] acción [log] protocolo from origen to destino [interface-spec]
Escribiendo un firewall con IPFW
Ahora bien, luego de haber visto cómo funciona IPFW y cuál es la sintaxis del comando nos abocaremos a escribir un conjunto de reglas utilizándolo. Las reglas que escribiremos serán las correspondientes a:
Permitir todo el tráfico local (de la propia máquina) Permitir todo el tráfico saliente Permitir el tráfico entrante para las conexiones establecidas Permitir el ping a la máquina Permitir el acceso SSH a la máquina Denegar todo el resto del tráfico entrante
Lo cuál, traducido en reglas de IPFW queda de la siguiente manera:
ipfw add 00900 check-state ipfw add 01000 allow ip from any to any via lo* ipfw add 01010 allow ip from any to any out ipfw add 01020 allow tcp from any to any established ipfw add 01030 allow udp from any to any keep-state ipfw add 01040 allow icmp from any to any in ipfw add 01050 allow tcp from any to any dst-port 22 in ipfw add 30000 deny ip from any to any
Ahora bien, en los comandos de arriba se puede interpretar lo siguiente:
- La primer línea le indica al firewall que deseamos que mantenga estados para las conexiones. De esta manera, al generar una conexión saliente se generará una regla de manera dinámica que permitirá la respuesta de la misma. Para ello nos valemos luego de las palabras established y keep-state, la primera para TCP y la segunda para UDP.
- La segunda línea permite todo el tráfico local.
- La tercer línea permite todo el tráfico saliente de la máquina.
- La cuarta y quinta línea indican explícitamente que se desea mantener el estado para las conexiones que sean TCP y UDP.
- La sexta línea permite el ping a la máquina y la séptima el SSH.
- La última línea deniega todo el resto del tráfico, sea entrante o saliente, que no haya coincidido con alguna de las reglas anteriores.
Finalmente, si se deseara eliminar todas las reglas de la tabla basta con ejecutar:
ipfw -f flush
En la siguiente parte de este artículo explicaré cómo configurar el firewall para que se cargue automáticamente al iniciar el sistema operativo.
PPP con autenticación CHAP en Cisco
En este post explicaré cómo utilizar CHAP en PPP para realizar la autenticación. La configuración la llevaré a cabo con la CLI de Cisco. Recomiendo leer antes el post que explica el proceso de autenticación chap donde se detalla cómo se lleva a cabo este tipo de autenticación y el que explica cómo configurar PPP en un equipo Cisco, ya que se continúa con la topología y los comandos descriptos en él (lógicamente, sin la configuración de PAP).
Configuración CHAP
LaPlata# configure terminal LaPlata(config)# username BuenosAires password 1234 LaPlata(config)# interface serial 0/0/0 LaPlata(config-if)# ppp authentication chap
BuenosAires# configure terminal BuenosAires(config)# username LaPlata password 1234
Los comandos anteriores nos dejan ante el siguiente escenario:
- La autenticación es unidireccional, donde LaPlata es el autenticador y BuenosAires el autenticante.
- El nombre de usuario que se define en un equipo debe coincidir con el hostname del equipo que autenticará contra él.
- La contraseña debe ser la misma en ambos equipos.
Para lograr una autenticación bidireccional sólo basta con agregar la línea ppp authentication chap a la interfaz serial 0/0/0 en BuenosAires.
BuenosAires# configure terminal BuenosAires(config)# interface serial 0/0/0 BuenosAires(config-if)# ppp authentication chap



