Instalando RasPBX: Rasperri PI y PBX

Como ya os he contado voy a montar un PBX en una rasperri pi. Como podéis ver en la imagen, ya le he puesto la carcasa.

Rasperri PI en su carcasa

Ahora, hay que hacerse con la distribución deseada. En mi caso, me voy a instalar una RasPBX. En principio, voy a seguir los consejos que dan para hacer la instalación. No puedo asegurar que si se hace con otra distro vaya a funcionar, pero la verdad, debería de tirar igualmente.

Lo primero de todo va a ser descargarse el fichero de instalación y descomprimirlo. En mi caso el fichero ya descomprimido es raspbx-12-08-2013.img.

Ahora hay que descargarse el Win32DiskImager, que permitirá pasar la imagen del sistema que vamos a instalar a la tarjeta SD. No olvidarse de tener una a mano. ¡Ah! Y que sea como mínimo de la capacidad que requiera el sistema operativo en cuestión. En mi caso, va a utilizar 4 GB, sí o sí. O eso dicen. Después se podrá reajustar. Pero como aún no lo he hecho, porque estoy escribiendo esto en vivo y en directo...

Por lo tanto, y para que quede claro: tarjeta SD insertada y localizada. No vayas a utilizar la letra equivocada. Perderías los datos irremediablemente. El diskImager que os acabo de decir, lanzado como administrador (por si las moscas). El .img correspondiente también localizado. Ahora, le daremos al botón write para empezar el proceso.

Win32DiskImager para grabar la imagen de la RasPbx en la tarjeta SD

Cuando finalice, deberías de poder ver que ahora la unidad utilizada sólo tiene un máximo aproximado de 75MB. Dentro habrá una serie de ficheros, entre otros algunos .txt y algún que otro kernel. En principio, eso debería de significar que todo ha salido bien. En caso contrario, me temo que no puedo dar ningún consejo.

Con todo esto hecho, ahora podemos sacar la tarjeta SD e introducirla en la ranura correspondiente. Toca buscar, pero no es nada complicado. Son varias razones: una, se puede descartar porque si en cada lado tenemos los puertos USB y red, salida de vídeo... ¿RCA? y audio, HDMI... El último sitio donde mirar sería justo al lado del micro USB para la alimentación. Además, la carcasa tiene el hueco donde encaja. No sólo eso, sino que también hay que mirar en qué posición hay que introducirla. Evidentemente, los contactos metálicos de la tarjeta tendrán que estar mirando hacia la rasp. 

Bueno. Es el momento de enchufarla a la corriente. Aunque lo he hecho durante dos segundos, y he visto una sola luz encendida, me ha parecido ver que la carcasa tiene una leyenda de lo que significa cada led:

Leds encendidos de la rasp

Aquí podemos ver los leds encendidos. La leyenda de la izquierda es la que está serigrafiada directamente en la placa. La de la derecha es la que está grabada en la carcasa. La única diferencia notable es la marca de más abajo del todo: en la placa pone ACT mientras que en la carcasa pone OK. Este es el que se enciende y apaga. Si desconecto el cable de red, las tres primeras luces se apagan.

Una vez descrito todo esto, vamos a ver si consigo el acceso sin tener que conectar ningún monitor y teclado USB. Teniendo en cuenta que no hay DHCP, que tengo conectado directamente el cable con este microordenador y que el direccionamiento de red es un tanto peculiar, mucha suerte tendré si lo consigo de buenas a primeras.

En efecto, un ping para raspbx no ha funcionado. Por lo que se me ha ocurrido una cosa: tirar de wireshark. Seguro que alguna cosa sí que salía. Y, en efecto, en 5 segundos después de lanzarlo para la tarjeta de red correspondiente, he conseguido el dato que necesitaba:

Wireshark para buscar la IP de la rasp: es una APIPA

Como podía imaginarse, al no existir un DHCP, y no indicar la documentación una dirección IP específica,era de esperar que se la hubiera asignado ella misma. Y sólo podía haberlo hecho con una dirección de tipo APIPA. El estándar dice que tiene que ser tipo 169.254.0.0/16. Lo mejor es que me ponga en ese rango y después ya le asignaré el direccionamiento que mejor me convenga. ¡Genial! Aunque un primer ping ha fallado al 50%, ya responde correctamente. La primera vez que he intentado tirar desde el putty no me ha dejado acceder, sí he que podido llegar desde la interfaz web:

Intefaz web para FreePbx en la rasperri pi

De todas formas, el usuario root y la contraseña raspberry que dicen que hay que utilizar en la documentación, no tiraban en el panel de control web. Por lo que he vuelto a intentar tirar de los comandos. Eso sí, después de un reinicio inesperado. Ahora sí que sí, en la consola, puedo llevar a cabo la configuración recomendada:

#configure-timezone
#dpkg-reconfigure locales

El configure-timezone te permitirá seleccionar la zona horaria. En mi caso, he seleccionado Madrid. El dpkg-reconfigure locales, te permitirá seleccionar el tipo de codificación que quieres con la que trabaje.En mi caso, he dejado seleccionada por defecto las del inglés de Inglaterra (GB) y he seleccionado las de español de España. Por defecto, dejaré que sea es_ES@euro.

Ya ya está. Ahora se debería de poder acceder al portal (tal y como enseñé antes) e introducir las credenciales para el mismo, totalmente diferentes a las que se usan para la consola (algo que no me acordaba). Por defecto, admin tanto para el usuario como para la contraseña. Y este es el estado en el que se encuentra:

Estado inicial de FreePbx justo una vez se que se ha terminado de instalar

Y por hoy aquí lo dejamos. Ya os seguiré explicando los siguientes pasos que he ido dando en siguientes posts.

Unboxing: Rasperri Pi

Como os conté hace unos días, hice un pedido de una serie de cosas. Entre otras, una rasperri pi y su tarjeta SD correspondiente. Mi plan: Montarme una minicentralita PBX.

Como fui muy listo, conseguí que el pedido de este microordenador saliese en distintos envíos: uno el pequeño dispositivo y la tarjeta SD de 8 GB en la que instalaría el sistema operativo y en otro, la carcasa para la Rasp, que además, sale de otro distribuidor. Todo eso, en vez de que salga del mismo sitio a la vez. ¿Veis como soy muy listo?

También lo soy por abrir el paquete sin hacerle las fotos correspondientes. Total, que este unboxing va a ser un poco de pega. Ya había metido algo las zarpas en el contenido. Pero bueno, por enseñar un poco cómo estaban las cosas tampoco creo que pase nada.

El contenido del paquete: Rasperri pi y tarjeta SD

Aunque me ha quedado un poco desenfocada (o movida):

La tarjeta SD que usaré para montar el sistema

No tiene mucho más misterio. Ahora, la Rasperri:

Caja que contiene la Rasperri Pi

Rasperri pi en la bolsa que la protege de la electricidad estática

Rasperri pi fuera de la bosa protectora de electricidad estática

Una razón por la ahora mismo no voy a sacar la Rasp es porque quiero esperar a que me llegue la carcasa. En cuanto me llegue, le podré dar bastante caña. A ver si hay suerte.

FreePBX 01 - Unboxing Cisco/Linksys Spa3102

Llevaba tiempo queriendo hacer un tinglao con el teléfono fijo y al final me voy a poner con ello. Espero que me salga como quiero (por mi  bien).

Lo primero que hice fue hacer una  serie de pruebas con FreePBX en una máquina virtual. Tiraban de ésta una aplicación de escritorio en Windows y otra para Android desde el móvil. 

El tema es que ya me decidí a comprar las cosas que me harían falta. Una de ellas era un aparato que te convierte la línea RTB (Red Telefónica Básica) a VoIP. Además, en mi estudio también pude ver que se podía dirigir las comunicaciones a una centralita PBX. La razón de comprar esta marca y este modelo no es otra que Lorenzo (Martínez) fue la que nos presentó en alguno de sus posts sobre este tema. 

Y, sin más, os dejo las fotos que fui haciendo a medida que desempaquetaba uno de los envíos de los que constaba el pedido que hice. 

Paquete del pedido del Linsys Spa3102

Abriendo el paquete del pedido del Linsys Spa3102

Dislumbrando la caja, pero está boca abajo

Caja del Linsys Spa3102, dispuesta para ser abierta

Primera impresión de la caja nada más abrirla

Y, para finalizar, la última imagen que hice fue con todo el contenido del paquete para que viese todo lo que había dentro de la caja:

Contenido completo del Linsys Spa3102

A falta del CD, que se puede ver en una la penúltima imagen, el contenido que se puede describir (sentido de las agujas del reloj, y centro) sería:

• El cable para el teléfono (contector RJ11)
• El dispositivo propiamente dicho
• Par trenzado, categoría 5, tipo 568B, para la red (vamos, el cable con conector RJ45).
• Alimentación para la red eléctrica. Pero sin el formato del enchufe.
• En el centro: El enchufe para la alimentación eléctrica.

Me explico con los dos últimos: Para la alimentación de para la red eléctrica, dependiendo del país donde estés, te puedes encontrar con que el enchufe tiene un formato u otro. En este caso, lo que hacen es tener el mismo adaptador de corriente para el dispositivo en cuestión, y te entregan sólo una pequeña pieza que vas a acoplar dicho adaptador. Esa pieza es la irá definida por el país en el que te encuentres. Espero que se haya entendido, porque no me ha resultado muy fácil explicarlo. 

De momento lo dejo aquí. Pero ya iré haciendo otra serie de posts al respecto. 

Un puerto, dos lugares

Este fin de semana estaba en la academia de piano a la que voy con asiduidad, cuando me dijeron que tenían un pequeño problema. Habían cambiado el router para acceder a internet y una de las sedes no podía acceder al servidor en el que se encuentra el software que gestiona las facturas. Y antes sí que podían. 

En el momento en el que pude ponerme a ello ya estaba el caballero de la operadora, que no veía muy bien cómo podía solucionarlo. Y yo, al principio, tampoco. Se pudo recabar más o menos la siguiente información:

- Se había cambiado un router por otro.

- No se habían producido otros  cambios en el resto del sistema. 

Por lo tanto, parecía que el problema iba a estar en el trasto que se acababa de cambiar. Ahí había que buscar las posibles diferencias entre el antiguo aparato y el nuevo. En principio, si el nuevo permitía un acceso a internet como siempre, no debía de estar en la conexión. Pero sí que había algo que estaba claro: si se accede desde el exterior, tenía que haber, como mínimo, un problema en los puertos. 

Sabiendo eso, había que mirar qué puertos iban a hacer falta abrir, como mínimo. ¿Cómo se buscan esos puertos si ya no se dispone del antiguo router? Además, siendo un software propietario... Muy bien. Sabiendo que en la misma red podía haber otro cliente abierto, teníamos que mirar a qué puertos estaba accediendo éste, para así, poder abrirlos. 

Lo primero de todo sería mirar en el software por si hubiese algún sitio donde configurarlos. Pero, en este caso, no hubo suerte y no aparecía nada que hiciese pensar que se podía configurar algún tipo de conexión. Además, sin disponer del portátil, tampoco se podría utilizar ningún sniffer. Tampoco es plan de bajarse uno, pero se podría haber hecho. Hasta, que se me ocurre, que para qué instalar un wireshark o net monitor si tenemos el magnífico 

netstat -nabo > salida_netstat.txt

A partir del cual, se podría intentar buscar el nombre del ejecutable del programa. En este caso, hubo suerte  y el ejecutable se llamaba igual que el programa. Pero, si no hubiese sido así, habría hecho falta buscar la carpeta de instalación del cliente y mirar qué ejecutables habría para ir buscando en el fichero de salida el que correspondiese. Como iba diciendo, en este caso hubo suerte y sólo salieron 3 o 4 entradas que se corresponderían con el programa en cuestión. Y todas ellas al mismo puerto. 

Por desgracia, después de abrir ese puerto y desde el otro lado probar varias veces (con reseteos del router y todo) no se consiguió hacerlo funcionar en ese destino remoto. En cuanto vuelva, preguntaré para ver qué me faltaba, porque no debía de ser mucho más difícil. 

Cómo calcular el SAI / UPS que se necesita

Recientemente (realmente, hace unos meses), tuve un pequeño encargo: se necesita que un servidor, que es el que hace que funcionen unos TPVs, siguiese funcionando en el caso de que la luz se fuese. Me comprometí a hacerlo… Y cada vez que quiero hacerlo o no es el mejor momento o no puedo. Por lo que ahora que acabo de sacar un rato, me he puesto a investigar. Porque, todo sea dicho, he hecho pocas cosas con los SAIs, desde conectarlo físicamente a la corriente y al ordenador, hasta configurarlo en un Linux. Y ya. Sin importarme el tiempo que fuera a durar. Precisamente, eso es lo que se necesita calcular: ¿qué equipo hace falta para tener una autonomía de X tiempo?

Lo primero vamos a aventurar las cosas que parezcan obvias, y después, vamos a adentrarnos en el mundo de la búsqueda por Google.

Primero, vamos a analizarlo para un equipo sólo y después lo vamos afinando.

Vamos a ver.

Primero habrá que averiguar cuánto consume. No creo que sea lo mismo un ordenador de sobremesa que un señor pepino que es 7 veces más fuerte que tú potente que ese miso equipo de sobremesa. Además, en esto influye cada uno de los periféricos que tenga conectados el equipo, si conectamos también el monitor…

También habrá que ver qué batería le pones y que salida ofrece. No creo que una batería de móvil sirva para nada. Es más, lo más probable es que ni se inmute.

Con esto, deberíamos poder buscar, en términos muy, muy generales, qué tenemos que comprar. Os recuerdo, que todo esto va a ser teniendo en cuenta que va a servir para un equipo, y sólo uno. Como enchufemos más equipos a alguna de las tomas que tiene salida de batería… Recordemos que los SAIs también tienen tomas que sólo “limpian” las posibles fluctuaciones de la corriente que podrían tostar (quemar) un equipo.

Desde el sitio de Unicrom, dan una fórmula de cómo se tiene que calcular la potencia que debería de tener el UPS para las necesidades adecuadas. El problema está en que en New SAI dan otra fórmula distinta. Ahora lo explico. Para ello vamos a tener una tabla como la siguiente:

Ejemplo de tabla para calcular el SAI mínimo necesario:, procedente de Unicrom

Tendremos que listar los equipos. En sus respectivas columnas de voltios y amperios, vamos a poner los datos que indiquen sus correspondientes etiquetas.

Una vez tengamos listados los equipos con sus datos de voltios y amperios, tendremos que multiplicar los voltios y los amperios para obtener los VAs. Y aquí es donde radica la diferencia entre varios sitios. Mientras que en el Unicron dicen que este cálculo es directamente un VA, en New SAI dicen que esta multiplicación son vatios, y que para obtener el VA real hace falta dividirlo entre 0,7. De hecho, los mismos de Unicron, también dicen que si en la etiqueta de los equipos analizados tienen marcado su consumo de potencia con los vatios, para obtener los VAs correspondientes hay que dividir ese valor entre 0,7 o multiplicarlo por 1,43. Un ejemplo que explica muy bien cómo a veces se confunden estas fórmulas está en este enlace. Otras fuentes van más allá, e indican que esa división debería de estar entre 0,6 y 0,7 , dependiendo del fabricante (gama alta o baja entre otros valores). Aunque es un margen de error, en estos casos voy a dar por bueno estos 0,7.

Vamos a ver las fórmulas que proponen aquí:

POTENCIA ACTIVA (W) Vatios = 1 vatio = 1 Voltio x 1 Amperio x COS fi
POTENCIA APARENTE (VA) Voltiamperios = 1 VA = 1 Voltio x 1 Amperio
Por lo que 1W = 1 VA x COS fi

Teniendo en cuenta esta información, podemos despejar algunos datos para sacar los VAs de los vatios y viceversa.

Donde COS fi es ese factor del que estamos hablando que se encuentra entre 0,6 y 0,7.

(x W ) / 0,7 = y VA
(z VA) x 0,7 = p W

Vamos a analizar las dos fuentes que he utilizado: Unicron y New SAI. Pongamos 120v y 2 A para un equipo.

Para Unicron, tendríamos:
120 v x 2 A = 240 VA

Para New SAI serían:
(120v x 2 A)/0,7 = 342,85… VA

Vemos que la diferencia entre ambos es casi, casi de un 30%. Ese factor de corrección parece bastante importante.

A final, habrá que saber los VAs que consumimos y que su valor será siempre mayor al vatio.

Después de todo este follón, ahora toca poner cada uno de los resultados en su celda correspondiente.

Ahora tendremos que sumar todos los VAs que hemos calculado. Una vez sumados, vamos a buscar un margen de crecimiento. Según recomiendan en la página, que este sea de un 5% anual, para un equipo que pueda tener una durabilidad de 5 años. Espero que no haga falta, pero aún así, por si las moscas, vamos a calcular ese 25% que recomiendan. Los VAs que vamos a necesitar saldrán de la suma del subtotal con el valor obtenido del 25%. Si tenemos en cuenta el ejemplo que nos ponen en la página, podemos hacer un pequeño redondeo hacia arriba. A ver, si no tienes visos de que se vaya a ampliar el equipo, podrías mirar si el UPS siguiente hacia abajo te serviría.

Con esto hemos calculado la potencia que debería de tener el SAI, pero no hemos hecho ninguna comprobación de cuánto tiempo de autonomía nos dará. ¿Hay alguna otra forma de hacer los cálculos necesarios para saber cuál es el mejor UPS, ya sea por la potencia o por el tiempo que nos permita trabajar sin que nos llegue la chicha al equipo?

Eso sí: Tengamos mucho cuidado de la potencia que sacamos no vayamos a quemar algún equipo (¿cuál de ellos: el que queremos que no se quede fuera de servicio ante un apagón o el UPS? No me ha quedado del todo claro, la verdad).

Ahora ya sabemos qué va a consumir aproximadamente nuestro sistema. En la búsqueda de información para realizar los cálculos, una de las primeras entradas de Google. Desde FashionPCs explican bastante bien cómo se debería de calcular la duración en tiempo que ofrecerá nuestro Sistema de Alimentación Ininterrumpida. Una de las cosas que me ha gustado mucho es que han sido muy cautos y los consejos que han dado en los dos últimos párrafos.

Así, para que conste aquí la fórmula que nos ofrecen:

Tiempo autonomía = ((Número_baterías x Voltaje_baterías x Amperios-Hora_baterías x eficacia_SAI) / (VAs_SAI))x60
Por cierto, el amperio-hora (Ah), es, la cantidad de electricidad que, en una hora, atraviesa un conductor por el que circula una corriente continua de 1 A, según Wikipedia.

Desde APC, un fabricante que ya conocía de SAIs, tienen un configurador, que te ayuda muy bien a seleccionar el producto que ellos te ofrecen según los datos introducidos. y que voy a mirar ahora mismo (mientras que escribo este post).

Lo tengo que probar más tarde (cuanto continúe editando este post y revise algunos datos que no me acaban de cuadrar), pero el resultado obtenido no todo lo que esperaba: Si tenemos en cuenta el porcentaje de ampliación, no me cuadra nada el resultado. Probando, probando, me he puesto a despejar obteniendo:

(x V / y VA) = factor

Y los resultados se encontraban entre 0,7 y 0,8. Por eso algunos de esos datos no cuadraban. Como dicen en alguno de los ejemplos de donde he obtenido los datos para este post, cada fabricante pone lo que le da la gana.

No voy a negar que prácticamente todas estas entradas las he conseguido en la primera entrada que me ha ofrecido Google. Creo que de momento esto es todo lo que puedo contar. No he buscado mucho más, pero, para las necesidades básicas, creo que me servirá. Si tengo alguna que otra cosa más, haré otra publicación al respecto.

Las imágenes en blogger no son las que he subido

Así es como debería de empezar el artículo: Las imágenes en blogger no son las que he subido... al menos, en lo que a su hash se refiere.

Como algunos sabréis, recientemente he montado mi primer reto. Era de esperar que quería que funcionase bien, pero ha sucedido algo que no me esperaba. Y aquí he de entonar el mea culpa. Vamos a poner un ejemplo muy curioso. Pongamos que queremos subir una imagen…

Vamos a poner un ejemplo: esta captura quita el ajuste automático de imágenes en blogger. Para desactivarlo tienes que acceder a https://www.google.com/settings/plus:

Cómo quitar ajuste automático de imagenes en Google / Blogger

Esta imagen tiene el siguiente hash md5 (sí, lo sé, no es recomendable, pero bueno, por poner un ejemplo):

Hash imagen del ajuste: e39f872040f4474ef49edb06f87c38dd

Ahora, habría que mirar qué pasa si nos bajamos la imagen. El problema está en que en vista previa no me deja cogerla bien. Como he podido leer que las imágenes se guardan en álbumes en Picasa, voy a ver si ahí sí que puedo hacerme con la foto correctamente, descargarla, y probar qué hash me muestra ahora. Por desgracia, aún no me la muestra, tendré que publicar este post para hacer la prueba.  

[Lugar donde pondré los resultados después de actualizar las modificaciones que hace blogger al subir las fotos. ¿Qué resultado obtendremos?]
[UPDATED]

Comparación de imágenes después de realizar el cambio de configuración en el perfil de Google

Al cambiar la configuración, las imágenes ya son las que deberían de ser. Al menos, eso parece.
[/UPDATED]

Por poner un ejemplo claro de que se producen cambios, me bajaré las dos imágenes que se tenían que analizar y las compararé con las que se tendrían que haber bajado. Estos son los enlaces:

Imágenes para descargar

Los "segundos enlaces" te llevan a las miniaturas que te presenta blogger cuando te muestra todas las fotos. O eso es lo que he deducido. 

Hashes de las imágenes originales y las descargadas

Para que se entienda la anterior captura: las dos primeras imágenes son con las que habría que trabajar. Las otras son la miniatura (las que llevan el apellido "_reducida") y las de tamaño normal.

Por eso, el reto no salió todo lo bien que esperaba. Ahora me gustaría hacer un sondeo: ¿Cuántos de vosotros lo habéis intentado hacer? Como mínimo, Longinos tuvo la idea de que se podría haber manipulado de alguna forma la imagen por parte de blogger, cosa al final se ha podido corroborar. Por lo tanto, para los siguientes tengo que buscar un plan de actuación para evitar en la medida de lo posible este problema (¿el cambio que he hecho en la configuración de mi perfil?). Una idea que me dio Longinos cuando estuvimos allí por la NoConName, es que tendría que haber puesto la firma de la imagen para que aquel que se la bajase supiese si era la foto correcta o no. Ya sabéis, algo que tendría que haber caído en la cuenta.

Espero que para las próximas tenga más éxito. Ahora, vamos a ver qué resultado obtenemos de publicar este artículo y bajarme la imagen que he hasheado al principio.

Crónica NoConName 2013

Un año más, he ido a la NoConName. Como de costumbre, al menos desde que voy, se ha celebrado en la CosmoCaixa de Barcelona.

Una vez más, tiré en tren para la cuidad un día antes. Por lo que una vez llegué al hotel, me dispuse a pasear por la zona, comer y callejear por el centro (viendo la Sagrada Familia en la medida de lo posible),

Aunque las notas que tomé el primer día se me quedaron en el hotel el segundo día... y para colmo de los colmos ese segundo día, el sábado, fue cuando hice el check-out, creo que podré resumir sin problema las ponencias y el ambiente que se respiró.

Este año, se celebró un CTF (Capture The Flag) organizado por Facebook. Todo sea dicho, un "juego" sólo para profesionales. Sólo decir que también participaron, si no recuerdo mal, unos chavales chinos con una media de 14 años, unos rusos... Y los primeros empezaron arrasando. De todas formas, la explicación del reto la hicieron el mismo sábado al finalizar todas las ponencias, pero ahí Longinos (@L0ngin0s) y yo ya nos habíamos ido a coger el tren de vuelta.

¿Qué pudimos ver? Pudimos ver a Ruth Sala (@Ruth_legal) hablando sobre todo lo que nos observa: saben qué hacemos y dónde. Desde que te levantas encendiendo el móvil, pasando por las cámaras que tienen en la panadería o el datáfono, en tráfico, al entrar en la oficina con la tarjeta / huella / cámaras... Así se ponía de manifiesto que fueras donde fueras, había dispositivos que te traceaban. De hecho, más tarde ella moderaría una mesa redonda en la que se hablaría precisamente de este tema.

En diversas ocasiones también tuvimos la posibilidad de que nos hablasen de la evasión (o cómo evitarlo) de sandboxes, por parte de Iñaki Rodriguez (@virtualminds_es) y Ricardo Rodríguez (@RicardoJRdez) una de ellas y Alberto Ortega (@aOrtega) otra. Sobretodo porque hay que tener en cuenta que se tiene que conseguir o buscar las características que nos indiquen que nos encontramos en un entorno controlado (ya sea utilizando sandboxes, máquinas virtuales, una máquina con unas características muy bajas...) o poder engañar a la muestra para que si  intentase detectarlo que se crea que es un entorno real.

Otra ponencia fue la de Vicente Aceituno (@vaceituno), en la que se nos mostraba cómo el hecho de categorizar los defectos, vulnerabilidades, riesgos... en alto, medio y bajo hará que los que tienen que tomar las decisiones decidan dejar cosas a medias. Su propuesta, al menos tal como la entendí, era no asignar ninguno de esos valores, e indicar algo parecido a "tienes que resolver estas incidencias, y punto". Así explicado muy rápido (no es tan sencillo de explicar), pero como resumen...

También Carlos Alberto Fouz nos enseñó a utilizar nuestra propia box para conectarla directamente al móvil: un pequeño dispositivo que te permitirá analizar lo que contiene un móvil aunque tenga la pantalla, el teclado, ¿botones de encendido? completamente rotos. La idea principal es tener el terminal al que se le quiere realizar el forense / la pericial y con los distintos pines que tiene la placa base del mismo, conectarlos (o soldarlos si hiciese falta) a los cables que forman el cable de red y el otro extremo al trasto que realizará la lectura. Eso sí: esto conlleva que hay que tener mañana soldando y hay que saber qué pines del cable van en qué lugar. Una forma de recuperar información del terminal aunque hayan intentado romperlo (ya sea queriendo o por accidente). No olvidarse de utilizar una jaula de faraday si fuese necesario.

Jordi Giménez [sic, así es como viene en el programa] (@gimix3) nos habló de OAuth, cómo usarlo (ya sea bien o mal), etc.

Sebastián Guerrero (@0xroot) es uno de los que hizo doblete: nos habló de rootkits en Android, tal y como lo hizo en la RootedCon 2013, pero en este caso se dirigía al al espacio de usuario en vez de espacio del kernel. También nos habló de cómo no seguir las recomendaciones de buenas prácticas puede implicar que se estén dando permisos de lectura de los datos que genera tu aplicación a otras que no deberían de poder acceder a los tuyos.

Ricardo Rodríguez (@RicardoJRdez) hizo otro doblete, en este caso nos habló de NFC y de cómo se podía conseguir, por ejemplo, recargar una tarjeta de transporte sin tener que soltar un solo duro (al menos, sólo tendrás que comprar el lector/escritor. Y sí, los antiguos duros son más que un céntimo). Algún día tendré que volver a trastear con mi lector RFID. No es NFC, pero bueno. Ahí lo tengo.

David Guillén nos habló de la esteganografía (¿cómo lleváis el reto?) de binarios. Meter en un binario otro binario. Perfecto para guardar bichos y que se escondan a los antivirus.

Una vez más, y como continuación de la Sivila (una Sivila 2.0), el Profesor (Pedro) Fortunity le ha dado una vuelta de tuerca a la Sivila. En su momento no lo conté. Para resumirlo, la sivila es la que se encarga de hacer el cifrado de las contraseñas que envía el usuario. Es un cifrado por hardware, por lo que si el servidor de ser comprometido, no se podrá sacar la contraseña en claro. En esta ocasión, la vuelta de tuerca es que también participa el cliente.

Omar Martín (@ElPalomo_Blog) puso ejemplos de cómo inyectar SQL para saltarse un posible Web Application Firewall.

Jaime Sánchez (@segofensiva) nos contó los problemas de seguridad de WhatsApp ya conocidos (más o menos) y qué hacer para evitar que te espíen las conversaciones. Entre otras cosas, pasa por montarse un servidor intermedio. Pero para trollear al espía...

Este es un resumen de lo que pudimos ver este año. Si habéis estado otros años, veréis que hay muchas caras nuevas. Pero eso no ha quitado calidad al evento.

Una vez más, espero poder veros en las siguientes ediciones. Y si pueden ser en otros eventos, bienvenido sea.