RSS

El nuevo blog

Nada más empezar el año cerré este blog porque me apetecía empezar algo nuevo tras siete años y medio escribiendo en el blog. Además, me apetecía empezar algo en inglés. Así que, de momento, simplemente he abierto otro blog que podéis encontrar en la siguiente URL:

Binary Coders

Nos vemos.

 
Deja un comentario

Publicado por en 16 marzo, 2015 en anuncios

 

Despedida y Cierre

Durante estos últimos meses muchas cosas han cambiado y acontecido, cosas que han dado un empujón final una idea que ya me rondaba la mente, la de cerrar este blog. Así que, he tomado una decisión definitiva y esta será la última entrada en este blog. Al igual que el año llega a su fin, la etapa de este blog también llega.

Durante muchos años, desde su inauguración el 16 de Octubre de 2006, me ha servido para escribir, dar rienda suelta a la creatividad y apoyar una de mis pasiones, aprender cosas nuevas. Este proyecto personal que empezó como una simple idea sin un propósito demasiado claro cuando estaba en la universidad y, con el tiempo, se ha transformado en una recopilación de pequeños apuntes, chuletas o tutoriales que durante estos años me han ayudado, y espero que a alguien más, a aprender y explorar el enorme mundo de la tecnología y, más concretamente, de la computación, especialmente el desarrollo de software y la seguridad. He hablado de nuevas y viejas tecnologías, he aprendido cosas nuevas, he cometido errores y, sobre todo, he disfrutado escribiendo y leyendo los comentarios de unos y otros usuarios. Además, me ha permitido conocer gente muy interesante, unos que solo han pasado brevemente por mi vida y otros que han llegado para quedarse.

Espero que durante estos años hayáis disfrutado con el contenido del blog y que al menos, uno solo de vosotros, haya aprendido algo.

El motivo de cerrar no es otro que la necesidad de empezar un ciclo nuevo y empezar proyectos nuevos o nuevos retos. Al igual que la tecnología cambia y evoluciona rápidamente y, los proyectos nacen y desaparecen para dejar paso a otros dejándonos algunas lecciones aprendidas, parece evidente que un blog dedicado a la tecnología tenía que seguir unos pasos similares. Es hora de explorar nuevos horizontes y empezar algo nuevo. ¿Qué será? Aún no está claro, algún proyecto de software, otro blog quizás similar pero reescrito desde cero y sin lastres anteriores de forma, formato o temática, solo el tiempo le dará forma a alguna de las ideas que tengo en la cabeza.

En cualquier caso, gracias por estar ahí y haberme ayudado a crecer como persona y como ingeniero de software.

Nos vemos.

 
2 comentarios

Publicado por en 31 diciembre, 2014 en anuncios

 

TDD

Metodología de pruebas bastante extendida cuyo acrónimo significa:

  • Inglés: Test Driven Development.
  • Español: Desarrollo guiado por pruebas.

Se utiliza generalmente para el desarrollo de pruebas unitarias y no es dependiente de ningún lenguaje. El proceso de desarrollo siguiendo esta metodología se compone de tres etapas diferentes:

  1. Se escriben las pruebas y se comprueba que fallan.
  2. Se implementa el mínimo código que hace que las pruebas se pasen exitosamente.
  3. Se refactoriza el código escrito.

La idea de la metodología es que los requisitos de negocio sean transformados en pruebas asegurando de este modo que al final el desarrollo, todos los requisitos se cumplen. También es evidente que utilizando esta metodología, otro de los objetivos que se alcanzan es el de tener una amplia cobertura de pruebas en nuestros proyectos, ya que nunca se va a desarrollar nada para lo que no se hayan escrito sus pruebas previamente. Esto deriva en que en las siguientes iteraciones del proyecto, el desarrollador que quiere introducir nuevos cambios puede confiar en que el código que va a modificar o va a utilizar en su desarrollo funciona e implementa de forma correcta los requisitos de negocio.

A la hora de la implementación, se pretende que el código siga dos principios básicos y ampiamente conocidos como son:

  • KISS: “keep is simple stupid”. Literalemnte traducido por “Mantenlo sencillo estupido”, aunque prefiero la traducción “Mantenlo estúpidamente sencillo”. Que nos viene a instar a mantener nuestros sistemas lo más simples posibles a través de buenas prácticas de diseño.
  • YAGNI: “You aren´t gonna need it”. Literalmente traducido por “No lo vas a necesitar”. Este principio nos insta a no implementar cosas que no se van a utilizar, ni siquiera aunque pensemos que en un futuro quizás lo vayamos a hacer, porque en la mayoría de las ocasiones, ese futuro nunca llega.

Pero bueno, después de toda esta introducción teórica, vamos a implementar algo.

Primera Fase: Escribir las pruebas y comprobar que fallan.

public interface Calculator {
    int add(int a, int b);
    int subs(int a, int b);
    ....
}
public class MyCalculator implements Calculator {
    public int add(int a, int b) {
        return 0;
    }

    public int subs(int a, int b) {
        return 0;
    }

    ...
}
public class MyCalculatorTest {

    Calculator calc;

    @Before
    public void setUp() {
        calc = new MyCalculator();
    }

    @Test
    public void addTest() {
        assertEquals(2, calc.add(1, 1));
    }

    @Test
    public void subsTest() {
        assertEquals(1, calc.subs(2, 1));
    }

    ...
}

Segunda Fase: Implementar el mínimo código

public class MyCalculator implements Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int subs(int a, int b) {
        return a - b;
    }

    ...
}

Tercera fase: Refactorizar nuestro código

En este caso, está tercera fase obviamente no tiene mucho sentido ya que el código se ha hecho lo más simple posible para que nos fijemos solo en el proceso de TDD y no en el código. Pero por si alguno no está familiarizado con el término refactorizar, os dejo el enlace de su definición: Refactorización

Tras esto tendríamos listo nuestro código con nuestras pruebas y la implementación de nuestra lógica de negocio, con lo que podríamos pasar al siguiente requisito.

Se que es una pequeña (muy pequeña) introducción al término de TDD pero creo que puede ser útil para aquellos que lo desconozcan o nunca lo hayan utilizado. Nos vemos.

 
Deja un comentario

Publicado por en 30 septiembre, 2014 en Desarrollo ágil, programación

 

Java EE: Lo básico

Hoy vamos a hacer algo muy simple. Estos días he estado escuchando discusiones sobre que los proyectos hechos en Java EE requieren muchos ficheros, configuraciones y demás, y la verdad, es que me temo que no estoy nada de acuerdo. Quizás antiguas versiones J2EE lo requerian, pero ahora Java EE nos permite centrarnos en el negocio y la única complejidad que se añade se debe a este. Así que he decidido implementar un ejemplo muy básico con ellos para ver cuanta complejidad obtenía implementando un pequeño servicio REST sin BBDD.

Lo primero que tenemos que hacer es crear un proyecto maven en nuestro IDE favorito, en mi caso yo usaré Eclipse. Este proyecto maven será con el arquetipo básico o sin arquetipo. El contenido del fichero pom.xml sera:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.wordpress.infow</groupId>
	<artifactId>MostBasicJavaEEApp</artifactId>
	<version>1.0</version>
	<packaging>war</packaging>
	<name>MostBasicJavaEEApp</name>
	
	<properties>
		<maven.compiler.source>1.8</maven.compiler.source>
		<maven.compiler.target>1.8</maven.compiler.target>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<failOnMissingWebXml>false</failOnMissingWebXml>
	</properties>
	
	<dependencies>
	
		<!-- Java EE 7 -->
		<dependency>
			<groupId>javax</groupId>
			<artifactId>javaee-api</artifactId>
			<version>7.0</version>
			<scope>provided</scope>
		</dependency>
	
	</dependencies>
	
	<build>
		<finalName>basic</finalName>
	</build>
</project>

Lo siguiente es crear el servicio REST para esto necesitamos la clase que nos configura REST en nuestra aplicación, cuyo contenido será:

package com.wordpress.infow.basic.rest;

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/rs")
public class ApplicationConfig extends Application {

}

Como podéis ver, muy simple.

Y ahora creamos nuestros servicio REST:

package com.wordpress.infow.basic.rest;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;

import com.wordpress.infow.basic.boundary.BasicStuff;

@Path("/sessions")
public class Session {

	@GET
	public String getSession() {
		return "Jonh Doe";
	}
}

Con esto, ya podremos arrancar nuestro servidor, yo estoy usando GlassFish 4, y accediento a la URL correcta podremos ver el resultado.

Lo siguiente es añadir el servicio al que el servicio REST va a invocar e injectar este en nuestro código REST.

package com.wordpress.infow.basic.boundary;

import java.util.Date;

import javax.ejb.Stateless;
import javax.inject.Inject;

import com.wordpress.infow.basic.entity.BasicEntity;

@Stateless
public class BasicStuff {

	public String getDate() {
		return new Date().toString();
	}
}
package com.wordpress.infow.basic.rest;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;

import com.wordpress.infow.basic.boundary.BasicStuff;

@Path("/sessions")
public class Session {

	@Inject
	BasicStuff bs;

	@GET
	public String getSession() {
		return "Jonh Doe" + this.bs.getDate();
	}
}

Con esto ya tenemos nuestro servicio REST invocando a la lógica de negocio de nuestra aplicación, y sin un xml todavía ni nada raro.

El siguiente paso será añadir la entidad que debería conectar con la BBDD.

package com.wordpress.infow.basic.entity;

public class BasicEntity {

	public String getStatus() {
		return "OK";
	}
}
package com.wordpress.infow.basic.boundary;

import java.util.Date;

import javax.ejb.Stateless;
import javax.inject.Inject;

import com.wordpress.infow.basic.entity.BasicEntity;

@Stateless
public class BasicStuff {

	@Inject
	BasicEntity be;

	public String getDate() {
		return new Date().toString() + " - " + this.be.getStatus();
	}
}
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
                           http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       version="1.1" bean-discovery-mode="all">
</beans>

Vaya, aquí s’i que hemos tenido que añadir un xml para permitir al contenedor web la injección de todos los objectos.

Y ahora, vamos a… Ummm, espera, ya está todo. No necesitamos hacer nada más.

Como se ve Java EE nos deja centrarnos en la lógica de negocio y los problemas derivados de está, en vez de, en complejas configuraciones.

Podeís encontrar el código del proyecto como siempre en mi repositorio:

MostBasicJavaEEApp

Nos vemos.

 
Deja un comentario

Publicado por en 4 septiembre, 2014 en JavaEE

 

Instalando RabbitMQ

Hoy vamos a dejar un poco de lado la programación y vamos a instalar un instancia de RabbitMQ para poder hacer un par de cosillas con ella. Para el que no lo sepa, RabbitMQ es un sistema de comunicación basado en mensajes, lo cual nos permite enviar (productor) tareas a una instancia de RabbitMQ para que una aplicación (consumidor) las procese.

Yo voy a instalar el sistema en un servidor CentOS pero los pasos son extensibles para cualquier plataforma Linux y, supongo, no distarán mucho de una plataforma Windows.

Para empezar tenemos que instalar en nuestra máquina una versión reciente de Erlang (un lenguaje de programación). En CentOS, al menos, a día de hoy, con el paquete que viene incluido en la distribución nos bastará. En otras plataformas podéis ir directamente a la página de Erlang y descargar de allí la última versión.

Tras esto, nos dirigimos a la página de RabbitMQ y descargamos el archivo para su instalación.

Hasta aquí, todo bastante trivial y yo creo que nada requiere más explicación.

Lo siguiente que vamos a hacer, es permitir que arranque cuando nuestro sistema arranque. Para conseguir esto ejecutaremos:

sudo chkconfig rabbitmq-server on

Tras esto, podremos arrancar y parar la instancia de RabbitMQ con los comandos:

sudo service rabbitmq-server stop
sudo service rabbitmq-server start

Si estamos en un entorno controlado, en este punto haríamos bien en abrir el puerto 5672 si queremos tener acceso la instancia de RabbitMQ.

Lo siguiente que vamos a crear para accere remotamente es un usuario. En este caso el usuario se va a llamar “rabbit” y el password va a ser “rabbit1“. Para ello bastará con ejecutar el comando:

sudo rabbitmqctl add_user rabbit rabbit1

Lo siguiente será asegurarnos de que el usuario tiene suficientes permisos para que no nos de problemas. Para ello ejecutaremos:

sudo rabbitmqctl set_permissions rabbit ".*" ".*" ".*"

Lo último que nos falta es activar una pequeña interfaz gráfica para poder monitorizar un poco nuestra instancia. Para ello vamos a activar uno de los plugins de RabbitMQ.

sudo rabbitmq-plugins enable rabbitmq_management

En este punto, de nuevo, si estamos en un entorno controlado, necesitaremos abrir el puerto 15672.

Si lo hemos hecho todo correctamente, tan solo necesitaremos rearrancar nuestra instancia para, a partir de este momento, podremos acceder a la interfaz gráfica con la siguiente URL:

http://servername:15672

Si todo ha ido bien, nos aparecerá una pantalla pidiendonos los credenciales de acceso, recordemos “rabbit/rabbit1” y, tran introducirlos, poder acceder a la interfaz de RabbitMQ.

Hasta aquí por hoy. Nos vemos.

 
2 comentarios

Publicado por en 3 septiembre, 2014 en prácticos

 

Probando nuestro firewall

Hace ya mucho tiempo escribí en este blog un artículo sobre la herramienta hping3 en el que hablaba de como falsificar la dirección IP desde la que se enviaba un paquete a través de la red. Dada la gran versatilidad de esta herramienta hoy os voy a hablar de otra de las tareas para las que se suele utilizar esta herramienta, en este caso, probar las reglas de nuestro firewall.

Una parte muy importante del bastionado de nuestros sistemas, es la de que nuestros firewall estén bien configurados para, de esta forma, solo permitir el acceso a aquellos servicios que nosotros ofrecemos al exterior e impedir el acceso a todo lo demás. Para esto, lo más habitual suele ser tener extensas (o no tan extensas) listas de reglas a aplicar en nuestro firewall. Después de aplicar estas reglas un paso básico, muchas veces olvidado, debería ser el de probar estas reglas, ya sea por despiste, descuido o por la existencia de otras reglas en conflicto, muchas veces nos podemos llevar desagradables sorpresas que no queremos que sea un cliente quien nos notifique o peor aún, que lo descubramos tras el resultado de un ataque.

En este escenario en el que necesitamos probar las reglas dadas de alta en nuestro firewall es cuando la herramienta hping3 nos puede ser de gran utilidad, ya que nos permite crear paquetes de diferentes tipos para poder probar nuestras reglas.

En general, en el artículo, estoy hablando de probar las reglas de un firewall, pero también nos puede servir en el mismo modo para probar nuestros sistema IDS (Intrusion Detection System). Pero bueno, en el ejemplo que voy a poner a continuación, nos vamos a centrar en la prueba de una regla del firewall.

Para ver la información general sobre el comando, bastará con ejecutar en la consola el comando:

hping3 -h

Este nos mostrará las diferentes opciones de las que disponemos.

A modo de resumen y que nos sean útiles para este artículo, tenemos:

Definir protocolo

No.    Abrev.    Largo            Descripción
0                                           Por defecto se envía un paquete TCP
1        -0           –raw-ip         Envía paquetes RAW IP
2        -1           –icmp           Envía paquetes ICMP
3        -2           –udp             Envía paquetes UDP
4        -8           –scan           Establece el modo escáner
5        -9           –listen          Establece el modo escucha

Paquetes TCP

No.    Option    Flag name
0                       Paquete TCP por defecto
1        -S           syn
2        -A           ack
3        -R           rst
4        -F           fin
5        -P           psh
6        -U           urg
7        -X           xmas: flags fin, urg, psh set
8        -Y           ymas

 

Pero bueno, vamos a empezar con un pequeño ejemplo. Yo para las pruebas he utilizado una máquina virtual con linux en la que he definido las siguientes reglas en el firewall:

  • Aceptar paquetes TCP al puerto 22 (SSH).
  • Denegar todo lo demás.

Tras esto, vamos a probar la regla:

Primero probaremos el caso que debería funcionar. Para ello mandaremos un paquete TCP SYN al puerto 22:

hping3 192.168.1.82 -c 1 -S -p 22

Esto nos tendría que devolver que nuestro paquete ha sido recibido

Ahora vamos a probar los casos en los que deberíamos ser rechazados.

Primero probaremos con un mensaje ICMP:

hping3 -1 192.168.1.82 -c 1

Tras ejecutarlo, deberíamos ver que nuestro paquete se ha perdido.

El siguiente paquete que debería ser rechazado que vamos a probar es un paquete como el TCP pero utilizando UDP:

hping3 -2 192.168.1.82 -c 1-S -p 22

Como vemos, si todo ha ido bien con nuestra nueva regla, este paquete es rechazado también.

En este sentido, podemos crear y probar tantas reglas como queramos, incluso podemos crear nuestros propios scripts para probarlas teniendo scripts para diferentes configuraciones o entornos.

Bueno, hasta aquí hemos llegado, el ejemplo ha sido bastante simple, pero creo que tenéis la suficiente información como para lanzaros a jugar un rato con hping3 y a utilizarlo seriamente. Nos vemos.

 
Deja un comentario

Publicado por en 25 agosto, 2014 en seguridad

 

Buscando personas

A diferencia de los artículos habituales, el que voy a escribir hoy carece de fundamentos técnicos y espero que pueda llegar a ser entendido por todos aquellos lectores que lo tengan en sus manos sin importar la disciplina en la que se manejen.

El artículo simplemente muestra como a partir de un pequeño dato, un poco de paciencia y la utilización de herramientas como Google, Facebook, Twitter u otras páginas a las que estamos acostumbrados, podemos encontrar a una persona de la cual no tenemos nada excepto su nombre. Además, vamos a ver como podemos averiguar más cosas de ella sin mucho esfuerzo, principalmente, debido al poco o inexistente cuidado que tiene la gente a la hora de configurar su privacidad en redes sociales o a la hora de dar sus datos.

Antes de empezar, decir que todos, repito, todos los nombres utilizados en el artículo son ficticios y que esto solo se ha hecho como estudio y curiosidad de ver si se podía o no hacer tras una larga discusión sobre ello.

Pues bien, vamos a empezar. Para ello, lo primero es ponernos en situación:

Imaginemos que recientemente hemos llegado a una ciudad nueva y que nos hemos apuntado a una de estas páginas donde se organizan grupos para quedar y hacer muchas y variadas actividades. En está página, llamémosla “grupitos.org”, para darse de alta en un grupo basta con poner un alias y subir una foto nuestra para que la gente al vernos nos reconozca y se pueda aprender nuestro nombre. Normalmente, subimos una foto nuestra que tengamos a mano y como nombre utilicemos el nuestro o como nos suele llamar la gente. Por ejemplo, “Pedro Martínez Lopez” utilizaría el alias “pedrito”.

Hasta aquí todo bien, estamos apuntados a un grupo con más gente de las cuales tenemos una foto cualquiera (no comprometedora) y un alias.

Un día, en una de estás reuniones, uno de los integrantes del grupo aparece con otra persona que no es del grupo, dicha persona se presenta como “juan” y pasa la tarde con el grupo entre conversación de todo tipo. Al finalizar la reunión, dicha persona desaparece con lo cual no tenemos más datos sobre ella. Pero uno de los miembros del grupo, decide que quiere saber más sobre ella.

Partiendo de la base de que solo tenemos: El alias y la foto de su supongamos amigo “pedrito”, el nombre/alias de dicha persona y que la hemos visto en persona, ¿cuanta información de dicha persona creéis que se puede obtener? Pensadlo un poco antes de seguir leyendo…

¿Ya?, pues bien, si la conclusión a la que habéis llegado es diferente de “mucha”, estáis muy equivocados, y no hace falta ningún tipo de conocimiento extraordinario. Vamos a ver como.

Para empezar, nos centraremos en nuestro amigo “pedrito”, él no nos interesa, pero tenemos un dato más que de “juan” que es a quien buscamos, tenemos la foto de “pedrito”. Obviamente, realizar búsquedas por cualquiera de los dos nombres en Google o Facebook sería una pérdida de tiempo, solo la casualidad nos llevaría a encontrarlos pero, como ya he dicho, tenemos la foto de “pedrito”.

Google cuenta con una herramienta que nos permite hacer búsquedas a partir de una foto, no es muy conocida, pero está ahí al alcance de todo el mundo. Para el que no la conozca la dirección es:

http://images.google.com

La idea es, tu subes una foto y Google busca coincidencias en la web de dicha foto, muy divertido.

Entonces, el primer paso es subir la foto de “pedrito” a Google Images y ver que nos ofrece. Cuando examinamos los resultados, vemos que ha utilizado la misma foto en diferentes redes sociales (bastante común) y que, de una forma u otra, está ha sido indexada por Google. Pero entre los distintos resultados, el que más nos llama la atención en este caso concreto es el de Twitter, porque en dicha cuenta está utilizando su nombre completo, supongo que para dar visibilidad a su perfil profesional o similar.
Pues bien, ya tenemos de:

  • pedrito: Alias, fotos, algunas cuentas en diferentes redes sociales y nombre completo.
  • juan: Seguimos solo con el alias.

Para el siguiente paso, aunque concretamente para el supuesto que estábamos utilizando la cuenta de facebook no salía en los resultados, nos dirigimos a Facebook y buscamos a pedrito por su nombre completo. No tardamos nada en encontrar su cuenta de Facebook con la que obtenemos mucha información sobre él, ya que la privacidad no está demasiado bien configurada.

En este punto, no es “pedrito” el que nos interesa pero, vemos que en la cuenta de Facebook de “pedrito” tenemos acceso a su lista de amigos. Es de suponer, que si en la vida real es amigo de “juan”, en la virtual también lo será. Y… ¡Bingo! Encontramos a “juan” ya que como lo hemos visto anteriormente, podemos reconocerlo sin dificultad, además de ser uno de los pocos juanes en este caso amigos de “pedrito”.

En este punto, tenemos la cuenta de Facebook de “juan” que tampoco está del todo bien configurada. En ella, podemos ver su nombre completo, ya que lo está usando, su bibliografía, un par de fotos y poco más. Umm… nos es mucho pero, por algo se empieza.

Tras obtener el nombre completo, podemos lanzar una búsqueda en Google para obtener más información sobre “juan” y con ello encontramos su universidad, algunos grupos deportivos donde ha estado, la carrera que ha estudiado, un montón de información.

En facebook, aunque “juan” no es dado a publicar nada, sí que podemos ver su resumen biográfico, y sí que se nos muestra los amigos que ha agregado cada año. Tras un leve vistazo, podemos deducir que “juan” ha estado viviendo en un par de paises diferentes durante estos años, ya que, durante fechas concretas ha agregado a mucha gente de dichos paises.

Y así podemos seguir un rato más, podemos afinar las búsquedas en Google e ir averiguando más cosas.

Como aquí ya se ha demostrado que se puede hacer, voy a parar, pero los límites de donde buscar y como establecer relaciones o deducir información, solo los pone vuestra mente.

Espero que hayáis disfrutado leyendo el artículo tanto como yo he disfrutado haciéndolo, y que a pesar de todo lo que pone aquí, os quedéis con dos moralejas:

  • Cuidad las opciones de privacidad de vuestras redes sociales y páginas de internet.
  • Todo lo que sube a la red, tarde o temprano, será descubierto por alguien.

Nos vemos.

 
Deja un comentario

Publicado por en 9 agosto, 2014 en curiosidades, offtopic

 
 
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.