lunes, 25 de noviembre de 2013

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. 

miércoles, 13 de noviembre de 2013

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
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.

miércoles, 6 de noviembre de 2013

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
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
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
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.

lunes, 4 de noviembre de 2013

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.