Archivos del sitio
Seguridad avanzada en Linux: Port Knocking
Una de las principales vulnerabilidades en un sistema es el hecho de tener que dejar abiertos los puertos cuyos servicios desea proporcionar. Si bien servicios como el http o el smtp deben permanecer abiertos para ser funcionales, es posible hacer que los servicios neurálgicos de nuestro sistema solo sean accesibles cuando verdaderamente son necesarios.
- ¿A qué nos referimos? A la posibilidad de ofrecer un servicio sobre un puerto cerrado.
- ¿Mande? Dime qué has fumado que yo también quiero…
- No he fumado nada incrédulo, hablo de la estrategia del port knocking.
- Em, ¿me lo explica?
- Desde luego.
El port knocking es una estrategia que permite a un usuario solicitar la apertura de un puerto para disponer de un servicio inicialmente cerrado. Esta solicitud tiene la forma de secuencia de paquetes de autenticación enviados a puertos cerrados. Es posible enviar información a través de puertos cerrados y en ausencia de otro servicio de red, ya que nuestro cortafuegos y otras utilidades como tcpdump pueden configurarse para observar todos los paquetes que llegan sin importar si luego serán entregados a un servicio. La gran potencia del port knocking radica en el hecho de trabajar siempre con puertos cerrados, lo cuál no deja resquicios de seguridad.
Una forma de limitar los usuarios entrantes es por filtrado de IP, pero esta ténica tiene muchas debilidades: puertos abiertos, suplantación fÃsica, imposibilidad de movilidad de los usuarios… Port Knocking resuelve todos estos problemas y además aporta más seguridad.
El port knocking fue descrito por primera vez en la revista SysAdmin. Existen diversas formas de implementarlo, una bastante popular es doorman, aunque aquà haremos una implementación muy sencilla basada en tcpdump y en tan solo 4 pasos.
Paso 1: cerrar todo. Lo primero es usar una configuración muy restrictiva en nuestro iptables: lo cerramos todo. Un ejemplo simple serÃa:
#!/bin/sh
#firewall.sh
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP
Cabe destacar el uso de DROP, nunca de REJECT en nuestra polÃtica de rechazo ya que debe producirse una denegación silenciosa del servicio que no provoque respuesta al supuesto intruso. Esta configuración no permite nuevas conexiones sobre puertos cerrados pero sà permite continuar aquellas iniciadas.
Paso 2: apertura de puerto. Diseñamos un script que durante abra durante 10 segundos por ejemplo el puerto solicitado si recibe un paquete cuyo “santo y seña” es correcto.
#!/bin/bash
# guard.sh
# acepta los paquetes entrantes
/sbin/iptables -I INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2
sleep 10
# rechaza los paquetes entrantes
/sbin/iptables -D INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2
A los 10 segundos el puerto se cierra, pero nosotros ya hemos iniciado la conexión (SSH, FTP, etc) y el firewall permite continuar conexiones iniciadas. ¡Estamos trabajando sobre un puerto cerrado!
Paso 3: escucha activa. El port knocking se asemeja a las famosos santo y seña de las pelÃculas de espionaje donde abrimos una puerta llamando con “2 toques largos, 3 cortos y uno largo”. En nuestro caso la contraseña correcta podrÃa ser que el paquete recibido tuviera una cabecera de valor 17. Debemos diseñar un script que permanezca a la escucha e identifique la llamada correcta. Cuando ésta se produzca lanzará guard.sh lo que abrirá el puerto durante 10 segundos, tiempo suficiente para entrar.
tcpdump -l -O "tcp[2:2]>=1000 and tcp[2:2]<=10999 and tcp[4:4]=17 and tcp[tcpflags] & tcp-syn!=0" | sed -u 's/.*IP \([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\).*\.10*\([0-9]*\): S.*/\1 \2/' | xargs -t -l -i bash -c "/root/guard.sh {} &"
tcpdump no permite especificar intervalos de puertos, cosa que suplimos con la sintaxis tcp[2:2] que indica un campo de 2 bytes en la cabecera TCP a partir del byte 2 (tcp[inicio:longitud]). Nuestra estrategia de implementación en esta ocasión consiste en eliminar la cabecera de 2 bytes y abrir el puerto resultante. Asà por ejemplo con 1022 abrirÃamos el puerto 22 (SSH).
Paso 4: llamada. Nuestro sistema permanece atento, vamos a hacer la llamada correcta:
# Sintaxis:
# sendip ip_origen puerto_origen ip_destino puerto_destino
# 1000 < puerto_destino <=10999
sendip -p ipv4 -p tcp -is $1 -ts $2 -td $3 -tfs 1 -tn 17 $4
La contraseña 17 es correcta y solicitamos la apertura del puerto para nuestra IP.
Con estos sencillos pasos conseguimos que servicios tan útiles como el FTP, de los cuáles los administradores siempre son recelosos, puedan ofrecerse con riesgo nulo. El ataque de un intruso es prácticamente imposible.
Si deseas profundizar en el uso de port knocking recomiendo que te documentes sobre Doorman, de Bruce Ward, que se caracteriza por su original y elegante enfoque del port knocking.
Hasta la próxima entrega.
Una de patrones de creación(Parte II )
Después de una pequeña introducción a los patrones Parte I , vamos a hacer un resumen de los patrones de creación más utilizados.
Estos patrones están orientados a facilitar los procesos de creación de objetos en el sistema, consiguiendo simplificar la creación de objetos complejos, permitiendo la instanciación sin identificar la clase especÃfica en el código y centralizando el proceso de construcción.
Hay bastantes mas patrones que podrÃa ser incluidos en esta lista, pero los mas relevantes en mi opinión son:
- Abstract Factory ( Fábrica abstracta)
- Builder(Constructor)
- Singleton(Único)
AbstractFactory
Proporciona una clase encargada de la generación de familias de objetos sin tener que especificar su clase concreta. Deberemos usar este patrón cuando:
- La aplicación cliente debe ser independiente del proceso de creación.
- La aplicación debe poder funcionar con una o mas familias de objetos( con una implementación diferente)
- Deseamos revelar solo los contratos y no las implementaciones.
- Necesitamos interfaces genericas adaptadas a productos abstractos.
Una fábrica abstracta ayuda a incrementar la flexibilidad tanto en tiempo de ejecución como en tiempo de ejecución.
Builder
Simplifica la creación de objetos complejos definiendo una clase cuyo propósito sea construir instancias de otra clase. Debemos usar este patrón cuando:
- Para crea objetos con una estructura interna compleja y con atributos dependientes entre si.
- Utiliza objetos del sistema conflictivos, como pueden ser recursos JNDI.
- Pueden necesitar de un sistema de cache centralizado.
Singleton
Permite tener una única instancia de una clase, a la que puedan tener acceso todas las clases del sistema.
A pesar de su simplicidad, es uno de los patrones mas utilizados. Una correcta implementación (sacada de la wikipedia) del patron Singleton podrÃa ser:
public class Singleton{
private static Singleton INSTANCE = null;
// Private constructor suppresses
private Singleton() {}
private synchronized static void createInstance() {
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
}
public static Singleton getInstance() {
if (INSTANCE == null) createInstance();
return INSTANCE;
}
}
Las 14 principales vulnerabilidades de seguridad
En vista que el señor dbejar nos está dejando en evidencia va siendo hora que los demás contemos algo. En esta ocasión voy a tirar hacia sistemas y voy a escribir el primero de una serie de artÃculos relacionados con seguridad que iré publicando en sucesivas entregas.
Como es la primera empecemos despacito para ir calentando motores. Lo leà en un libro bastante bueno (a ver si lo encuentro, solo conservo unos apuntes) y el punto se titula, como vuestras mentes lúcidas habrán deducido, “Las 14 principales vulnerabilidades de seguridad”. En ella repasamos los principales puntos por los que un hacker podrÃa atacar nuestro sistema. Contempla tanto sistemas Windows como Linux, es un “vuelo rasante”. Vamos al turrón:
1) Control de acceso inadecuado al router: un ACL del router que se haya configurado erróneamente puede permitir la filtración a través de ICMP (Protocolo de Control de Mensajes de Internet), IP NetBIOS y permitir accesos no autorizados a determinados servicios en sus servidores DMZ (Zona DesMilitarizada).
2) Los puntos de acceso remoto no seguros y no vigilados proporcionan uno de los modos más sencillos de acceder a nuestra red. Es conveniente no exponer nuestros archivos sensibles.
3) La filtración de información puede proporcionar al atacante información sobre la versión de nuestro sistema operativo, aplicaciones, usuarios, grupos, servicios compartidos, información DNS a través de transferencias de zona y servicios en ejecución tales como SNMP, finger, SMTP, telnet, rusers, rcpinfo, NetBios…
4) Los host que ejecutan servicios innecesarios tales como RCP, FTP, DNS, SMTP, etc son una fuente innecesaria de puertos vulnerables.
5) Contraseñas reutilizadas, sencillas o fácilmente adivinables a nivel de estación de trabajo. Caer ante un ataque de diccionario es uno de los errores más frecuentes en un sistema si no se educa adecuadamente a sus usuarios.
6) Cuentas de usuarios con privilegios excesivos. En combinación con 5 es bajarse los pantalones ante el resto del mundo.
7) Sevidores de internet mal configurados, especialmente archivos de comandos CGI en servidores web y FTP anónimos con permisos de escritura.
8) Si un servidor DMZ queda comprometido un ACL mal configurado en el router puede dar acceso al intruso a la zona interna de nuestra red.
9) Aplicaciones que no estén convenientemente actualizadas con sus correspondientes parches de seguridad.
10) Excesivos controles de acceso en los recursos compartidos de NT y exportaciones mediante NFS en Unix.
11) Contar con excesivas relaciones de confianza tales como los Dominios de Confianza en NT y los archivos .rhost y hosts.equiv de UNIX puede orientar al atacante un acceso a sistemas sensibles.
12) Servicios no autenticados tales como X-Windows que permiten a los usuarios capturar pulsaciones de tecla realizadas de forma remota.
13) Capacidades de registro, detección y vigilancia inadecuadas, sin cruzar la frontera que puede suponer invadir la privacidad de los trabajadores.
14) Carencia de directivas, procedimientos, normativas y directrices de seguridad aceptadas y convenientemente elaboradas.
Y si me apuraÃs añadirÃa la 15, El arma más eficaz del hacker: la ingenierÃa social.
Bueno, ¿y todo este tostón para qué? Pues en principio solo para que te hagas preguntas sobre tu sistema. En próximos artÃculos iremos al grano con soluciones prácticas para cada apartado con la idea de amargar la vida al más perseverante de los hackers.
Sed buenos.
Concatenacion de Strings en Velocity
Concatenar strings en velocity no es tan simple e “intuitivo” como hacer:
$bufferstr=$str1+$str2+"lala"�
Sin embargo, existe una manera, realmente siemple, que puede que te haga tirarte de los pelos si has llegado hasta aqui con una busqueda de google.
Para hacer concat de strings en velocity basta con hacer (en el ejemplo anterior):
$bufferstr="$str1$str2lala"o bien:
$bufferstr="${str1}${str2}lala"�
Realmente tonto, pero muy util.
Qubits y criptografia quantica simplificada
He estado revisando lo que uno se puede encontrar en internet sobre qubits, y mas concretamente sobre criptografia quantica, y me he encontrado con que toda la informacion es o bien muy compleja, con complicadas formulas matematicas o bien se hace mencion a dificiles y relativamente desconocidos, por la mayoria, conceptos de mecanica quantica.
Creo que se pueden hacer ciertas abstracciones y explicar algunos conceptos sin tener que enfangarse en los datos y conceptos complicados en los que se pierden algunos (no se si para demostrar lo que saben, o para ocultar lo que ignoran).
Concretamente, echando mano de algunas simplificaciones, e intentando no perderme en complejas parabolas, como gatos que estan vivos y muertos a la vez, voy a intentar explicar o introducir a lo que se conoce como criptografica quantica para transmisiones. Realmente solo expondre una de sus aplicaciones lo mas *simplificadamente* posible.
Pongamonos en la situacion en la que un sistema A le quiere pasar una informacion al sistema B. Para que la comunicacion se produzca necesitamos, usualmente, una fase de setup en la que A y B se pongan de acuerdo en le protocolo. Esto es, A informa a B de que le va a comunicar, y del significado exacto que va a tener cada secuencia de bits.
Matematicamente los bits son muy faciles de manipular, se ajustan al algebra de Bool, cuyas reglas son bien simples y conocidas por todos (supongo).
Adaptar el caracter binario de los bits a dispositivos fisicos para su almacenamiento o transporte es tambien relativamente sencillo, basta con tener algun dispositivo fisico que tenga dos posibles estados, uno de ellos sera el 0 y el otro sera el 1. El bit se guarda poniendo el dispositivo en un estado u otro, y si el dispositivo se desplaza se produce comunicacion y si persiste en su estado en el tiempo entonces tenemos almacenamiento.
Clasicamente se usan cantidades masivas de electrones para representar un bit en un semiconductor, o de fotones en comicaciones por onda. Asi, en un semiconductor, por ejemplo, un voltaje entre 0v y 1v equivaldrian a un ‘0′ y un voltaje entre 4v y 5v, equivaldrian a un ‘1′ logico.
Pero por que usar cantidades masivas de electrones y fotones para reprensentar una unica unidad de informacion? Por que no hacer que un unico electron almacene, represente, el ‘1′ logico, o que un foton, por ejemplo, transporte una unidad de informacion, un bit? Un hombre, un platano, y un foton, un bit. O mejor dicho un qubit o bit quantico.
Tranquis, no hace falta saber que es el principio de incertidumbre para entender esto… peroooo…. tengo que decir que la mecanica clasica nos permite abstraernos de ese principio de incertidumbre porque usamos cantidades ingentes de particulas y asi la incertidumbre sobre su estado tiende a cero. Pero a medida que disminuimos la cantidad de fotones para representar cada unidad de informacion, las simplificaciones de la mecanica clasica dejan de ser validas, y la incertidumbre se maximiza; empezamos a pisar los terrenos de la mecanica quantica, terrenos que no siempre resultan faciles de entender, y casi nunca son intuitivos.
Por eso ya no podemos hablar de bits, si no de qubits. Un qubit es un objeto que puede guardar un bit pero que es tan pequeño que se ve sometido a las leyes de la mecanica quantica. En realidad un qubit puede hacer y almacenar muchas mas cosas, pero no nos interesan aqui.
Una diferencia clave para el tema que nos ocupa es que un bit clasico puede medirse sin ser alterado, y por tanto se puede copiar, no es ese el caso de los qubits. No podemos medir un qubit! Como suena, si intentamos saber si su valor es 1 o 0, medirlo, habremos modificado su estado, y perdido la informacion para siempre antes de poder recuperarla. Vaya puto desastre, guardar informacion que no se puede luego recuperar…no tiene sentido…
Ah, pero los fisicos son chicos muy listos, y tienen la solucion! A un qubit no lo podemos medir pero si que le podemos preguntar “vales 1?” y nos dira SI o NO. Ojo, esas son las unicas respuestas que obtendremos. No, nos respondera nunca, “casi”, o “70% cierto”, o “falso por 35º”…. no, unicamente nos dira SI o NO. Esto es importante, para la transmision segura, pero luego veremos por que. Otra diferencia clave es que, solo podemos preguntar una unica vez por su estado, porque intentar averiguar el estado quantico de una particula subatomica modifica irrevarsiblemente su estado…. podemos preguntarle, nos respondera, pero al responder, su estado se pierde, y para siempre. No hay una segunda oportunidad. Solo una pregunta.
Ahora, pongamos que en una transmision de informacion, usamos un foton, el foton resulta un perfecto vehiculo para nuestro proposito porque es pequeño, y viaja rapido… digamos que mas rapido imposible. Los fotones (casi todos los tipos) tienen un campo electrico y un campo magnetico oscilando simultaneamente. Si lanzamos a nuestro amigo foton en una direccion Z, su campo electrico podra ir en la direccion X (horizontal), en la direccion Y (vertical), o, en cualquier direccion del plano XY (horizontal-vertical). Graficamente seria una canica rodando hacia delante, con su lo-que-sea (campo electrico) en vertical, u horizontal, o haciendo algun angulo diagonal con el suelo.
Y alli llegamos nosotros ‘B’ (en nuestro ejemplo inicial de una transmision) y nos ponemos en la horizontal y preguntamos “oh campo electrico… estas aqui?” (o sea “vales 1?”), y la canica (el foton) nos dice que SI o que NO, cambia la direccion del campo electrico y sigue su camino… Si nosotros sabemos (setup de la transmision) que A nos va a tirar las canicas con sus campos electricos en horizontal o vertical, y nos informa de que la horizontal significa ‘1′ y la vertical ‘0′, tendremos informacion transmitida a altisimas velocidades, usando tan solo un foton para cada bit. Fabuloso!
Pero y si C, un tipo malo, quiere “escuchar” nuestra transmision? Entonces, no solo podria si no que la destruiria al hacerlo. Pongamos que C, se coloca en el la direcion Z entre A y B, y en el plano horizontal, pregunta a cada canica-foton que pasa por ahi: “oye, campo electrico, estas aqui?” o, “foton, vales 1?”, entonces C conseguiria la informacion y al hacerlo la alteraria de modo que B, ya nunca recibiria la informacion. Es esta la tan cacareada eficacia criptografica de los qubits? Menuda decepcion.
Vale, rebobinamos un poco, cuando C empieza a “escuchar” la transmision, B no tarda en darse cuenta de ello al percibir que ninguno de los fotones que pasa le responde SI a la pregunta “vales 1?”. Basicamente porque C, al alterar la informacion hace que el campo electrico del foton se ponga en cualquier direccion del plano XY, y las probabilidades de que el campo alterado se ponga exactamente en la direccion X (horizontal), en el que B esta preguntando, son realmente minimas. Asi rapidamente B notaria que de golpe todos los fotones le responden NO, y el espionaje seria descubierto casi al momento. Suena mejor ahora, no?
Pero aun hay mas. En cuanto B se diese cuenta del espionaje, podria avisar a A, y este, por ejemplo, rotar el angulo del campo electrico 15 grados, o incluso tan solo un grado, y C ya no podria seguir “escuchando”… Por que estara preguntando “vales 1?” en la direccion incorrecta del plano XY… ya hemos dicho que la respuesta solo es SI o NO, nunca un “uuuuyyy, casiii, por un grado”… Asi que C solo obtendria NO como respuesta. Su escucha seria inutil.
Ademas, nuevamente su intento de escucha sera detectado por B. Si la comuncacion es bidireccional, al recibirse unicamente ceros (NOes) en uno de los sentidos, la comunicacion se interrumpe en ambos sentidos, es decir, en cuanto el canal no es seguro la transmision cesa. Cualquier intento de espionaje bloquea automaticamente la transmision.
Si lo pensais es una pena, Jack Bauer ya no tendria que decir nuestra frase favorita:
-”Is it a secure line, isn’t it?!”
Disclaimer: La criptografia es un area en la que Viavansi es fuerte, pero sus aspectos quanticos no son area de negocio, aun :)
Genealogia de genericos en Java5
Pregunta de certificacion; son correctas las siguientes lineas de codigo Java5?
List <Integer> li = new LinkedList <Integer> (); //#1
List <Object> lo = li; //#2
Si habilitais Java5 en vuestros Eclipse, vereis que la linea 2 no compila [ Type mismatch: cannot convert from List<Integer> to List<Object> ]. No es acaso Integer un subtipo de Object? La regla es que en general, cuando de genericos se trata, si Foo es un subtipo (subclase o subinterfaz) de Bar y G una declaracion de tipo generico, *no* se cumple que G<Foo> sea subtipo de G<Bar>. Pero por que esta limitacion?
Volviendo al ejemplo, si la linea #2 fuese valida podriamos hacer…
lo.add(new Object()); //#3
Integer i=li.get(0); //#4
En la linea #4 estariamos asignando un Object a un Integer, una superclase a su subclase. No hace falta que explique las consecuencias desagradables que esto tendria.
Afortunadamente, en Java5 si existe una superclase de todas las listas:
List <?> l_unknown = li; //#2
La lista de tipo ‘?’ si resulta ser supertipo de cualquier otra lista. Asi G<?> seria supertipo de G<Foo> y de G<Bar>.
Hala todos a jugar.
Para aficcionados a los videojuegos
Si te gusta el desarrollo amateur de videojuegos puedes visitar esta página:
No esperes nada espectacular, su único cometido es colgar el material terminado, más bien poco pues la mayorÃa de los códigos se quedan en pruebas.
Actualmente está parada, asà que las fechas que pudiera haber no se deben tener en cuenta pues todos los proyectos están congelados.
Una de patrones (Parte I)
La idea que hay detrás de los patrones de diseño es desarrollar una forma estandarizada para alcanzar soluciones generales a problemas comunes. Si no somos genios, utilicemos las soluciones que ya les funcionaron a ello en el pasado.
Desde la perspectiva del diseño y la arquitectura del software, la abstracción, la reutilización y el uso de patrones, son los tres pilares que garantizan la calidad del software.
Expresando esto de una forma gráfica:
Podemos ver que los fragmentos de código( Ej: scriptles JSP) son muy poco reutilizables, mientras que una buena arquitectura basada en patrones permite una excelente reutilización .
Si los constructores hicieran las casas de la misma forma en que los programadores escribimos el código, el primer pájaro carpintero que viniera distriburÃa la civilización.
Continuara… (Parte || - Patrones estructurales)
Sobre el iPhone
En Gizmodo recibieron trato VIP y tras hacerles una demo del teléfono y dejarles jugar con él, pudieron hacer algunas preguntas a Eddie Cue el videpresidente de Aplicaciones de Apple y a Phil Schiller, vicepresidente senior de Marketing Mundial. Gracias a esas preguntas podemos saber que:
- El iPhone no es blanco porque el negro destaca los colores de la pantalla
- El sistema no es un OSX completo y no será un sistema abierto con una API pública, por lo que no habrá aplicaciones de terceros
- No está previsto el acceso directo a la iTunes Store (de momento)
- No se puede sincronizar vÃa WIFI o Bluetooth, sólo a través del dock
Disponible Google Earth 4 final
Google acaba de lanzar oficialmente su programa Google Earth 4 final para las plataformas Windows, Linux y Mac, justo seis meses después del lanzamiento de la primera beta y hace un año de la versión Google Earth 3.Entre las mejoras de esta aplicación, como podemos ver en su sitio oficial, tenemos un nuevo look, bastante mejorado, facilitándonos una navegación más fluida; podemos ver edificios y paisajes en 3D, me encanta el efecto tridimensional de los montes; compartir información geográfica con otros usuarios, donde podemos ver fotos geolocalizadas, datos enviados desde el GPS, etc , y hasta añadir figuras en 3D que podemos compartir.
Dispone de otras herramientas como las búsquedas de negocios locales, incluidos los españoles, o trazar la ruta de un punto a otro.
Una herramienta que ha mejorado muchÃsimo, sobre todo a nivel de navegación y búsqueda.
Busca esto rápido
Encuentra lo que buscas de forma sencilla usando el buscador.
CategorÃas
Encuentra artículos a través de sus "tags"
Archivos mensuales
Encuentra artículos según el mes en el que fueron escritos.