lunes, 23 de mayo de 2016

SPA3102 y los códigos telefónicos I: rsyslog

Este post llevaba en la recámara mucho tiempo. De hecho, me lo he encontrado cuando estaba buscando cómo hacer los logs del SPA3102: tenía que repetir los pasos y no lo encontraba con Google, sabiendo que ya lo había hecho antes. Intentaré completarlo, porque esto lo dejé a medias hace mucho tiempo y ya no me urge la necesidad que tenía.

--

Esta es otra entrada más sobre el sistema PBX y los códigos telefónicos.

Por poner un ejemplo, cuando estás creando unos feature codes habrá que probarlos de alguna forma. En mi caso solía ser tirando del teléfono que tengo puesto en el SPA3102, que para eso lo compré. El problema que me he encontrado es que a veces me funciona, después me encuentro con que no... Sigue sin funcionar... Más adelante sí... Y eso no puede ser. Por lo tanto, como el trasto tiene la posibilidad de conectarse a un servidor de logs, voy a configurar mi RasPBX para que haga el log y después, si no se entiende muy bien (ya lo digo yo, que lo acabo de probar: es un poco críptico), se busca qué significa.  

Si buscamos manuales, nos encontraremos con que te hablan del sistema syslogd. Pero resulta que el que viene instalado es rsyslog. Si por algún casual tuvieses syslogd, este manual parece que tiene buena pinta. Al menos en lo que a este tema se refiere. En nuestro caso, tocará buscar el específico para rsyslog. Aquí he encontrado uno, que nos dice que hagamos más o menos lo siguiente:

En /etc/rsyslog.conf:
  • Descomentar:
    • $ModLoad imudp
    • $UDPServerRun 514
  • Además, vamos a permitir o tener descomentada (más abajo te lo ofrece) la linea que dice $IncludeConfig /etc /rsyslog.d/*.conf
En /etc/rsyslog.d/spa3102.conf vamos a poner lo siguiente:

:FROMHOST-IP, isequal, "_direccion_ip_SPA3102_" /var/log/spa3102.log

Las comillas son obligatorias. 

Vamos a reiniciar el servicio con

/etc/init.d/rsyslog restart

Y esta parte ya estaría. Si no se crease el fichero indicado, lo mejor es buscar qué indica el sistema en /var/log/syslog.

Ahora hay que configurar el trasto de Cisco/Linsys. 

Iremos al menú Voice, submenú System. En los campos Syslog Server y Debug Server pondremos la dirección ip de nuestra PBX. El combo Debug Level lo pondremos a 3 (aunque en alguno de los manuales dicen 2, yo quiero la máxima información):

SPA3102 - Configurando el syslog y el debug level
SPA3102 - Configurando el syslog y el debug level
Guardamos y haremos una prueba con algo que sabemos que funciona desde el teléfono. Como por ejemplo, una llamada a la extensión de un softphone que tengas instalado en un ordenador. O, un código que debería de funcionar. Por ejemplo, en mi caso, el feature code *69 funciona desde el teléfono. Te indica la última llamada entrante y te ofrece devolverla. Pero, si quieres que te diga la hora, que por defecto lo hace con el código *60, nos comunica. Pero, desde nuestro softphone sí que funciona. O si queremos probar el que configuramos el otro día, podremos ver que nos sucede lo mismo. 

Está claro que hay algo que no consigo que este aparato (el Linksys SPA3102) se le está diciendo que no va a poder enviarlos (y que a estas alturas sigo sin controlar del todo). Esto es lo que vamos a descubrir. Tal y como hemos configurado más arriba, miraremos los datos en el fichero /var/log/spa3102.log

Una vez que he estado probando un poco con los los códigos que funcionan y los que no, he podido ver que:
  • [0]Off hook: terminal "descolgado"
  • [0]On hook: terminal "colgado"
Es decir, el primero es el aviso de "se ha descolgado el teléfono" y el segundo "han colgado el teléfono". Volviendo a lanzar el comando, sólo aparecen estas dos líneas. ¿Me dejaría algo el otro día al quitar los códigos que pudieran interferir? No sé, porque si los hubiese eliminado por completo no me dejaría hacer nada, y algunos sí que me los envía. 

Viendo que esto no tira, me he encontrado con que la pestaña Line 1 tiene una sección con el combo "SIP Debug Option". Lo voy a activar a full y reiniciaré el aparato.

--

La selección de SIP Debug Option permite visualizar en el log, además de los demás valores que ya se muestran de por sí, algunos mensajes SIP con los que estaba trabajando el terminal 3102 en cuestión.

En el día de hoy: el error que me daba de no funcionar el código *60 ya no se produce. Al menos hemos podido recuperar la forma de registrar los resultados internos del aparato. Si más adelante tengo que seguir trabajando con estos códigos, seguro que os lo cuento por aquí. 

miércoles, 11 de mayo de 2016

Facebook y renovar la contraseña

Hace poco a un familiar le llegó un correo en el que le indicaban que se había intentado cambiar su contraseña de Facebook. Era rarísimo. 

Lo primero que se hizo fue mirar de dónde provenía el correo. El dominio:  @facebookmail.com. Como se dio el dominio por válido, miró el contenido de los dos correos y había un enlace que indicaba que si no había solicitado el cambio de password que se hiciera click en éste. Y así se hizo. ¿Resultado? Una página cuya URL indicaba que era de Facebook avisando de que se había cancelado el reseteo. 

Más adelante se hicieron más averiguaciones: ¿Era realmente el domino @facebookmail.com de la empresa? Según las entradas de Google, algunas entradas indicaban que era un domimio para scam (Ej01, Ej02)y otras, perteneciente al foro de la compañía, que sí era legítimo (Ej01, Ej02 ). 

Una búsqueda en algún WhoIs me ha ayudado a saber más sobre el dominio del que estamos cuestionando su pertenencia. Si hacemos una comparación del perteneciente a facebook.com con respecto a facebookmail.com podemos constatar de que ambos dominios tienen los mismos datos. 

Aún así, podríamos decir que los datos de contacto entregados del segundo dominio podrían haber sido copipasteados del primero. ¿Más cosas que nos pudieran dar pistas de que es un correo falso? Aunque en ocasiones falle, Google suele atinar y descubrir que se está intentando suplantar la identidad de la empresa. Además, he hecho otra validación más: he mirado las cabeceras del correo en cuestión. La primera cosa que he pensado en mirar ha sido el resultado de la comprobación SPF: 

Received-SPF: pass (google.com: domain of password[valor_censurado]@facebookmail.com designates 66.220.155.153 as permitted sender) client-ip=66.220.155.153

Tenemos un pass. Aún así, me gustaría comprobar a quién pertenece esa dirección IP, 66.220.155.153. Una vez más, haciendo uso de Google encuentro un servicio, IP Location Finder, nos devuelve:

Encontrando Facebookmail con IP Location Finder
Encontrando Facebookmail con IP Location Finder
Por lo tanto, y siempre teniendo en cuenta estos datos, se puede afirmar que el correo se ha mandado desde la localización de los servidores de Facebook. 

Aunque me he centrado en estos valores también se puede tener en cuenta que en las cabeceras aparecen más valores como:
  • Comprobación DKIM:  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=facebookmail.com;
  • Received del dominio original: Received: from facebook.com
Si bien algunos de estos son spoofeables estos datos me hacen pensar que el correo era legítimo. Además, estos datos se han realizado desde otro equipo distinto a aquel desde el que abrieron el correo sospechoso. 

domingo, 8 de mayo de 2016

EastMadHack 2016

Estos dos últimos sábados hemos tenido un evento muy especial en Arganda del Rey. Ha sido la primera edición de la EastMadHack. Dos sábados en los que durante todo el día se han realizado unas ponencias muy interesantes.

Esta primera edición la vi como el inicio que supongo que todas han tenido: un petit comité que en futuro llegará a alcanzar cientos de asistentes. En este caso podíamos contar unos veintipocos asistentes a la vez, dado que en algún momento algunos compañeros tuvieron que partir mientras que otros llegábamos. En mi caso, no pude asistir al comienzo del mismo, tal y como he hecho con otros (en los que casi siempre he sido de los top 10 en llegar). Aún así, he disfrutado mucho.

Dada la configuración de cómo estaban organizadas las charlas y volviendo a mencionar la confluencia que teníamos en las dos salas en las que hicieron las charlas (un salón de un bar restaurante el primer día, un aula de la Casa de la Juventud de Arganda la segunda sesión) permitía hacer preguntas en mitad de las charlas en vez de hacer una sección de preguntas al final de cada una de éstas. Al menos en la mayoría de las ponencias. Incluso alguno de los ponentes lo promovía. Al final de cada charla teníamos un sorteo de un libro, ya fuera de 0xWord o de MundoHacker (editorial Ra-Ma), del que me entregaron uno de esta última editorial sobre Protección de Datos .

Como de costumbre en los eventos a los que he asistido, la organización ha estado muy encima de que todo saliera bien. Incluso aún teniendo un lugar planificado para la segunda sesión, hicieron un cambio de localización a tres días de empezar para que los que fuéramos en coche pudiéramos tener un lugar fácil para aparcar sin pagar (quitándonos el problema de las zonas azules y verdes).

Desde EastMadHack se han comprometido a promover formaciones, por lo que no será descartable que dentro de poco tengamos noticias suyas al respecto.

Como ya he comentado, no pude estar desde el principio en ambas sesiones.

El primer día pudimos escuchar temáticas sobre criptografía en la Guerra Civil, Jupyter (para desarrollar en python), peritajes forenses (de la que se pudieron haceer muchas preguntas e intervenciones), cómo funcionan los antivirus en general y algo más particular para ESET o como hacer el reconocimiento como inicio para un pentest (en este último junto con un pequeño hack para el portátil de Kao, quien dio esta última charla).

Para el segundo día llegué cuando Angelucho empezaba su charla sobre "el eslabón más débil en Internet es el usuario", hacer búsqueda y análisis de big data en Twitter, O los distintos ataques a SSL/TLS, y la última de todas en las que se describía cómo funciona el entorno laboral de un desarrollador.

Soy consciente de que en otros eventos explico más. Espero que para la siguiente edición pueda hacerlo mejor.

No se puede olvidar las comidas, la cual se pudo compartir con la organización.

Si te gustan estos eventos, no te puedes perder las siguientes ediciones.