28
Jul
2011

Plan de Continuidad del Negocio: amenazas

Las amenazas que pueden enfrentar los procesos de una organización pueden ser eventos naturales (inundaciones, terremotos, huracanas, descargas eléctricas), eventos causados por el hombre (ataques, fraude, ausencia) o por desperfectos técnicos (fallas en las comunicaciones, fallas en los sistemas).

Cualquiera sea la amenaza, puede causar escenarios como los siguientes en la organización:

  • Mal funcionamiento de los equipos o equipos no disponibles
  • Utilidades no disponibles (HVAC, energía, líneas de comunicación)
  • Instalaciones no disponibles
  • Personal crítico no disponible
  • Vendedores y proveedores de servicios no disponibles
  • Corrupción de software y/o datos

Es de interés para la organización la naturaleza de la amenaza y el impacto que genera en los recursos o activos que dan soporte a los procesos. La naturaleza de la amenaza permite el desarrollo de planes específicos de prevención y recuperación, mientras que el impacto en los recursos permite tomar acciones concretas para lograr la continuidad de las operaciones.

19
Jul
2011

Plan de Continuidad del Negocio (BCP)

Para la construcción de un Plan de Continuidad del Negocio (BCP) debe comprenderse el objetivo principal de la organización: ¿ser rentable vendiendo productos o servicios? ¿brindar servicios de interés público? ¿brindar servicios relacionados a la salud o binestar de las personas? En otras palabras, ¿qué buscamos estando preparados para continuar las operaciones en el caso de un acontecimiento inesperado?

Es importante en este sentido que la alta gerencia comprenda los objetivos, alcance y beneficios de la continuidad del negocio. Debe realizarse una declaración a nivel de las políticas de la organización donde se establezcan los lineamientos generales y el marco de trabajo para las actividades que engloba. Es indispensable el apoyo de la dirección de la organización, la asignación de recursos humanos calificados, la planificación y el presupuesto.


Leer el resto del artículo »

21
Mar
2011

Funciones virtuales en C++

En la clase pasada de Análisis Numérico, Alejandro mencionó la posibilidad de utilizar funciones virtuales en las clases “padre” definidas en el lenguaje C++.

¿Qué son las funciones virtuales?

Son funciones que pueden ser reimplementadas en las subclases, comportamiento que por defecto no se permite. Si la función es puramente virtual, no existe una implementación en la clase padre sino que se debe especificar en alguna subclase. Es una forma de definir interfaces.

Veamos el siguiente ejemplo tomado del libro C++ GUI Programming with Qt 4 (segunda edición):

#ifndef SHAPE_H
#define SHAPE_H
#include "point2d.h"
class Shape
{
public:
      Shape(Point2D center) { myCenter = center; }
      virtual void draw() = 0;
protected:
      Point2D myCenter;
};
#endif

Allí se puede visualizar que la función draw es virtual. También, podemos ver que es puramente virtual por la definición draw() = 0. ¡Que sintáxis horrible!


Leer el resto del artículo »

13
Mar
2011

Verisign: DNSSEC para .com y .net en 2011

(Ver video)

Supuestamente Verisign estaría aplicando la especificación DNSSEC a las dos zonas más importantes de Internet: .com y .net. Si bien existen actualmente zonas como .se, .br, .gov, .edu que utilizan DNSSEC, este cambio le daría a la especificación un reimpulso y mayor alcance.

Según un anuncio del SeCIU, se está estudiando que en el presente año la zona .uy también utilice DNSSEC.

Sería interesante ver en los navegadores un indicador para diferenciar cuando es posible trazar la cadena de confianza desde el trust-anchor al nombre resuelto y cuando no. Sin embargo, dada la cantidad de sitios que no van a tener Resource Records firmados, el usuario no le prestaría mayor importancia a esto -como sucede con SSL, que no hay demasiada consciencia-. Una vez más: el desafío no es tecnológico, es cultural.


Leer el resto del artículo »

3
Mar
2011

mtrace: debug de memoria en C (LibC)

La función mtrace proporcionada por LibC nos permite trazar todos las operaciones de obtención, redimensionamiento y liberación de memoria realizadas por las funciones malloc, realloc y free respectivamente. De esta forma, es posible detectar memory leaks (memoria sin liberar) en nuestra aplicación.

La función mtrace se vale de la variable de entorno MALLOC_TRACE para conocer la ruta donde guardar el resultado de las operaciones realizadas.

Con la función muntrace podemos detener el monitoreo iniciado por mtrace. Es posible encapsular bloques del programa con mtrace y muntrace.

Código de ejemplo:

#include <stdio .h>
#include <stdlib .h>
#include <mcheck .h>
 
int main () {
 
	setenv("MALLOC_TRACE", "/root/c/mtrace/output", 1);
 
	mtrace();
 
	void* puntero_a_memoria =  (void*)malloc(1);
 
	return 0;
}
</mcheck></stdlib></stdio>

Cambien el path /root/c/mtrace/out por el que les resulte conveniente. El proceso debe tener permisos de escritura allí.


Leer el resto del artículo »

3
Mar
2011

Variables de entorno con LibC

LibC provee algunas funciones para manejar las variables de entorno. Debemos incluir la Standard Library (stdlib.h) para acceder a ellas.

Limpiar las variables de entorno:

int clearenv(void);

Escribir o modificar una variable de entorno:

int putenv(char *string);

El parámetro string es de la forma VARIABLE=valor

Escribir o modificar una variable de entorno:

int setenv(const char *name, const char *value, int overwrite);

name es el nombre de la variable de entorno, value el valor y overwrite (0 o número distinto de 0) permite especificar la acción para el caso de que la variable de entorno ya exista con un valor determinado.

Remover una variable de entorno:

int unsetenv(const char *name);

name es el nombre de la variable de entorno.

3
Mar
2011

Variables de entorno en bash

Las variables de entorno de una shell Linux se utilizan para trabajar sobre ella o para dar información de contexto a los procesos que desde ella se ejecuten. Ese contexto sirve de datos al proceso y le permite, por ejemplo, modificar su compartamiento.

Las shells tienen un conjunto de variables de entorno cargadas por defecto. Los usuarios pueden definir más variables y modificar los valores existentes. Sin embargo, cualquier cambio realizado es temporal: al abrir una nueva shell, nos encontraremos nuevamente en el estado por defecto.

Los siguientes comandos aplican a la shell bash.

Para ver las variables de entorno:

printenv

Para imprimir el valor de una variable específica:

echo $VARIABLE

En caso de que la variable sea utilizada únicamente en la shell, podemos definirla de la siguiente forma:

VARIABLE=valor


Leer el resto del artículo »

2
Mar
2011

Disowning procesos en Linux

disown procesos linux

Cuando ejecutamos procesos en Linux desde un terminal, los procesos quedan “atados”. Esto significa que al cerrar el terminal, los procesos mueren. Voy a comentarles en este artículo dos formas de crear procesos independientes, que pertenecen al usuario desde el que se ejecutaron pero a ningún terminal en particular.

nohup

Lanzamos el proceso de la siguiente forma:

nohup ping 127.0.0.1

Con Ctrl + z detenemos el proceso para volver al terminal. Ingresando bg lo enviamos al background y podremos cerrar el terminal sin que el proceso muera.


Leer el resto del artículo »

26
Feb
2011

ACLs en OS X Server y Linux

El esquema de permisos tradicional en los sistemas UNIX diferencia a los usuarios que pueden leer, escribir o ejecutar un archivo o directorio en tres clases: propietario, grupo y otros. Si bien para muchos escenarios esto es suficiente, puede necesitarse mayor granularidad.

Imaginemos que necesitamos darle al usuario test permisos de lectura sobre el archivo archivo. Supongamos que el usuario y grupo propietarios de archivo son root y wheel respectivamente. Además, supongamos que no queremos que test pertenezca a wheel para no tener permisos sobre archivos que no le corresponde. ¿Cómo resolvemos la situación?


Leer el resto del artículo »

11
Feb
2011

Secure Login en PHP: One time token + SHA1

Estuve haciendo una pequeña demo para demostrar dos conceptos de un formulario de autenticación en php: One time token y SHA1.

¿Cuál es el problema que motiva esta idea?

Si el formulario php envía las credenciales de autenticación del usuario en texto claro al servidor, por más que se guarden hasheadas en la base de datos, cualquier intruso podría caputarlas mientras están en viaje y utilizarlas luego. La primer idea a tener presente es: las credenciales nunca debarían viajar en texto claro.

Ahora, ¿qué sucede si le aplicamos un hash del lado del cliente y las enviamos hasheadas? Estamos en la misma situación. Alguien puede capturarlas y, por más que no entienda realmente la contraseña, al servidor le alcanza ese hash extraño -que es siempre el mismo- para dar la autenticación como válida.

One time token es un token aleatorio que genera el servidor php, lo guarda en una variable de sesión y lo envía junto con el fomulario de login. Al recibir el formulario de login enviado por el usuario, elimina el token de la sesión. El token se utiliza una sola vez.

SHA1 es un algoritmo de hashing que se aplica del lado del cliente (javascript) al password ingresado por el usuario + el one time token.


Leer el resto del artículo »