AVISO: Nos hemos integrado con Facebook y Twitter. Ahora, podrás decir si te gusta o no uno de nuestros artículos con tu usuario de la red social. También podrás difundir los artículos que más te gusten a través de cualquier medio. Ayúdanos a que los artículos sean más interesantes dándonos tu opinión. Gracias.

viernes, 27 de noviembre de 2009

Ni espionaje, ni mafia organizada, solo vanidad.

Hoy ha aparecido en el periódico El País una noticia sobre la detención de un menor que ha sido detenido por ataques masivos a Webs (Leer noticia aquí). El incauto adolescente, tras presuntamente haber realizado un virus que infectaba PCs por todo el mundo, lanzó ataques de denegación de servicio contra algunas webs, entre otras la del foro elhacker.net, que quedó inactiva durante varios días.
Si hace unos cuantos días intentábamos reflexionar sobre la importancia de los ataques internos a los sistemas de información dentro de las empresas, no se debe descuidar también los externos. Si bien un DDOS (Denegación de servicio distribuida) es un poco más complicado de evitar que un DOS, existen técnicas y tecnología suficiente como para minimizar las consecuencias de este tipo de ataques.
Empresas que vendan a través de Internet, empresas de hosting, bancos, etc. son el tipo de empresas mas vulnerables a este tipo de ataques y donde un ataque de denegación de servicio mayor impacto causa.
Las mejores técnicas para evitarlos, entre otras, son:
  • Limitar las conexiones SYN desde un mismo equipo.
  • Implementar mecanismos para limitar el número de peticiones web para un equipo. En Apache tenemos mod_security, mod_evasive, mod_throttle.
  • Implementar limitación de congestión a través de firewalls. En linux, iptables dispone de las -m limit --limit xxx/second --limit-burst xxx para limitar la cantidad de conexiones recibidas por segundo.
Si bien todo lo comentado hasta ahora parece muy técnico, debemos preguntarnos lo siguiente:

¿Está nuestra empresa preparada para quedarse sin Internet durante 1 día? ¿Se conocen los riesgos que supone no disponer de la tienda online de la empresa durante unas cuantas horas? ¿Estamos preparados para afrontar este tipo de ataques?

Si la respuesta a alguna de las preguntas ha sido NO, espero que no pierda el sueño este fin de semana. Si bien, los DDOS no son tan habituales para PYMES, otros ataques similares, son más frecuentes de lo que se supone.

Como ejemplo, comentar que desde que IBERDAT dispone de servicios de cara a Internet, se reciben una media de 3 ataques diarios contra estos servicios. Si os estáis preguntando como podemos saber eso de los sistemas, solo debéis configurar correctamente los sistemas de monitorización y/o utilizar herramientas SIM o IDS con alertas.

Buen fin de semana a todos.

miércoles, 25 de noviembre de 2009

Identidad 2.0

La pasada semana estuve en una charla sobre identidad empresarial 2.0. y llevo un par de días con ganas de analizar la información que últimamente se está dando a nivel general sobre el tema. Para aquellos que no lo conozcan, la identidad 2.0 de las empresas se refiere a la utilización de Redes Sociales (tipo facebook, Tuenti, Linkedin, etc.) para generar imagen de empresa y utilizarla con fines publicitarios y fortalecimiento de marca. Se supone que es el futuro de la comunicación.
Al ser humano y a los publicistas en particular, les encanta eso de las denominaciones efectistas. Ya pasó con el marchamo de 2000 (cuando llegábamos al final del siglo XX) y ahora, unas cuantas modas después, empezamos con fuerza la utilización del término 2.0. (pronto vendrá el boom inmobiliario 2.0) Todo para seguir vendiendo cosas de la manera más efectiva. Pero con respecto a la Identidad corporativa, ¿estamos ante un nuevo paradigma de la comunicación empresarial?
Es cierto, que las redes sociales abren una nueva vía de comunicación con los usuarios o clientes de la marca. Es cierto, que en las empresas estamos evolucionando de "yo te cuento lo que quiero y me da igual tu opinión" a "soy una empresa que me preocupa tu opinión y estoy aquí para escucharte". De solo hablar a tener una conversación bidireccional.
Pero en esto de las conversaciones bidireccionales, tenemos que ser conscientes en todo momento de que riesgos y costes implican. Por ejemplo, no sirve de nada que tu empresa este representada en una red social tipo facebook o tuenti, si no vendes servicios al público en general. Tampoco sirve de mucho si no dispones de una web y un correo electrónico con tu propio dominio. Es decir, la identidad 2.0 no puede ser construida si todavía no tienes la identidad 0.1, la 0.5 y la 1.0. :-) En esto de la creación de una identidad empresarial no se pueden dar saltos de gigante ni empezar por el tejado. Nos lo tenemos que tomar con calma y ser constantes.
¿Pero cómo y cuando debemos afrontar el salto a la identidad 2.0?
Sólo debes seguir los siguientes pasos, y no dar el siguiente hasta tener afianzado el anterior:
  1. Disponer de correo con dominio propio y utilizarlo en las comunicaciones de la empresa con el exterior.
  2. Disponer de una página web asociada al dominio de la empresa, aunque esta sea básica, con la imagen corporativa. Incorporar apartado de noticias.
  3. Disponer de un blog con actualización semanal como mínimo.
  4. De acuerdo al mercado de actuación de la empresa:
    1. Si el mercado de tus productos y/o servicios es el público en general, (B2C) incorporación a redes sociales como nueva vía de comunicación.
    2. Si el mercado de tus productos y/o servicios son empresas (B2B) incorporación de Newsletter y extranet de clientes.
Si bien alguno de los pasos puede variar un poco o incluso, incluir alguno nuevo, son los pasos más naturales para ir forjándote una buena identidad en la red. Eso si, la incorporación a las redes sociales tampoco es la panacea. Hay que establecer una buena estrategia de acercamiento a la red.
Además de estos pasos también hay que tener en cuenta algunas recomendaciones cuando empezamos a elaborar un blog y/o estamos en una comunidad virtual:
  • Los contenidos deben ser apropiados a la imagen de empresa que se quiera dar.
  • Permitir los comentarios siempre que estos sean moderados y aprobados por la empresa.
  • Responder a los comentarios que los usuarios realicen.
  • No dedicar el espacio solo a publicidad. Los usuarios se quedarán en la comunidad si los contenidos son interesantes.
  • Constancia, constancia, constancia.... :-)
Cada nuevo servicio que ofrecemos (un blog, una comunidad, o una newsletter) requieren recursos de la empresa que dediquen su tiempo a mantenerlos. En el caso de los blogs y las comunidades, también se pueden contratar servicios de dinamizadores de comunidades para minimizar la dedicación de personal.

Con todo este popurri de cosas espero haber dejado un poco más claro que es eso de la Identidad 2.0 y que implica.

viernes, 20 de noviembre de 2009

Nos miramos al ombligo o al espejo?

Esta semana he tenido una crisis existencial sobre el tema que debería tocar. Cuando se tocan temas técnicos, volver a coger altura a veces cuesta. Pero no hay nada mejor para despegar que ir viendo las noticias de actualidad. Pues bien, esta semana, incluso ellas me han fallado :-) Pero bueno, no hay nada mejor que llegar al ecuador de la semana y ver el fin de semana cerca para poder tener nuevos aires.
Ya llevo un párrafo y todavía no he dicho que tema vamos a tocar. El título quizás no de muchas pistas, pero seguro que al final de la entrada veréis que tiene mucho sentido.
Desde hace mucho tiempo, se viene hablando que los principales ataques y problemas de seguridad en las empresas actuales no vienen desde el entorno externo a esta, sino desde el interior.
Hará cosa de 12 años, la empresa de uno amigo me llamaba para que les ayudara a implementar medidas de seguridad en sus ordenadores. La necesidad les había surgido después de haber contratado a una persona. Tras el periodo de prueba, tuvieron que despedirle por no cumplir las espectativas, y no contento con esto, la persona despedida les dejó un triste recuerdo: les borró todos los datos de las base de datos interna(clientes, pedidos, contabilidad, etc.). Por suerte, pudieron recuperar gran parte de la información gracias a las copias de seguridad.
Si bien esto puede parecer un hecho aislado, en la mayoría de las encuestas de seguridad realizadas a empresas, el hecho es que los ataques por personal interno son más frecuentes y de peores resultados:

"[UK's Department for Trade and Industry's annual Information Security Breaches report] showed that 48% of large companies blame their worst security incident on employees. By contrast, the 2001 edition of the survey showed that 75% of those questioned named external hackers and criminals as the biggest threat to security." From: http://news.bbc.co.uk/hi/english/sci/tech/newsid_1946000/1946368.stm

"The problem of internal hacking (unauthorized access by authorized users) consistently outweighs the problem of external hacking."[citing NCSA Firewall Policy Guide Version 1.01]" From: http://ksi.cpsc.ucalgary.ca/courses/547-96/johnp/547/present.html

La mayoría de las empresas son muy conscientes que al igual que protegen sus oficinas físicas de ataques externos, sus sistemas de información también deben ser protegidos: Antivirus, Firewalls, vpn, etc., son elementos comunes implementados en las empresas. Pero, ¿qué hacemos para mitigar el riesgo de ataques internos?
Los elementos a tener en cuenta para evitar gran parte de los ataques internos son muy sencillos de implementar, bueno, si se tienen las herramientas adecuadas:
  • Limitar el acceso de los empleados a la información.
  • Implementar una segmentación de red adecuada.
  • Implementar mecanismos de cifrado de información.
  • Crear e implantar políticas de segurdad para monitorización y gestión de alarmas.
  • Implantar la firma de claúsulas de confidencialidad y secreto industrial.
La limitación del acceso a la información es una de las grandes carencias en las empresas. Normalmente se tiende a dejar acceso a toda la información (sobre todo en las pequeñas empresas), pero esto a la larga es un error. La regla es que los empleados puedan ver aquella información que realmente deban ver, ni más ni menos. La tecnología actual permite implementar estas limitaciones de una manera relativamente sencilla. Lo mismo sucede con el acceso a la red interna de la empresa. La mayoría de las veces la dirección no es consciente de lo que un empleado puede llegar a ver a nada que tenga un poco de interés.

De ahí viene la reflexión que planteaba en el título:

Tendemos a mirarnos en el espejo implantando solo medidas externas de seguridad, o somos capaces de miranos al ombligo y darnos cuenta que internamente también debemos aplicar medidas de seguridad?

Con esto nos despedimos por esta semana.

sábado, 14 de noviembre de 2009

Servicios de Windows en Perl 5.10

Esta semana nos acercaremos al mundo del Perl. Desde que aprendí a programar en este lenguame me ha fascinado tremendamente. Hay mucha gente que se ha ido mudando a Python, pero yo todavía sigo fiel a Perl. Es un lenguaje muy fácil de aprender y con grandes funcionalidades que se pueden aprovechar. Aunque hay gente que lo ve solo como un lenguaje para scripting de sistemas (y en eso es indiscutible), aquellos que realmente le saben sacar partido puede desarrollar aplicaciones enteras con entorno de ventanas (incluido en plataforma windows).
Pero bueno, vayamos al grano. Llevo unas semanas dándole vueltas a la cabeza para poder migrar un script de monitorización de las IP pública de equipos para entornos windows. Ya tengo desarrollado el script para entornos linux/unix. Pero cuando me lo he planteado migrar a Windows, quería que fuese algo, como diríamos, un poco más elegante. Para ello, decidí que la mejor manera de que estuviese siempre activo sería hacíendolo servicio de windows.
Manos a la obra, me puse a buscar documentación al respecto y encontré el módulo Win32::Service que sirve para manejar servicios de windows (aunque esto no es lo que necesitaba inicialmente) y el módulo Win32::Daemon. Si bien en CPAN hay documentación al respecto, cuando empiezas a hacerte el primer esqueleto, te das cuenta que tienes que ir por pasos.
Lo primero de todo es ver como se instala y desinstala un servicio. Esta parte fue la sencilla. Para aquellos que no quieran buscar, les copio las funciones:

sub GetServiceConfig
{
my $ServicePath = $^X;
my $ScriptPath = join( "", Win32::GetFullPathName( $0 ) );
my %Hash = (
machine => '',
name => 'Nombre',
display => 'Lo que ves en el mmc',
path => $ScriptPath,
user => '',
pwd=> '',
description => 'Descripcion de lo que hace el servicio',
parameters => ''
);
return( \%Hash );
}
sub GetError
{
return( Win32::FormatMessage( Win32::Daemon::GetLastError() ) );
}

sub install_service (){

my $ServiceConfig = GetServiceConfig();
if( Win32::Daemon::CreateService( $ServiceConfig ) )
{
print "El servicio $ServiceConfig->{display} fue instalado con exito.\n";
}
else
{
print "Fallo al instalar el servicio $ServiceConfig->{display}.\nError: " . GetError() . "\n";
}
}
sub uninstall_service (){

my $ServiceConfig = GetServiceConfig();

if( Win32::Daemon::DeleteService( $ServiceConfig->{name} ) )
{
print "El servicio $ServiceConfig->{display} fue desinstalado con exito.\n";
}
else
{
print "Fallo al desinstalar el servicio $ServiceConfig->{display}.\nError: " . GetError() . "\n";
}
}

Si estas funciones se utilizan acompañadas de la utilización getoptions, permitirá instalar y desinstalar el servicio de manera muy sencilla.

use Getopt::Long qw(:config pass_through);
GetOptions('help|?' => \$help, 'install|i' => \$install, 'uninstall|u' => \$uninstall) or print_usage();
GetOptions('help|?' => \$help, 'install|i' => \$install, 'uninstall|u' => \$uninstall) or print_usage();
print_usage() if $help;
install_service() if $install;
uninstall_service() if $uninstall;

así, cuando llamemos al script con -i, lo instalará como servicio, y cuando lo llamemos con -u lo desinstalará. :-) Hasta aquí, como he dicho, es la parte más sencilla. Esto no lleva más de 10 minutos.
Ahora viene la parte complicada. Cuando vemos ejemplos del módulo en http://www.roth.net/perl/Daemon/, la cosa parece que va a ir de lo más sencillo, pero al implementarlo te das cuenta que algo empieza a no ir bien. Decir, antes de seguir, que lo que cuento ahora vale para su desarrollo en windows con ActivePerl 5.10. Esto es quizás lo que más quebraderos de cabeza ha dado (la versión de perl). Primero, hay que conseguir la versión adecuada del módulo Daemon (se obtiene aquí), después instalarla manualmente en tu distribución de perl y después empezar a leerte los ejemplos de nuevo. Para el desarrollo del servicio hay tres maneras de hacerlo, de acuerdo al autor del módulo. Típico bucle hasta que se detecta una señal de stop, utilización de una función que atiende a los eventos que puede tener el servicio (stop, start, pendind start, ...) o múltiples funciones que se ejecutan dependiendo del evento que se produzca (el ejemplo 5 de la página del módulo). Como programador eficiente, y de acuerdo también a las recomendaciones del autor, opté por este último modo. Algo sencillo y elegante. Cuando el servicio arranque, habrá un evento START y se ejecutará la función que yo asocie a ese evento, y así para el resto. Perfecto, no hay más que hablar, vamos allá.
Tras copiar y pegar el ejemplo, añadido a las otras opciones generadas (bendito Copy&Paste), me puse a probarlo. Instalé el script como un servicio y le di al play en el mmc. Vi como el servicio se levantaba, casí esbocé una sonrisa por lo sencillo que había sido, pero al cabo de 10 segundos, al refrescar el mmc, vi que el servicio estaba parado. Es en estos momentos es cuando se pone a prueba la paciencia de todo desarrollador ;-) La pregunta que se pasa por la cabeza es: ¿Pero por qué se ha parado el ~#€@#€@# servicio ?
Añadí algunos logs a mi script. Coloco aquí el esqueleto:

sub Callback_Running
{
my( $Event, $Context ) = @_;

# Note that here you want to check that the state
# is indeed SERVICE_RUNNING. Even though the Running
# callback is called it could have done so before
# calling the "Start" callback.
my $state = Win32::Daemon::State();
if( SERVICE_RUNNING == $state )
{
escribelog ("Estado Running del servicio.");
}
}

sub Callback_Start
{
my( $Event, $Context ) = @_;
$Context->{last_state} = SERVICE_RUNNING;
# Initialization code
# ...do whatever you need to do to start...
escribelog ("Estado Start del servicio. ");


Win32::Daemon::State( SERVICE_RUNNING );
}

sub Callback_Pause
{
my( $Event, $Context ) = @_;
escribelog ("Estado Pause del servicio.");
$Context->{last_state} = SERVICE_PAUSED;
Win32::Daemon::State( SERVICE_PAUSED );
}

sub Callback_Continue
{
my( $Event, $Context ) = @_;
escribelog ("Estado Continue del servicio.");
$Context->{last_state} = SERVICE_RUNNING;
Win32::Daemon::State( SERVICE_RUNNING );
}

sub Callback_Stop
{
my( $Event, $Context ) = @_;
$Context->{last_state} = SERVICE_STOPPED;
Win32::Daemon::State( SERVICE_STOPPED );
escribelog ("Estado Stop del servicio.");
Win32::Daemon::StopService();
}

Win32::Daemon::RegisterCallbacks( {
start => \&Callback_Start,
running => \&Callback_Running,
stop => \&Callback_Stop,
pause => \&Callback_Pause,
continue => \&Callback_Continue,
} );

%Context = (
last_state => SERVICE_STOPPED,
start_time => time(),
);

escribelog("Antes Start Service");
Win32::Daemon::StartService( \%Context, 15000 );

La función escribelog solo deja en un fichero el texto que se escribe. Bueno, tras analizar las trazas que dejaba en el log, veía como el servicio pasaba por "Antes Start Service", "Estado Start del servicio" y después nada. Mirando los procesos que se generaban, cuando arrancas el servicio, se arrancan dos procesos y se ve como al arrancar se inician y al cabo de 15 segundos uno de los procesos muere.
Pues nada, ya se que pasos da. Se arranca, pasa por la rutina de star y después se detiene, pero sin pasar por la rutina de stop. Empecé a investigar por Internet y empecé a sentirme un poco solo al ver que a nadie le pasaba. Empecé a plantearme si después de tanto tiempo me estoy oxidando con la programación. Lo primero que encontré es que en las nuevas versiones del módulo, se había cambiado el evento running por el evento timer. Bueno, quizás por eso no se ejecutaba. Volví a probar. "Antes Start Service", "Estado Start del Servicio", "Estado running del servicio" y se vuelve a parar. Pues no, eso no era, pero al menos hemos avanzado. Por lo menos veo que se ejecuta la función en running. Pero ¿qué le pasa?.
En estos momentos, cuando ya de los 5 minutos para hacer el script pasas a los ratos libres de 2 días, el script pasa a ser algo personal :-). Es entonces cuando al igual que las integrales de idea feliz, hay veces que en el cerebro de un programador se enciende una lucecita que alumbra el camino. Bien, pues tras no se cuantas pruebas, instalaciones de servicio, desinstalaciones del mismo, conseguí que mi servicio corriese estable en windows. Ese momento es como quien tiene un niño y ve que acaba de nacer y respira. Pero claro, los que hayáis llegado hasta aquí, os estaréis preguntado, pero ¿cómo lo has hecho funcionar?. Bien, para aquellos que realmente estéis en el mismo problema que he estado yo, aquí va la solución. Solo copio la función running, que es donde estaba el problema:

Primero acordaros del RegisterCallBacks:

Win32::Daemon::RegisterCallbacks( {
start => \&Callback_Start,
timer => \&Callback_Running,
stop => \&Callback_Stop,
pause => \&Callback_Pause,
continue => \&Callback_Continue,
} );

y después de modificar la función callback_running como sigue:
sub Callback_Running
{
my( $Event, $Context ) = @_;

# Note that here you want to check that the state
# is indeed SERVICE_RUNNING. Even though the Running
# callback is called it could have done so before
# calling the "Start" callback.
my $state = Win32::Daemon::State();
if( SERVICE_RUNNING == $state )
{
escribelog ("Estado Running del servicio.");

}
$state = Win32::Daemon::State();
}
Como veis, al final de la función se realiza una llamada a la función State. del módulo No he encontrado una razón lógica para esto, pero parece ser que si no llamas a esta función, el estado del proceso cambia al estado 1 (pendiente de parada) y después al estado 0 (de parado) aunque se sigue ejecutando en el evento timer.
Bueno, y ya está, a partir de aquí se abre todo un mundo de posibilidades con este esqueleto de servicio windows. Para aquellos un poco más "perfeccionistas", comentaros que el script también se puede pasar a un archivo exe a través de la herramienta "pp" dejando así la funcionalidad perfectamente encapsulada para poder ser distribuida a todas las máquinas windows que desees.

Espero que sea de utilidad para alguien más.

miércoles, 4 de noviembre de 2009

La ficción se vuelve realidad.

Muchas veces hemos visto películas de ficción en las que aparecen adelantos tecnológicos que para la época de la película son pura ficción. Pero de vez en cuando, algunos de ellos acaban siendo de uso cotidiano en la realidad. Los intercomunidadores móviles de Star Trek, los robots que andan con piernas aparecen en la Guerra de las galaxias, etc. Ahora, le llega el turno a un elemento visto en las películas de espionaje de los últimos tiempos, donde el protagonista ayudado de un pequeño aparato, lo conecta a un equipo y le descarga toda la información.

Según investigadores de "MVR InfoSecurity" (Fuente) debido a un fallo en los drivers de las memorias USB estos dispositivos podrían preguntar al ordenador por la información que contienen y descargársela completamente. La ficción ya está aquí para quedarse.

Pero desde el punto de vista empresarial, ¿cómo nos afecta?

La analogía vendría a que alguien sea capaz de tener una llave que abre casi todas las puertas del mundo. Tendremos que empezar a utilizar mecanismos que mitiguen el riesgo de seguridad que supone este nuevo ataque. Deshabilitar la conexión de dispositivos USB en nuestros equipos, utilización de sistemas de control de acceso físico, videovigilancia, etc., pueden hacer que mitiguemos suficientemente los riesgos, por lo menos, hasta que los SO nos permitan disponer de la funcionalidad con el mínimo riesgo posible.

Esperemos, que lo que parecía una simple excentricidad como es el dedo-usb, no se acabe convirtiendo en el accesorio indispensable para los espías industriales del futuro.