Enjaular usuario mediante CHROOT para acceder solo por SFTP

Transferir archivos sigue siendo una actividad importante a nivel corporativo. No obstante, los servicios como FTP o FTPs no son los más adecuados dado que los datos son de facil acceso, pues viajan sin encriptar através de la red.

La solución más práctica es SFTP, un protocolo interno de SSH, mediante el cual la información viaja encriptada de extremo a extremo. Sin embargo, crear el usuario y asignarle una contraseña no es suficiente si se quiere mantener un estandar de seguridad. Así mismo, mejorar la seguridad a veces causa que el servicio esté inaccesible por problemas de permisos.

Veremos como configurar el servidor para dar los permisos precisos sobre carpetas puntuales a multiples usuarios.

Como bonus, vamos a generar un conjunto de claves rsa publico-privada para acceder sin necesidad de contraseña.


En primer lugar, crearemos un grupo con el cual administraremos a todos los usuarios a nivel SSH

#groupadd usuarios-sftp

a continuación definimos la carpeta raíz donde estarán los directorios de todos los usuarios

#mkdir /carpetas-sftp

seguidamente editaremos el archivo sshd_config para asociar los recursos creados.

#nano /etc/ssh/sshd_config

Comentamos el comando Subsystem y añadimos las lineas siguientes

 #Subsystem       sftp    /usr/libexec/openssh/sftp-server

 Subsystem       sftp     internal-sftp

 Match Group usuarios-sftp

 ChrootDirectory /carpetas-sftp/%u
 ForceCommand internal-sftp
 AllowTCPForwarding no
 X11Forwarding no

Reiniciamos ssh

systemctl restart sshd

Creamos nuestros usuarios

useradd usuario1 -g usuarios-sftp

Desde aquí tenemos 2 opciones. Manejar contraseñas o archivos de llave (.key, .ppk).

Opción 1: Contraseña.

passwd usuario1

Opción 2: Generar archivo de llave

su usuario1
mkdir ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
nano ~/.ssh/authorized_keys

Colocar una llave pública previamente creada con openssh o puttygen (tutorial próximamente) y guardar el archivo.

exit

Finalmente impedir que el usuario pueda acceder mediante ssh

usermod -s /usr/sbin/nologin usuario1

Creamos la carpeta destino y asignamos permisos.

mkdir /carpetas-sftp/usuario1
mkdir /carpetas-sftp/usuario1/data
chown root.root /carpetas-sftp/usuario1
chmod -R 0755 /carpetas-sftp/usuario1/
chown usuario1:usuarios-sftp /carpetas-sftp/usuario1/data
chmod -R 0755 /carpetas-sftp/usuario1/data/

HSRP con IP SLA (Para 2 proveedores)

El HSRP es un protocolo muy importante para evitar una caida del servicio. Las siglas significan Hot Standby Router Protocol y quiere decir que hay un router activo y uno en standby que lo reemplaza si el primero pierde conectividad.

Esto se logra asignando una dirección real y una virtual (VIP) a cada router. La física diferente pero en el mismo segmento y la VIP la misma para ambos. Esta VIP será la IP de GW a configurar en los dispositivos de la red.

Para esto existen pesos de la prioridad. Si el Router 1 (R1) tiene una prioridad 105 y el Router 2 (R2) tiene prioridad 100, el primero tomará el estatus de ACTIVO y el segundo STANDBY. Si el primero cae o baja su prioridad por debajo de 100, el segundo tomará el control.

Esto está muy bien, siempre que se trate de un mismo proveedor. Porque este configura el HSRP para ambas interfaces, de tal modo que si cae el enlace en cualquier punto del lado del ISP, este se activa.

Los comandos son muy simples. En cada router se debe seleccionar la interface adecuada y agregar los siguientes comandos. (usaremos la IP 10.1.1.1/24 para la red interna y la 172.20.33.121/29 para el ISP)

#En R1

#Interface externa
R1(conf)#interface gigabitEthernet0/0
R1(conf-int)#ip address 172.20.33.122 255.255.255.248
R1(conf-int)#standby 1 ip 172.20.33.121
R1(conf-int)#standby 1 priority 105
R1(conf-int)#standby 1 preemt
#Interface interna
R1(conf)#interface gigabitEthernet0/1
R1(conf-int)#ip address 10.1.1.2 255.255.255.0
R1(conf-int)#standby 2 ip 10.1.1.1
R1(conf-int)#standby 2 priority 105
R1(conf-int)#standby 2 preemt

#En R2

#Interface externa
R2(conf)#interface gigabitEthernet0/0
R2(conf-int)#ip address 172.20.33.123 255.255.255.248
R2(conf-int)#standby 1 ip 172.20.33.121
R2(conf-int)#standby 1 preemt
#Interface interna
R2(conf)#interface gigabitEthernet0/1
R2(conf-int)#ip address 10.1.1.3 255.255.255.0
R2(conf-int)#standby 2 ip 10.1.1.1
R2(conf-int)#standby 2 preemt

Sin embargo, esto se complica cuando tratamos con dos proveedores distintos. Se debe a que no podemos configurar el HSRP del lado del ISP.

Felizmente lo podemos solucionar configurando un SLA (Service Level Agreement) para IP.
Para ello solo tenemos que configurar la interface interna pero previamente crear el SLA. Debemos saber cual es la IP de la interface externa (172.20.33.145) y el siguiente salto (172.20.29.38), según sea el caso.

#En R1

R1(conf)#ip sla monitor 1
R1(conf-ip-sla)#type echo protocol ipIcmpEcho 172.20.29.38 source-ipaddr 172.20.33.145
R1(conf-ip-sla)#frequency 5
R1(conf-ip-sla)#end
R1(conf)#ip sla monitor schedule 4 life forever start-time now
R1(conf)#track 1 rtr 1 reachability
#Interface interna
R1(conf)#interface gigabitEthernet0/1
R1(conf-int)#ip address 10.1.1.2 255.255.255.0
R1(conf-int)#standby 2 ip 10.1.1.1
R1(conf-int)#standby 2 priority 105
R1(conf-int)#standby 2 preemt
R1(conf-int)#standby 2 track 1 decrement 10

En R2 mantenemos la configuración de la interface interna según el ejemplo inicial.

Lo que hacemos es hacer un ping constante al siguiente salto de nuestro enlace principal. De este modo, si en cualquier parte de dicho enlace se pierde conectividad, el ping devolverá error y se activará el HSRP.

Construir un servicio WS SOAP for Dummies

Un servicio WS SOAP es un servicio SOAP sobre web. La idea es transferir la información mediante xml.

Hoy vamos a construir un servicio WS SOAP desde cero y tendremos un servicio de Pruebas para emular el consumo del servicio. Así mismo, trabajaremos con una persistencia simple DAO y así guardar/recuperar información de una base de datos SQL Server. Esto último solo es para aprovechar mejor el servicio.

El ejemplo a continuación es un servicio de vehículos, pero puede adaptarse para trabajar con usuarios, productos, animales y/o añadir más objetos.

En la vista observamos 2 proyectos: El servicio WS_SOAP y el WS_TEST_SOAP. En WS_SOAP hemos creado dos carpetas (Dominio y Persistencia) solo para mantener el orden. En Dominio se agregarán las clases de los objetos que iremos añadiendo y en Persistencia estará el archivo de conexión (ConexionUtil) y los métodos de cada clase.

En primer lugar definiremos los atributos de nuestra clase Vehiculo.cs. Nuestro Vehiculo contará con una Placa, será de una Marca y Modelo definidos.

Luego pasaremos a indicar que elementos serán serializados. Esta parte es importante porque a nivel de servicios no se envian variables con sus tipos, sino que pasan tramas de bits que luego serán interpretadas según los metadatos.

Así pues, el DataContract define un espacio de nombre XML para que la información pueda ser almacenada; mientras que los DataMember (uno por cada atributo) indican el nombre con que será representado y que dicho atributo será serializado.

Ahora crearemos una clase de apoyo para conectarnos a la base de datos: ConexionUtil.cs

Solo contiene un método que retorna una cadena de conexión a la base de datos. Recuerden poner el nombre de la base de datos con la que estén trabajando. Si la base de datos no es local, en Data Source cambien el punto por la IP del servidor correcto.

Ahora configuramos VehiculoDAO. Una clase que almacenará los métodos de Vehiculo. De momento usaremos 2: Crear y Obtener; pero se pueden añadir incluso los métodos para las validaciones (Documento válido, usuario NO repetido, etc).

Ahora configuremos nuestro servicio web con WS SOAP. Para esto, creamos un nuevo elemento dentro del proyecto.

Click derecho sobre el proyecto --> Agregar... --> Nuevo elemento.

Buscamos "Servicio WCF". Le damos un nombre apropiado y luego click en "Agregar"

Se generará más de 1 archivo:

IVehiculosSVC, VehiculosSVC y VehiculosSVC.svc, este último dependiente del anterior.

El primero tiene una I adelante porque es la Interfaz. Este es un archivo donde solo se declaran las operaciones y da la cara al servicio.


VehiculosSVC.svc.cs es donde se implementan las operaciones declaradas en la Interfaz; es decir, añadiremos aquí la lógica de cada operación.

Por defecto, se abrirá el archivo IVehiculosSVC. Analicemos su estructura.

En primer lugar veremos unas etiquetas llamadas ServiceContract y OperationContract.

El ServiceContract sirve para definir el servicio a brindar, mientras que los OperationContract indican que operaciones del servicio se van a exponer y podrán ser consumidas por terceros.

Esto es importante porque nos permite usar nuestros métodos sin exponerlos directamente.

Pasamos a borrar el OperationContract de Ejemplo y agregamos las nuestras (Crear y Obtener).

Para evitar confusiones, nuestras operaciones deben tener nombres distíntos a nuestros métodos. En nuestro caso los métodos tienen nombres básicos como Crear y Obtener mientras las operaciones son CrearVehiculo y ObtenerVehiculo.

Pasamos al archivo VehiculosSVC.svc.cs. Tenemos que implementar las operaciones declaradas en la interfaz. La forma más sencilla es ubicar el cursor sobre la Interfaz a quien implementamos, abrir el menú contextual y seleccionar "Implementar la interfaz..."

Ahora solo tenemos que reemplazar las excepciones indicadas por nuestro código.

Message Bus - Conceptos

Antiguamente las aplicaciones se diseñaban a medida para cada escenario concreto. Con el uso intensivo de la red, se vió pertinente empezar a intercambiar información entre los distintos sistemas.

El reto consiste en que todas las aplicaciones se comuniquen entre sí de manera apropiada y con el menor costo posible.

En un primer acercamiento, se definió un patrón de canal punto a punto.

El problema es que a mayor número de aplicaciones, crece exponencialmente la cantidad de código a escribir, y así mismo, crece el consumo de recursos de la red si existe mucha demanda.

Para resolverlo, se llegó al patrón Bus de Mensajes

Con este patrón, definimos un sistema independiente que administrará todos los mensajes. De esta manera, la aplicación se deberá modificar como máximo una sola vez para enviar los mensajes a este bus. Luego, este se encargará de reenviar el mensaje a todas las aplicaciones consumidoras.

Cabe decir que la entrega de los mensajes es bajo el patrón Canal Publicador-Subscriptor, pues ciertamente habrán algunas aplicaciones que no requerirar los mensajes; ahorrando recursos de procesamiento y de red.

Fuentes:

http://www.enterpriseintegrationpatterns.com/MessageBus.html

https://msdn.microsoft.com/en-us/library/ff647328.aspx

Entendiendo Hadoop

Con la explosión de internet se empezaron a generar grandes cantidades de datos, sobre todo datos no estructurados. El problema es que analizar los datos se vuelve costoso, en primer lugar por la cantidad y luego por su falta de estructura.

Hadoop es un framework desarrollado en JAVA para sistemas de archivos distribuidos que permite el procesamiento de grandes volúmenes de datos, ya sean estructurados o no, de manera escalable mediante clusters. Además permite una alta disponibilidad. Puede migrar de unos cuantos nodos hasta miles de ellos de forma rápida y confiable.

Trabaja con una arquitectura maestro/esclavo donde existe un nodo maestro encargado de realizar el procesamiento y almacenar la información en múltiples nodos esclavos. También existe un nodo esclavo pasivo, que toma las funciones del nodo maestro cuando este falla.

Así mismo, los nodos están agrupados en Racks (Capaces de mantener hasta 40 nodos maestros) y estros se comunican con otros Racks para intercambiar información y procesos cliente, el cual es cualquier petición de un nodo maestro (almacenamiento o recuperación de data).

La idea subyacente está en los procesos cliente. Estos se dan en cada nodo maestro por demanda, lo que quiere decir que solo usa los recursos del nodo, o en su defecto, los del rack. Esto reduce el tráfico en la red troncal permitiendo máyor concurrencia.

Hadoop se aprovecha del uso de XML para intercambio de información, por lo que es muy sencillo agregar nuevos racks y nodos a un ecosistema.

Adicionalmente, permite trabajar con distinto hardware, incluyendo servidores económicos. Lo que viene bien pues abarata costos y distribuye aún más el procesamiento.

Fuentes:

http://www.cloudera.com/content/cloudera/en/about/hadoop-and-big-data.html

http://es.wikipedia.org/wiki/Hadoop

http://momentotic.com/2013/05/16/que-es-hadoop/

HTTP/2 - Por una navegación más rápida

gizlogic.com

El protocolo HTTP 1.1 (su última actualización) tiene entre nosotros alrededor de 16 años, pues es un estandar desde 1999. Una eternidad en el espacio-tiempo tecnológico.

Desde Google pensaban que la navegación mediante este protocolo es lenta y podía acelerarse. Es por esto que desarrollaron SPDY (léase "Speedy"). Estamos hablando de noviembre de 2009 y este proyecto está en sus fases iniciales, aunque en pruebas de laboratorio ya presentaban una mejora de hasta 50% en velocidad de carga.

Luego de un proceso de mejora continua, el proyecto SPDY entra a una etapa de estandarización de la tecnología (Julio de 2012) y pasados 5 meses se convierte en un borrador de HTTP/2 en la IETF (Internet Engineering Task Force).

Hace algunos días, desde la IETF, mencionan que la especificación HTTP/2 por fin está concluida y empieza la fase en la cual los navegadores deben implementar el nuevo protocolo en su código.

¿Qué ventajas provee HTTP/2?

La más visible es la mejora en velocidad de carga de las webs y una reducción de consumo de ancho de banda.

Todos los elementos de una página web (imágenes, archivos CSS, JavaScripts y el propia página HTML) son considerados como objetos. Por lo tanto, para cada web podemos tener cientos si no miles de objetos.

En HTTP/1.x las conexiones apuntan a solicitar objetos únicos. Los navegadores pueden realizan una descarga en paralelo de todos los objetos que necesitan de un site, pero lo hacen generando múltiples conexiones hacia el mismo servidor. Esto genera consumo de red y tiempo adicional.

A nivel de desarrollo, esto significa un incremento significativo en la velocidad de transferencia de información entre servicios, ya sea por WS SOAP o por REST.

fuentes:

https://www.mnot.net/blog/2015/02/18/http2

http://arstechnica.com/information-technology/2015/02/http2-finished-coming-to-browsers-within-weeks/