news: Metasploit fue comprado por Rapid7
Leyendo el blog de Metasploit me encontré con que el excelente framework de exploits usado para penetration-tests fue adquirido por una compañía llamada Rapid7. Esta compañía (por suerte) se dedica a la seguridad, proveyendo su servicio a organizaciones para optimizar la seguridad de la red, seguridad de aplicaciones Web y seguridad en base de datos.

La pregunta que siempre surge cuando un software libre es comprado por una compañía es "qué va a pasar con la licencia?"...
Para dejarnos tranquilos (?!) el creador de Metasploit nos asegura desde el blog que la adquisición solo traerá buenas consecuencias, que Rapid7 no piensa cambiar la naturaleza open-source del proyecto, ni tampoco su licencia.

Entre las buenas noticias podemos decir que el creador (HD Moore) y uno de los desarrolladores (Egypt) ahora podrán dedicarse de tiempo completo al proyecto, estando Moore como Arquitecto en Jefe y Egypt como core developer. Además estarían contratando a un desarrollador de exploits, un diseñador de interfaces y un ingeniero QA.
Todo esto quiere decir que Metasploit se estará actualizando más seguido, agregando exploits, reparando bugs, y agregando nuevas funciones mucho más rápido que antes.

Esperemos que todo sea como dicen y que la compra no cague un excelente framework libre, estaremos viendo el progreso pronto.
KOOBFACE, el worm de Facebook
Hoy les traigo el review de una pieza magistral de malware: KOOBFACE. Esta singular software viene dando vueltas hace meses por distintas redes sociales de mucha importancia, siendo la más popular Facebook, gracias a la cual se ganó el nombre (koobface es un anagrama de facebook).

Actualmente este worm se dispersa, además de Facebook, por MySpace, hi5, Bebo, Twitter y Friendster, entre otros. Como suele suceder con la mayoría del malware importante, éste se dispersa por máquinas Windows, así que los *nixeros estamos a salvo =P

A lo largo del review voy a seguir la excelente explicación hecha por la gente de Trend Micro, llamada The Real Face of KOOBFACE.

KOOBFACE está formado por varios componentes, cada uno con una funcionalidad distinta. Estos componentes están dispersos en varios archivos que forman una bootnet (ver la imagen - cortesía de Trend Micro). La cantidad de componentes que forman esta botnet es increíble, haciendo del malware una pieza digna de investigar.



La forma de propagación no es nada del otro mundo. Uno recibe un mensaje en Facebook o alguna otra red social con un comentario llamativo que referencia un link a un "video" en "youtube". Digo "video", porque en realidad cuando seguimos el link llegamos a una página (llamada YuoTube...) que nos dice que nuestra versión de Flash está desactualizada y que para poder ver el video necesitamos instalar un ejecutable... ehhh alguien en su sano juicio no le daría instalar... ehhhh... mejor sigo con la explicación. Para el que tenga poca imaginación, aclaro que el ejecutable no es otra cosa que un downloader, el cual se encarga de descargarnos los componentes del KOOBFACE (si le dieron click están listos...).

La gente de Trend Micro dividió los componentes en las siguientes categorías:
- KOOBFACE downloader
- Componentes de propagación por redes sociales
- Componente Servidor Web
- Propagandeador e instalador de antivirus falso
- Rompedor de CAPTCHA
- Ladrón de datos
- Hijackers de buscadores Web
- Cambiador de DNS
como ven, son varias categorías, osea, el malware es bien completito, trae un poco de todo.
Cada uno de estos componentes es interesante, así que describo brevemente cada uno de ellos.

El downloader se encarga de determinar en qué redes sociales el usuario es miembro. Esto lo hace revisando las cookies del navegador. Una vez que sabe en qué redes el usuario tiene cuentas, se conecta al Command Y Control (C&C) y descarga los componentes que el C&C le indique.
KOOBFACE tiene la habilidad de armarse a medida para cada usuario, dependiendo de en qué redes sociales el usuario es miembro. Por ejemplo, si el usuario es miembro de Facebook y Twitter, el C&C le indica al downloader que se descargue las componentes de propagación para estas dos redes sociales.
Además de las componentes de propagación, el C&C le indica qué otras cosas le interesaría que la máquina del usuario haga, descargando alguno de los otros componentes.

Los componentes de propagación son los encargados de enviar los mensajes en las redes sociales, los cuales harán que otros usuarios se infecten si instalan el downloader. Estos componentes básicamente contactan el C&C, obtienen los mensajes y las URLs a postear, postean el mensaje y URLs en la página de cada red social, y también envían mensajes a la bandeja de entrada de otros usuarios.
Los componentes de propagación comprenden varios binarios, los cuales fueron construidos especialmente para manejar un site de red social en especial.
El gran enganche en la propagación está en que uno suele confiar en los links que envía un amigo y no piensa que puede tratarse de algo malicioso...

El componente Web server hace de nuestra máquina un lindo punto de distribución de malware. Una vez que el web server se instala en nuestra máquina, éste se registra en el C&C. El C&C le indica a nuestro nuevo, flamante e indeseado web server que actúe como proxy o como un redireccionador para distribuir otros componentes de KOOBFACE.
Este componente sirve las páginas falsas de YouTube, las cuales terminan en el downloader.

El propagandeador e instalador de antivirus falso se encarga de convencer al usuario de que su máquina está infectada lanzando ventanas de advertencia con links a antivirus falsos.

El rompedor de CAPTCHA usa una idea interesante, en vez de hacer el trabajo molesto de desenmarañar los CAPTCHAs para poder publicar cosas automáticamente, hacer que usuarios infectados resuelvan los CAPTCHA y usar el resultado obtenido!
Para hacer esto, el malware descarga la imagen con el CAPTCHA de alguno servidor C&C y amenaza al usuario a resolverlo con un mensaje inductor de pánico, el cual tiene un contador regresivo que reza "tiempo antes de apagar"... si el usuario no escribe lo que dice en el CAPTCHA KOOBFACE no apaga la máquina, sino que vuelve a reiniciar el contador. El contador está impuesto porque los CAPTCHAs tienen un tiemout, si no se resuelven en un dado tiempo, se genera un nuevo CAPTCHA.

Entrando en los componentes más riesgosos, nos encontramos con el ladrón de datos. El ladrón de datos roba IDs de Windows, perfiles de Internet, credenciales de e-mail, ftp y mensajeros instantáneos (GAIM, ICQ, Trillian, etc). Los datos robados son encriptados y enviados al C&C.

Los Hijackers de buscadores Web interceptan las búsquedas en Google, Yahoo, etc y las redirigen a dudosos sitios propios. Los sitios a donde vamos a parar nos muestran los resultados listando compañías que pagan a los administradores de KOOBFACE y no son sitios con buena reputación...

El cambiador de DNS modifica los servidores DNS utilizados por la máquina del usuario para que apunten a servidores DNS administrados por gente de KOOBFACE. Estos servidores interceptan los sitios que el usuario visita y envían en su lugar paginas con malware o phishing. Estos servidores DNS también bloquean el acceso a páginas de antivirus o de seguridad!


Como pueden observar, KOOBFACE puede hacer mucho y lo hace muy inteligentemente.
Para terminar, los de Trend Micro publicaron además una lista de las 8 cosas que seguramente no conoces acerca de KOOBFACE, es interesante como para enterarse rápidamente a qué nos enfrentamos.


Conclusiones

Como se habrán dado cuenta, KOOBFACE es una red compleja muy bien pensada y diseñada que abarca varias ramas de malwares y se propaga como chisme. Viene dando vueltas desde diciembre de 2008 (tal vez antes) y cada semana leo alguna noticia relacionada al tema, por lo que está muy activa actualmente.
La gran conclusión de todo esto es, NO INSTALES NADA QUE NO ESTES SEGURO!, no den click a lo pavo en todo lo que se quiera instalar. No le hagan caso a los alertas de antivirus falsos! No sigan cualquier link! Hotmail no se cierra! (uhh, eso pertenece a otro post...)
curiosidades: el origen del // en las URLs
Hoy me encontré con una noticia más que curiosa. Hace unos días le preguntaron a Sir Tim Berners-Lee, creador de la worl wide web (www), cuál era la razón de ser de las dos barras diagonales (//) que se sitúa en las URLs... y la respuesta fue: "no existe razón".

Para el que no entienda de qué estoy hablando, seguramente se dará una idea con el clásico ejemplo http://www.ejemplo.com. Como ven, las // aparecen en cada URL actual, no sólo para http, sino tambien para ftp://, smb://, etc, etc.

El mismo Tim pensando en retrospectiva no tiene mucha idea de porqué eligió poner dos barras en lugar de por ejemplo una, o ninguna, dado que no son necesarias.

Tim se disculpa por el sacrificio provocado por la necesidad de escribir dos caracteres inútiles y por toda la tinta malgastada en impresiones debido a ellas.

Este señor actualmente es el director del consorcio Worl Wide Web (W3C), que supervisa el desarrollo de la web, y es considerado el arquitecto de la www. Para el que quiera leer un poco más sobre el, siempre pueden encontrar su entrada en wiki, o bien en la misma página de la W3C.

Estas perdonado Tim! lo que inventaste es una genialidad, un componente vital en las comunicaciones, sin la www no podría aprender todo lo que aprendo, ni enterarme de todo lo que me entero.
Deshabilitar ejecución en directorios por política (Windows)

Ya se que van a pensar, desaparezco un buen tiempo y encima aparezco con otro post sobre aplicaciones MS... a mi también me da bastante cosa, pero el trabajo me lleva a esto, así que, a falta de tiempo para crear artículos sobre otros temas, comparto algo que me parece interesante para todos los que trabajan en seguridad.

En el entorno Windows XP (y Windows en general), deshabilitar la ejecución de programas se puede realizar utilizando políticas de grupo. Estas políticas se pueden configurar por máquina, o bien a través de Active Directory para aplicarlas a varias máquinas o usuarios. A través de estas políticas, como mostraré en un ejemplo, podemos desactivar la ejecución sobre particiones enteras, o también desactivar selectivamente *.exe, *.bat, etc.


Crear reglas basadas en path

Para aplicar la política en una dada máquina, se debe abrir el editor de políticas (“Start” -> “Run…” -> gpedit.msc). En el editor de políticas nos dirigimos a “Computer Configuration” -> “Windows Settings” -> “Security Settings” -> “Software Restriction Policies”. Si el directorio Software Restriction Policies se encuentra vacío, hacemos click derecho sobre este y elegimos crear un nuevo set de políticas. Una vez que tenemos la carpeta “Software Restriction Policies” poblada, nos dirigimos a “Additional Rules” como se muestra en la imagen.

Dentro de “Additional Rules” hacemos click derecho y elegimos “New Path Rule”, donde podremos ingresar el path a la carpeta donde desdeamos deshabilitar la ejecución. En la figura se muestra cómo deshabilitar la ejecución en el disco D:\, es decir, los usuarios no podrán ejecutar ninguna aplicación que se encuentre en este disco.

También es posible configurar directorios donde deseemos que esté permitida la ejecución. Esto lo hacemos de la misma forma que el caso anterior, pero en lugar de elegir Disallowed en el “Security Level”, elegimos “Unrestricted”.Eliminar una regla es tan simple como dar clic derecho sobre la regla y elegir Delete.

Los paths pueden contener expresiones regulares para hacer la restricción más fina. Si por ejemplo queremos restringir la ejecución de .exe pero no la de otros tipos de ejecutables (como los .bat o .com) en el D:\, podemos colocar la sentencia D:\*.exe en lugar de solo D:\


Otras formas de restringir ejecución

Además de deshabilitar ejecución por path, podemos deshabilitar ejecución por:- certificado: dependiendo de quién firme la aplicación, habilitamos la ejecución de la misma o no. Las aplicaciones pueden venir firmadas digitalmente, y agregando el certificado a nuestra lista podemos restringir o habilitar la ejecución de estos programas.

- hash: agregamos el hash de una aplicación a la lista y configuramos si esa aplicación puede ejecutarse o no.
- internet zone: podemos configurar qué sitios de internet tienen acceso a instalar aplicaciones en nuestra máquina.


Valores por defecto

Windows por defecto mantiene la política de permitir acceso irrestricto. La política por defecto se configura en “Software Restriction Policies” -> “Security Levels”. Los valores que se encuentran allí son “Unrestricted” y “Disallowed”. Para cambiar entre estos valores, simplemente damos clic derecho en uno de ellos y elegimos “Set as Default”.

NOTA: es importante destacar que si configuramos que el sistema por defecto no permita la ejecución de programas, deberemos configurar en Additional Rules todas los paths desde donde esté permitido ejecutar (por ejemplo, Program Files). En caso contrario, no podremos ejecutar ninguna aplicación.


Aplicando las políticas

Para aplicar las políticas recién configuradas, desde la línea de comandos ejecutamos “gpupdate /force”, o bien nos deslogueamos y volvemos a loguear.

Buena Referencia

Software Restriction Policies
Tunear logs de SQL Server
Hace un par de semanas vengo trabajando en crear logs de SQL Server que valgan la pena para así poder realizar trabajos de revisión y auditoría de lo que sucede en los servidores de base de datos de la empresa. El tema es que, aunque a uno le parezca totalmente simple activar los logs de un sistema tan utilizado y (supuestamente) fácil de administrar, esto no es así.
Por defecto SQL Server no loguea casi nada útil, solamente cuando ocurre un error grave o cuando se hace backup de la base de datos. Si piensan que su motor de base de datos está (como debería) logueando información para poder controlar las acciones... piensen de nuevo!, revisen los logs y diganme si encuentran algo en los logs que les sirva!

Por supuesto que el DBMS en cuestión cuenta con sistema de logueo de eventos, pero hay que activarlo a mano y conocer un poco sobre el funcionamiento de algunos store procedures creados para esto. Una de las primeras cosas que uno se encuentra cuando busca logs de SQL Server, es el modo de auditoría C2, pero existen otra forma más efectiva de loguear, la cual es usando los traces de SQL Server. A continuación explico un poco de estas dos modalidades de logueo.

Cabe destacar que activar sistemas de logueo siempre generan una sobrecarga en el sistema. Dependiendo lo que deseemos loguear, la sobrecarga será mayor o menor, pero es un punto a tener en cuenta.


Modo de auditoría C2

Este modo fue diseñado para poder cumplir con la clase C2 del Criterio de evaluación de confianza de un sistema computacional creado por el Department of Defence yankee (DoD). Cuando se activa esta modalidad de logueo, todos los eventos y todas las columnas pertenecientes a cada evento se loguearan. Como se podrán imaginar, este nivel de logging es extremo y poco útil para la mayoría de los sistemas. Revisar estos logs es para un monje Shaolin drogado, porque por más filtros que pongamos, seguiremos teniendo miles de entradas repetitivas e inútiles.
Para que se den una idea del nivel de logueo C2, lo probamos en una base de datos con relativo poco movimiento de datos y el log creció a más de 1GB en un par de horas! 1GB de texto! se imaginan lo que es??? pues mucho!

Si luego de toda esa introducción al modo audit C2 todavía tienen ganas de probarlo, lo pueden hacer ejecutando las siguientes sentencias T-SQL:
SP_CONFIGURE 'show advanced options', 1;
GO
RECONFIGURE
GO
SP_CONFIGURE 'c2 audit mode', 1;
GO
RECONFIGURE
GO
SP_CONFIGURE 'show advanced options', 1;
GO

Luego de ejecutar las sentencias anteriores, deberán reiniciar el motor de base de datos, así que haganlo en algún momento donde no tengan mucho movimiento de datos.
Para revisar que el modo quedó activado, pueden ejecutar la siguiente sentencia:
SELECT value FROM sys.configurations
WHERE name = 'c2 audit mode';
GO
Los logs se almacenan en el directorio \MSSQL\Data (osea, donde está instalado el SQL Server) y son archivos .trc de 200MB cada uno. Los archivos se van generando a medida que se van llenando, osea, se arranca con un archivo, cuando llega a 200MB, se cierra y se abre uno nuevo.
Recuerden lo que les dije al principio, estos logs son monstruosos, así que si tienen poco espacio en el disco, vigilenlos! Sino les comerá el disco y al almacenarse en la misma partición que la base de datos, puede que les genere un Denial of Service si el disco se llena!


SQL Traces

Para no volvernos locos con los logs generados por el modo C2, podemos customizar lo que deseamos loguear utilizando trazas (traces), las cuales creamos con una serie de store procedures que trae SQL Server. La explicación de cada uno de estos store procedures la pueden encontrar en la página oficial de MS, dependiendo la versión de SQL Server que tengan, puede variar un poco, pero hasta donde vi es bastante similar en todas las versiones. Yo voy a explicar el sistema para SQL Server 2005, pero no debería variar mucho para SQL Server 2008.

SQL Server basa su funcionamiento en eventos y por ello, los logs se arman en base a los eventos que queremos loguear. Por cada evento tenemos una serie de atributos que podemos loguear. Muchos atributos son comunes para todas los eventos, pero algunos son específicos para cierta clase de eventos. Nuestro trabajo trata sobre ver que eventos queremos loguear y qué atributo de cada evento deseamos... no es un trabajo fácil, porque existen como 200 eventos a loguear, y contamos con 64 atributos posibles, encontrar lo que realmente necesitamos llevará un tiempo de pruebas.

Para comenzar les puedo dar el formato de como crear una traza básica:
-- declaramos las variables necesarias
DECLARE @traceID int
DECLARE @maxFileSize bigint
DECLARE @traceFile nvarchar(245)
DECLARE @on bit
DECLARE @date nvarchar(25)

-- seteamos el tamanio para los archivos donde se almacenan los logs
set @maxfilesize = 200
-- seteamos la localización de los logs
set @date = convert(nvarchar(25), GETDATE())
set @date = REPLACE(@date,':','.')
set @date = REPLACE(@date,' ','_')
set @traceFile = N'D:\SQL_Traces\trace_'+@date+'.trc'


-- creamos la traza, obtienendo un id que se almacenara en @traceID. Indicamos que cuando se alcance el maximo del archivo, se cree otro archivo nuevo.
EXEC sp_trace_create @traceID OUTPUT, 2, @traceFile, @maxFileSize, NULL

-- decimos que queremos activar el evento
set @on = 1

-- activamos el evento 109 (auditar cuando se agrega un login a la base de datos) y queremos guardar las columnas 1 (el texto generado por el evento) y 11 (el nombre de login).
EXEC sp_trace_setevent @traceID, 109, 1, @on
EXEC sp_trace_setevent @traceID, 109, 11, @on

-- activamos el evento 110 (agregar un miembro a un rol) con las mismas columnas que antes.
EXEC sp_trace_setevent @traceID, 110, 1, @on
EXEC sp_trace_setevent @traceID, 110, 11, @on

-- iniciamos la traza
EXEC sp_trace_setstatus @traceID, 1
GO
Traté de comentar todo lo relevante en el código, pero es interesante destacar el significado de algunas líneas. Por un lado al principio decimos el tamaño máximo que debe alcanzar cada archivo de log (se utiliza el formato propietario .trc). Luego creamos un nombre para estos archivos. Como no deseamos pisar trazas anteriores, le agregué la fecha al nombre de archivo.
Una vez seteadas las variables, creamos la traza con el store procedure sp_trace_create, al cual debemos pasarle una variable donde nos retornará el id de la traza creada. Con el siguiente valor le podemos especificar opciones, yo coloqué 2 para indicar que una vez que se llena el archivo de log (osea, alcanzamos los 200MB), que se cree un nuevo archivo... es decir, vamos creando archivos de 200MB. Como se imaginarán, el siguiente parámetro especifica el nombre del archivo donde guardar las trazas, y el que se encuentra al lado es el tamaño de los archivos. Por último, como no nos interesan los valores stoptime y filecount, colocamos un NULL.
Ahora pasamos a setear los eventos que queremos loguear. Primero utilizamos una variable del tipo bit que nos servirá para decir que queremos poner en on el evento... esa variable la utilizaremos en el store procedure sp_trace_setevent. Las siguientes líneas simplemente activan los eventos agregar un login y agregar usuario a un rol utilizando la citada sp_trace_setevent. Para ambos casos logueamos las columnas 1 y 11, las cuales nos dicen el texto del evento (osea, lo que pasó) y el nombre del usuario de login que causó el evento. La lista completa de eventos que pueden loguear y las columnas que se pueden loguear, vean el mismo manual de sp_trace_setevent... armense de paciencia porque son muchos...
Por último, iniciamos la traza utilizando el store procedure sp_trace_setstatus, donde le damos el id de la traza que queremos activar, y le pasamos un 1 para indicar que iniciamos, si pusiéramos un 0 estaríamos deteniendo y con un 2 la eliminamos del sistema.

Muy bien, con todo lo anterior ya tenemos la traza en ejecución y logueando eventos. Qué pasa si queremos detenerla? utilizamos el citado sp_trace_setstatus. Como habrán visto, sp_trace_setstatus necesita dos parámetros, el id de la traza y el indicador de qué hacer con la traza (comenzar, detener, eliminar). Pues cómo obtenemos el id de la traza que deseamos? acuerdense que antes utilizábamos la variable @traceID, pero esa variable la perdemos una vez q termina la ejecución de las sentencias anteriores. No desesperen, hay una forma de hacer esto.
Dado que pueden haber varias trazas en ejecución al mismo tiempo, primero tenemos que buscar la que deseamos. Para esto podemos usar la sentencia:
select * from fn_trace_getinfo(0)
Esta sentencia nos devuelve todos los ids de las trazas existentes. Busquen la que desean detener mirando los atributos de cada una (pueden buscar el nombre del archivo donde se guardan los logs por ejemplo). Una vez que obtenemos el id de la traza simplemente ejecutamos:
EXEC sp_trace_setstatus elID, 0
si queremos solamente detenerla, o bien:
EXEC sp_trace_setstatus elID, 0
EXEC sp_trace_setstatus elID, 2
si queremos detenerla y eliminarla del sistema.

Lo último que me queda por decir acerca de las trazas es que estas se detienen cada vez que reiniciamos el motor de base de datos y no se arrancan solas. Si queremos que nuestra traza se inicie cada vez que iniciamos el motor de base de datos, podemos meter todo el código anterior en un store procedure de la base de datos master:
USE [MASTER]
GO

CREATE PROCEDURE usp_trace
AS

... TODO EL CODIGO ANTERIOR ...
Una vez creado el store procedure, debemos configurarlo para que se ejecute al inicio. Para esto, necesitamos oooootro store procedure llamado sp_procoption. Por suerte esto SP es muy simple, debemos pasarle el nombre del SP que queremos ejecutar, un valor indicando lo que queremos hacer (en nuestro caso que se ejecute al inicio del sistema) y el valor de la opción (true para activarlo). Asumiento el nombre del store procedure que utilice en el ejemplo (usp_trace), deberíamos ejecutar lo siguiente:
EXEC sp_procoption ups_trace, StartUp, True


Cómo leemos los archivos .trc?

Para variar, nuestros amigos de MS nos entregan un formato propietario el cual no se puede abrir con otra cosa que no sea el SQL Profiler, osea, un programa provisto por ellos...
El SQL Profiler es bastante completo y permite realizar distintos niveles de filtrado para poder visualizar la información que nos interesa, pero igualmente preferiría un formato de archivo visible con cualquier editor, o desde una base de datos.

Cabe destacar que es posible volcar los valores del log a una base de datos para que sean más fáciles de administrar, aunque ahora no recuerdo exactamente en donde estaba explicado, si lo encuentro en estos días, actualizo el artículo =)

También es interesante saber que las trazas se pueden crear desde el SQL Profiler, desde una GUI bien bonita... aunque siempre es mejor hacerlo a mano y estar seguro de qué se está activando. Además el SQL Profiler incurre en un overhead extra en el sistema para ejecutar las trazas...


Referencias

El gran artículo que me ayudó muchísimo a entender todo este sistema de log de eventos fue Get Compliant with SQL Server 2005 Audit, muchas gracias Larry Clark por tan buen artículo.
Por supuesto que el resto lo tuve que hacer solo mirando los manuales de MS que pueden encontrar en SQL Server Profiler Stored Procedures (Transact-SQL).
Lo más leido en Septiembre
Otro mes que vuela, uno nuevo que comienza. Desgraciadamente septiembre no trajo muchos artículos nuevos, llego bastante quemado del trabajo y no alcanza mucho el tiempo. Igualmente el blog recibió varias visitas a entradas antiguas, así que dejo la ya clásica (?!), lista de lo más leido en el mes.
Esto fué lo que los usuarios eligieron durante septiembre:

1. Crear máquina virtual en CentOS usando Xen. El mes pasado se posicionó segundo y este mes trepó al primer lugar. Parece que mi intuición viene bien, cada vez más gente busca probar Xen... seguramente KVM también este entre los más buscados.

2. Utilidad para hackear passwords de Windows y Linux. Con un nombre muy punch (como diría el sensey Javi), este artículo sigue atrayendo muchisima gente y seguramente lo siga haciendo por mucho tiempo... el sueño del pibe, hackear passwords...

3. Top Supercomputadoras. La verdad que me llamó mucho la atención ver este artículo tan arriba, tal vez le hice propaganda en algún lugar y no lo recuerdo. A mi me resultó muy interesante saber cuáles computadoras son las más poderosas actualmente. Tener una computadora de estas es el sueño del pibe...

4. Hacking Bluetooth: ni tan fácil, ni tan imposible. Lo dije el mes pasado y lo vuelvo a repetir, este es uno de mis artículos favoritos, me encanta que siga recibiendo muchas visitas y espero que sigan surgiendo cosas para hacer con bluetooth.

5. Programando tareas con cron. El más nuevito de la lista (data de agosto), lo cree porque en su momento visité varias páginas para utilizar cron, un demonio sencillo y extremadamente útil. Creo que debería estar en el bolsillo de todo administrador =)

Espero este mes contar con más tiempo y escribir varios de los artículos que tengo ganas, los cuales seguramente gustarán mucho, o al menos les resultarán interesantes. Stay tuned!
Es todo acerca de passwords!
Uno de los temas en los que los departamentos de seguridad deben poner énfasis es en concientizar a los usuarios para que utilicen passwords fuertes. No es una tarea sencilla, y puede llevar a discusiones interminables sobre escusas de por qué es difícil recordar passwords largos, pero es algo que debe hacerse y es tal vez más importante que muchos otros aspectos de seguridad.
No es solo cuestión de los usuarios, sino y más importante, de los administradores de sistema. Es sorprendente la baja importancia que se le da a los passwords incluso en áreas donde se conocen los riesgos a los que uno se expone. En parte también es culpa de políticas mal diseñadas que fuerzan a un pobre mortal a cambiar un password continuamente y hacer que el olvido de contraseñas sea algo tan común que se decide utilizar pavadas como passwords.

Ojo, no me excluyo del tema, y es entendible que un usuario que tiene acceso a más de 3 aplicaciones por día, con distintos passwords, los cuales debe cambiar cada cierto tiempo y no se permiten repeticiones (por ejemplo, no podes repetir un password que pusiste hace 6 meses), hacen que uno termine cansándose y poniendo algo que sea fácil de recordar.
Imagínense al pobre administrador de dominio que debe acceder a más de 10 aplicaciones por día... recordar 10 passwords diferentes que cambian continuamente es casi para un robot.

Por esto, es tarea del departamento de seguridad encontrar una solución intermedia, que cumpla con un mínimo de seguridad, pero que no haga que los usuarios se vuelvan locos y quieran linchar al administrador de seguridad (osea, a mi).
Cómo se logra esto? en parte diseñando una buena política de contraseñas, y en parte concientizando a los usuarios sobre cómo crear passwords que sean fuertes y recordables. También es muy importante destacar los riesgos de utilizar passwords débiles, y explicar cuándo un password es débil para que no se cometan equivocaciones al elegirlos.

La fortaleza de los passwords debe ser consistente en todos las aplicaciones donde se necesiten utilizar estas cadenas de caracteres. El acceso a un sistema debido a una contraseña débil, puede hacer que se comprometan otros sistemas donde se utilizaban contraseñas fuertes. Supongan que en el trabajo utilizan una contraseña con 50 caracteres, imposible de romper con sistemas automatizados, pero en su casa utilizan una contraseña de 6 caracteres, bien fácil de romper. Si desde su casa acceden a la empresa a través de VPN, SSH o el protocolo que quieran, y utilizan certificados que almacenan en su máquina para autenticarse en la empresa... perdiste! Si en la máquina de su casa utilizan el "recordar contraseña" para no tener que marcar los 50 caracteres, perdiste!

Para que se den una idea de cuán importante es un password, tengan en mente que muchísimos sistemas se hackean por día debido a una mala elección de estos. Hace un par de meses se daba a conocer el robo de información empresarial alojada en una cuenta de gmail de un empleado de twitter. Cómo sucedió esto? hackearon twitter? NO!, hackearon gmail? NO, fue debido a un password débil (o pregunta de seguridad débil).

No hay parche de software contra la mala elección de passwords. Simplemente hay que aplicar algunas reglas generales para producir buenos passwords y reglas mentales para recordarlos. Es por esto, que la elección de passwords se vuelve el punto más débil de toda organización. Por más que usemos los firewalls más potentes, los mejores antivirus, actualicemos todos los días el sistema, usemos IDS, etc, etc, etc, si no elegimos un buen passwords, ésto no servirá de nada.


Qué debo saber para armar un buen password?

A continuación les dejo algunas reglas generales sobre passwords... apliquenlas siempre que puedan!

- Utilicen un mínimo de 10 caracteres. Con los sistemas actuales, un password que tenga menos de 10 caracteres es rompible en un tiempo razonable. 10 parece un montón para poder recordarlo, pero con algunas técnicas que describiré abajo, podrán armarlos.

- Utilicen una combinación de mayúsculas, minúsculas, números y caracteres especiales (por ejemplo !$%&/#=^´Ç*+@) en su password. Como mínimo agreguen un par de caracteres especiales. De esta forma harán mucho más difícil un ataque por fuerza bruta (ni hablar de los ataques de diccionario).

- Nunca utilicen una palabra que pueda encontrarse en un diccionario, no importa de qué jerga sea el diccionario. Si la contraseña se puede encontrar en un diccionario, un sistema automatizado la puede romper. Cuando digo diccionario, me refiero a cualquier diccionario, así contengan palabras impronunciables de medicina o términos inventados en películas o series (como trustno1, pokemon, starwars, etc), si la palabra es conocida, la van a descubrir.
Este concepto se aplica también a palabras escritas en lenguaje hacker o elite, donde se reemplazan letras por números y caracteres especiales (como el caso de mi nick), ejemplos de estos reemplazos son e -> 3, a -> 4 o @, s -> 5, t -> 7, o -> 0. Existen diccionarios con las palabras escritas en este lenguaje.

- No utilicen información personal. Nada de poner el nombre, dirección, teléfono, documento o cualquier otra información personal como passwords. Cualquier que los conozca puede obtener esta información y utilizarla.

- No utilicen el nombre de usuario como password.

- No utilicen secuencias predecibles como 123456, asdfgh, qwerty, etc.

- Cambien el password cada cierto tiempo. La cantidad de tiempo dependerá de la política de cada aplicación, de la fuerte que sea el password, de los mecanismos de protección de la aplicación (por ejemplo si cada 3 intentos fallidos, el sistema bloquea el usuario) y otros parámetros, pero por regla general, tengan en cuenta que el password debe cambiarse cada cierto tiempo.

- Cuando cambien un password, cambienlo de verdad. Agregar un número al final al password anterior no sirve. Si usaban micasitaloca, luego micasitaloca1, micasitaloca2, micasitaloca3, etc, si en algún momento descubren que el password es micasitaloca, conocerán los passwords que utilizan en cada cambio...

- Utilicen contraseñas distintas en las diferentes aplicaciones que tengan acceso. Esto tal vez sea lo más difícil de cumplir, pero es muy importante, sobre todo para administradores de sistema. Si utilizan el mismo password para todo, y este password se obtiene, el atacante tendrá acceso a todo!

- No le revelen el password ni a Dios (claro que Dios, según la creencia general, lo sabría igual =D). Más allá de los comentarios chistosos, es muy, pero muy importante que no le digan el password a nadie, ni a familiares, ni a amigos, ni siquiera a sus jefes! Que una cuenta sea utilizada por más de una persona hace que sea irrastreable quién generó un problema o realizó alguna maldad, quedando siempre como culpable el dueño de la cuenta. Aunque parezca loco, sus jefes no deberían pedirles el password, si necesita por alguna razón acceder a su cuenta, deberá hacerlo por otros medios, generando el papelerío adecuado que constate el por qué necesita utilizar la cuenta.

- No utilicen "recordar contraseña" en ninguna aplicación, y mucho menos en un celular, notebook, netbook, palm, o cualquier otro dispositivo que sea fácilmente robable. Esto hace que la seguridad de una organización se valla al tacho si alguien irrumpe en uno de estos sistemas.

- No hablar con nadie sobre temas relacionados a la contraseña. Tal vez uno utiliza una frase sacada de algún lugar loco que sería muy difícil de averiguar, pero si la andan comentando, la contraseña se vuelve fácil de adivinar.


Cómo alguien puede romper un password?

Para que no les parezca todo tan loco (el hecho de necesitar 10 caracteres que contenga mayúsculas, minúsculas, números y caracteres especiales puede parecer una locura), me parece que les va a servir una buena justificación. Porque hay una justificación a todo esto, no es un simple capricho de la gente que trabaja en seguridad (en serio!, no se la agarren con nosotros! =P ).

Los ataques utilizados para romper una contraseña son los siguientes:

- Fuerza Bruta. El más conocido de todos, también es el más simple, pero el que consume mayor tiempo. Un ataque por fuerza bruta consiste en utilizar todas las combinaciones de caracteres posibles (por ej. aaaaaa, aaaaab, aaaaac, .... zzzzza, zzzzzb, etc), hasta encontrar la combinación correcta. Este ataque es costoso, sobre todo si no se sabe de antemano la cantidad de caracteres utilizados, pero con la tecnología actual se pueden realizar cientos, miles o millones de pruebas por minuto, dependiendo de si se prueba localmente o por red.

- Diccionario. Este ataque se basa en utilizar diccionarios para realizar las pruebas. En lugar de hacer ataques ciegamente con todas las combinaciones posibles, se utilizan palabras conocidas para realizar cada intento. Existen diccionarios de todo tipo, con palabras de medicina, películas, computación, mecánica, etc. Por supuesto que existen diccionarios para todos los idiomas sobre todos los rubros. Estos ataque son los más efectivos y rápidos dado que la cantidad de palabras a probar siempre es menor a tener que probar todo el espectro combinaciones de caracteres.

- Rainbow Tables. Ataque con una lógica más compleja que los anteriores. Se basa en romper los passwords a partir de los hashes almacenados en un dado sistema. Para el que no lo sepa, la mayoría de los sistemas (si son sistemas bien hechos) no almacenan los passwords de forma plana, sino que primero les aplican una función de hash y luego almacenan el hash obtenido. Por esto, si alguien obtiene la lista de hashes, primero deberá obtener la contraseña a partir del hash para poder utilizar una cuenta de usuario. Por lógica estos hashes son difíciles de romper, pero con el ataque utilizando rainbow tables, dependiendo del algoritmo de hashing y de si se utiliza salt (número aleatorio pegado al password antes de generar el hash), obtener un password de menos de 15 caracteres es cuestión de minutos.
Claro que para poder aplicar este ataque, el atacante primero deberá obtener la lista de hashes, y para eso primero debe obtener acceso al sistema con privilegios de administrador.
No hay mucho que un usuario común pueda hacer contra los rainbow tables, al menos que utilice más de 15 caracteres en sus contraseñas, pero lo nombro porque es un ataque muy utilizado últimamente.

- Ingeniería Social. Para mi, el top de los ataques. Nada de esperar horas de ejecución, irrumpir en sistemas, buscar diccionarios, siempre es más fácil encontrar a alguien que termine revelando su password por voluntad propia. Es relativamente fácil utilizar artilugios en conversaciones para que otra persona, sin darse cuenta, termine revelando su password. Por ello en la sección anterior destaqué el hecho de que no le deben revelar el password a nadie!, mucho menos si no están seguros de con quién están hablando!

- Otras técnicas dependientes de la aplicación que autentica. Existen otras técnicas que se basan en falencias de cada aplicación y no tienen tanto que ver con lo fuerte que sea el password del usuario, por lo que quedarán para otro informe =P


Cómo mierd* armo un password de más de 10 caracteres con todo tipo de caracteres distintos y acordarmelo!!!???

Llegamos a la pregunta cumbre, cómo hacemos para cumplir con todo lo que dije y no quemarnos el cerebro en el intento.
Una contraseña debe ser difícil de romper, pero a su vez, debe ser recordable. Si a cada rato tenemos que llamar al administrador para que nos resetee la contraseña, no sólo nos haremos odiar, sino que no podremos trabajar. Por ello, algunas ideas generales que pueden encontrar en la red son las siguientes:

- Utilizar una frase con varias palabras. Las frases son buenas porque son recordables. Eso sí, no utilicen una frase que dicen continuamente, utilizan en la vida diaria, o sea extremadamente conocida. Utilicen algo sacado de algún libro o algo por el estilo. Nunca hablen de la frase frente a nadie, para no dar indicios.

- Utilizar las iniciales de una frase y agregarles complejidad. Como en el punto anterior, utilizaremos una frase, pero en lugar de tener la frase entera, usamos solamente las iniciales. Por ejemplo, podemos utilizar la frase "Los de Micrsoft son unos ladrones increíbles, pero de ladrones se compone el mundo" (by d3m4s1@d0v1v0), con lo que tenemos las iniciales ldmsuliplscem. Ahora para que no quede todo en minúsculas, rompible fácilmente, cambiamos algunas letras por mayúsculas y agregamos algunos símbolos, con lo que podría quedar así: "lDM5u|_1PdlSc#m". Traten de generar variaciones que luego recuerden.

- Utilizar dos palabras concatenadas con algún caracter especial en el medio. En este caso podemos usar las palabras seguridad y linux de la siguiente manera: seguridad$@linux.

- Utilizar dos palabras entrelazadas letra por letra, agregando caracteres especiales y números. En este caso, el ejemplo anterior (palabras seguridad y linux) podría quedar: sl31gnuXrid@d.

- Escribir cualquier cosa con todos los caracteres posibles y repetir la escritura muchas veces hasta hacerlo mecánico. Esta técnica es la que yo empleo. Escriben algo totalmente sin sentido como j#dw=menta67jjBOz3D en un archivo leíble, y lo repiten varias veces a lo largo del día hasta que se les hace tan mecánico que es como si escribieran algo con total sentido.

- Sorprendanse. Como última tip, queda decir que utilicen alguna técnica que mezcle a las anteriores o utilice otra idea. Siempre que el password sea de más de 10 caracteres y utilice mayúsculas, minúsculas, números y caracteres especiales, y no sea palabra de diccionario, y les resulte fácil de recordar.


Algunos ejemplos reales de malos passwords

Si buscan en google "common passwords" o "contraseñas comunes", se pueden encontrar con varias páginas que revelan datos sobre distintos exámenes en bases de datos de diferentes lugares.
En Most common password list from 3 databases se revelan los passwords hackeados de 3 sites muy utilizados (singles.org, phpBB y MySpace). En el top de los más utilizados nos encontramos con 123456, password, qwerty, 12345, jesus, 12345678, abc123.
En The top 500 Worst Passwords of All Time nos encontramos con una simpática lista de los passwords que la gente (de habla inglesa) suele utilizar. Lo gracioso es que 1 de cada 9 personas utiliza un password de esa lista y una de cada 50 utiliza alguno de los 20 primeros!
Muchos de los passwords en estas listas se aplican a gente de habla hispana.


Conclusiones

Incentivar a los usuarios para que utilicen passwords fuertes y recordables es una tarea difícil, pero que se tiene que hacer. Hay varias reglas a cumplir y es importante que estas sean transmitidas a todos los usuarios. Siempre que piensen en un password, piensen en las técnicas de cracking y en si sería posible crackearlo con alguna de ellas.
Existe formas relativamente simples de crear buenos passwords y que sean recordables, es cuestión de aplicarlas a la vida diaria.
Coincido totalmente con Roger A. Grimes en su artículo Password-cracking contest proves theory cuando dice: "I maintain that length is a better computational protector of password confidentiality than complexity, because true complexity is not easily enforced. And if it is enforced, most users will revolt, frequently forget passwords, or write them down. So if we can’t guarantee complexity, length is a better protector."
Es decir, el mantiene que el largo es mejor protector computacional de la confidencialidad de un password que la complejidad, porque la verdadera complejidad no es realmente forzada. Y si ésta no es forzada, la mayoría de los usuarios se revelarán, frecuentemente olvidando passwords o anotándolos. Así que si no podemos garantizar complejidad, el largo es un mejor protector.
Por esto, creo que las frases largas pueden ser mejores passwords que otro totalmente complejo pero olvidable.
Creando y Accediendo man pages
Todo aquel que se inicia en Linux (o en cualquier sistema *nix) y busca información sobre cómo usar un comando, función de librería, dispositivo, etc, seguramente se encuentre con comentarios en la red referidos a leer el manual. Más de una vez se encontrarán con gente que utiliza las siglas RTFM (Read The F*cking Manual), con el afán de que la gente no sea vaga y lea los manuales, que para eso están!
En los sistemas *nix (y Linux en particular), los programas suelen venir con manuales que pueden ser accedidos desde línea de comandos utilizando el comando man. Todo aquel que lleva un tiempo utilizando Linux sabe que ésta es la fuente de información más directa, y a pesar de que los años pasan e internet se vuelve la mayor fuente de información, los man pages siguen ahí, y se siguen utilizando mucho.

Ahora, aquellos curiosos como yo, querrán saber dónde están estos manuales y en qué formato se escriben. Todo programador *nix debería saber cómo escribir el manual de su programa, que acompañe al programa en sí para que luego pueda ser accedido por los usuarios. Es por eso que me interesé en investigar y escribir este artículo.

Por suerte la vida nos sonríe y escribir manuales es extremadamente sencillo, sólo hace falta conocer la estructura básica. Los man pages se escriben en texto plano, utilizando ciertos tags para demarcar secciones y tipo de letra. Estos tags son interpretados por el procesador nroff (o groff) y traducido a formato lindo, entendible para el usuario.


Formato del manual

El procesamiento de los manuales es como el de los lenguajes HTML, LaTeX y otros. Los tags se interpretan y se formatean las líneas según el significado del tag. El sistema permite diversos formateos, como cambios de font, espaciado, margenes, y notas al pie, entre otros.
Actualmente, los procesadores más utilizados son nroff (newer roff) y groff (GNU roof), los cuales, descienden de troff, el cual a su vez es hijo de roff, y si seguimos para arriba en el árbol genealógico de este programa, nos encontramos con RUNOFF (cuyo nombre, supuestamente, proviene de la frase "I'll run off a document").

Como cualquiera que haya abierto un manual en Linux pudo observar, éstos se estructuran de la siguiente forma:
1. Cabecera
2. Nombre
3. Sinopsis
4. Descripción
5. Opciones
6. Recursos
7. Diagnósticos
8. Véase También
9. Copyright
10. Bugs
11. Autores

Como mencioné, el formato descripto es para los manuales de Linux, dado que los manuales Unix siguen un patrón algo diferente:
1. Cabecera
2. Nombre
3. Sinopsis
4. Descripción
5. Opciones
6. Archivos
7. Véase También
8. Bugs

Por supuesto que no todas las secciones son mandatorias. Si bien es deseable que un manual tenga las secciones citadas, es posible eliminar secciones que no sean relevantes. En los manuales de Linux también es posible encontrarse con las secciones:
- Valores de Salida
- Errores
- Entorno
- Versiones
- Conforme a
- Notas
- Ejemplos

Cada sección dependerá del tipo de manual que estemos armando. Los manuales pueden ser de alguno de los siguientes tipos:
0 - Header files
1 - Comandos estándar
2 - Linux kernel system calls
3 - Funciones de librería estándar de c
4 - Dispositivos especiales
5 - Formatos de archivo y convenciones
6 - Juegos
7 - Misceláneos, por ejemplo estándares (SQL, ISO, etc)
8 - Comandos de administración de sistema (generalmente sólo para root)
9 - Rutinas del kernel
n - nuevo [obsoleto]
l - local [obsoleto]
p - público [obsoleto]
o - viejo [obsoleto]

Para el funcionamiento que nosotros estamos buscando (crear un manual simple), los tags principales son los siguiente:
* .TH - Título del man page
* .SH - Titulo de sección
* .SS - Título de sub-section
* .PP - Nuevo párrafo
* .B - Texto en negrita
* .I - Texto en itálica
* .BR - Salto de línea
* ." - Línea de comentario

Para conocer otros tags, pueden dirigirse a Creating and Formating man pages o a troff/nroff quick reference. Ahora, veamos un ejemplo. Creamos un archivo de texto llamado dtransfer.txt que contenga el siguiente texto:

." seteamos un titulo
.TH dtransfer 1
." creamos una seccion
.SH NOMBRE
transferidor de archivos de demasiadovivo
.SH SINOPSIS
dtransfer -h <
.I host
> -p lt;
.I port
> -f lt;
.I file
>
.SH DESCRIPCION
Programa para transferir archivos entre máquinas
.SH OPCIONES
." poner opciones en subsecciones
.B -v
versión
.SH EJEMPLO
dtransfer -h 192.168.0.1 -p 4444 -f /home/demasiadovivo/man-pages.txt
.SH AUTOR
demasiadovivo

y luego verificamos que el manual tiene la forma que deseamos, utilizando nroff:
$ nroff -man dtransfer.txt
Si todo va bien, nroff nos mostrará la salida de cómo se ve el manual formateado.


Ubicación de los manuales

Ahora, qué hacemos con los manuales? es claro que si no los ponemos en una carpeta donde el comando man pueda encontrarlos, no nos servirá de mucho. En Linux, los manuales se ubican en /usr/share/man o /usr/local/man. Si inspeccionan la carpeta de manuales, observarán que existen varias subcarpetas, algunas de las cuales comienzan con man, osea, la palabra man más el número del tipo de manual. Así los manuales de comandos van en man1, los de funciones en man3, los misceláneos en man7, etc. También existe una convención para mantener manuales en distintos lenguajes, es por ello que en el directorio de manuales también podemos encontrarnos con un directorio por cada lenguaje. Por ejemplo, los manuales en español van en es, los japoneses en ja, los de alemania en de, etc. Dentro de cada directorio de idioma, se sigue la misma convención antes citada para los tipos de manuales, así nos encontraremos con es/man1 para los comandos, es/man3 para las funciones, etc.
Una vez que sabemos en dónde ubicar nuestro manual, nos hace falta saber algo más sobre el formato. Como mencioné más arriba, los manuales se escriben en archivos de texto plano, pero para que el comando man los encuentre, deberemos colocar el tipo de manual al final del nombre. Para mi ejemplo, el manual deberá llamarse dtransfer.1 (en lugar de dtransfer.txt). El 1 indica que es un manual de comando. El archivo de texto además deberá comprimirse con gzip antes de posicionarlo en el lugar que debe. Para ello podemos hacer un:
$ gzip dtransfer.1
Recopilando todo lo que tenemos hasta ahora, llegamos a que tenemos un manual de comando, escrito en español, así que deberemos ubicarlo en /usr/share/man/es/man1 (necesitaremos permiso de root para hacerlo):
# mv dtransfer.1.gz /usr/share/man/es/man1
Si todo fue bien, simplemente tipeando "man dtransfer" debería aparecer nuestro super elaborado manual, no es hermoso?

Para más información sobre la estructura de directorios donde van los manuales, pueden leer Filesystem Hierarchy Standard - 4.11 /usr/share: Architecture-independent data.


Más ejemplos

Como siempre, una de las mejores formas de aprender, es mirando ejemplos. Por suerte, contamos con miles! Simplemente vallan a /usr/share/man, descompriman los manuales que quieran y abranlos con su editor favorito para ver el formato.


Accediendo manuales

Dado que tenemos varios tipos de manuales en diferentes lenguajes, también es interesante saber cómo acceder a un dado manual utilizando el comando man. Si bien tipeando "man man" podemos obtener información sobre cómo usar man, para completar el artículo me parece interesante mencionar algunas opciones:
man -a, --all : nos muestra secuencialmente todos los manuales que encuentra sobre .
man : nos muestra el manual del tipo indicado en . Por ejemplo, si queremos ver el manual del comando time, tipeamos man 1 time, pero si queremos el manual para usar time en programación, hacemos man 7 time.
man -k, --apropos [palabra1] [palabra2] ... : busca todos los manuales en donde aparezcan las palabras claves dentro de la definición del manual.
man -w, --where, --location : muestra la ubicación del manual dentro del sistema de archivos.

El idioma del manual dependerá del locale que tengamos seteado. El locale es un conjunto de parámetros que definen características de nuestra localidad, como ser, lenguaje, codificación de caracteres, tipo de moneda, formato de hora, etc. El locale se setea utilizando las variables de entorno $LANG y $LC_* ($LC_COLLATE, $LC_CTYPE, $LC_MONETARY, $LC_TIME, $LC_NUMERIC, $LC_MESSAGES, etc). Si por ejemplo, en la variable $LANG tienen seteado es_AR.UTF-8, man primero buscará los manuales en español para la palabra buscada, si no lo encuentra, buscará entre los manuales default (en ingles de USA). Para leer un poco más sobre los locale, pueden visitar Locales en Ubuntu y Controlling your locale with environment variables.


Convirtiendo manuales

Para darle un cierre a este interesante tema de man pages, me gustaría citar algunas transformaciones que pueden hacerse a los manuales.
Odian ver los manuales en la consola?, son amantes de la web y quisieran ver los manuales desde el firefox? a no desesperar, porque existen facilidades para transformar los manuales a html. Una de estas herramientas es man2html, con la cual simplemente necesitaremos apuntar el browser a http://localhost/cgi-bin/man/man2html para leer y buscar manuales.

Utilizando groff y la opción -T también es posible transformar páginas en formato troff a ps, dvi, html, y con la combinación ps2pdf es posible obtener los manuales en formato pdf. Para más información, vean el manual de groff: man groff.

Por último, les va a resultar interesante saber que konqueror trae incorporado una función para formatear man pages e info pages. Simplemente basta tipear man: en la barra de direcciones para ver el manual en cuestión. Por ejemplo, si tipean man:ls verán el manual de ls. Sin dudas, konqueror es una gran herramienta que nos brinda muchísimas funciones.


Algunas otras referencias

Creating Linux Man Pages - How to Create On-Line Documentation for Linux
Linux Man Page HowTo
Creating a Linux Manual (man) Page
Man and Info Pages
Charla con Panel de Graduados
Ayer me invitaron a participar como panelista en una charla para estudiantes e ingresantes de la universidad, para que puedan saber cómo es la vida luego de la universidad, cómo es trabajar, cuánto sirve la universidad una vez que empezamos a trabajar o para conseguir el trabajo. Creo que están muy buenas este tipo de charlas, porque uno como estudiante o ingresante tiene muchas dudas sobre el futuro, y sobre si lo que sigue te va a gustar o no.
La charla me gustó mucho, así que me pareció interesante compartir las respuestas que dí a cada una de las preguntas planteadas. Por supuesto que ahora con más tiempo para pensar en qué poner, pude elaborar mucho mejor lo que pretendía decir, así que desarrollé mejor cada uno de los temas.
Para que entren en contexto, les comento que soy Ingeniero en Sistemas de Computación y que actualmente trabajo como administrador de seguridad en una empresa importante que no se dedica al desarrollo de software. Mi experiencia es de sólo 8 meses, pero creo que es suficiente como para tener un pantallazo general de cómo va todo después del estudio, y por suerte mi opinión era muy similar a la de los otros panelistas, los cuales cuentan con más años de experiencia.

En fin, sin más introducción, les dejo las preguntas y las respuestas:

1. Enumere tres competencias que considere fundamentales para la iniciación profesional dentro de la disciplina.
- saber programar: sin importar el área de informática que deseen seguir, van a necesitar programar, aunque sean simples scripts que automaticen alguna tarea, es indispensable saber programar y conocer las herramientas con las que cuentan para no repetir trabajo ya hecho por otro. Incluso en mi tarea de administrador de seguridad, me es imprescindible saber programar, conocer lenguajes, conocer bases de datos, porque sino no puedo entender como funcionan las cosas y si no entiendo como funcionan, no puedo saber qué fallas pueden tener.

- hablar ingles: si bien en el comienzo de la carrera uno puede llegar a pensar que saber ingles no es estrictamente necesario, con el correr del tiempo se va haciendo más notorio. La información se publica en ingles, así que para mantenernos al día, aprender nuevas técnicas, saber cómo realizar ciertas tareas, y muchas otras cosas, necesitaremos como mínimo saber leer ingles. Pero es muy importante aprender a escribir y hablar tambien, de a poco esta característica se va volviendo excluyente a la hora de contratar profesionales de informática.

- ser proactivo: sacando cualquier característica técnica, ser proactivo es indispensable. La tecnología avanza y si uno no continúa aprendiendo, continúa investigando, se va quedando en el tiempo y perdiendo mucho terreno frente a gente que si se mantiene al día. Creo que una de las cosas que más busca una empresa en un empleado es que sea proactivo. Alguien que se recibió de la universidad ya tiene los conocimientos básicos para conocer cualquier otra herramienta, técnica, o lo que haga falta, sólo falta el interés de la persona por seguir aprendiendo. Con el correr del tiempo, una persona que no es proactiva se va notando y las empresas lo ven.


2. Cuáles de estas competencias considera que usted tenía desarrolladas al comenzar a trabajar y cuáles tuvo que adquirir o profundizar.

Por suerte, gracias al nivel de la universidad, no tuve ningún problema en cuanto a conocimientos necesarios para programar. Si bien yo no sigo una carrera de programador en el nivel laboral, como mencioné antes, necesito muchos conocimientos de programación. Además las personas que han estudiado con migo no han tenido ningún problema para adaptarse en carreras de programación, utilizando las últimas tecnologías.

Por su parte, el inglés no lo tenía tan bien desarrollado. Si bien puedo leer cualquier texto, artículo o libro en inglés, me cuesta un poco escribirlo y un poco más hablarlo. Es por eso que me encuentro desarrollando esa área, que si bien puede no parecer ligada a la carrera de informática, en realidad si lo está, y mucho. Por eso mi consejo es, estudien inglés en paralelo con sus carreras de informática, es estrictamente necesario para lograr crecer y ascender. Una vez que sepan ingles, si son proactivos, no van a tener límites.

Siempre fui una persona proactiva, así que se podría decir que no tuve ningún problema en ese campo. Me encanta investigar, me encanta saber más, no me puedo quedar con que algo funciona de una manera y que me digan "es así, porque si", necesito saber que lo hace funcionar. Esto mismo es el motivo para mantener un blog, una forma de seguir investigando y poder compartir con otros lo que voy descubriendo, el mismo eslogan del blog está pensado en ello: "constante deseo por saber cómo funcionan las cosas".


3. Cuáles de estas competencias están actualmente más desarrolladas en los graduados y cuáles menos.

A nivel programación no tengo nada para decir, el desarrollo está perfecto. Ningún egresado que conozca ha encontrado problemas a la hora de enfrentar proyectos de cualquier tipo y tamaño. Es verdad que en un principio harán falta horas de estudio detrás de la tecnología específica que se utilice en el lugar de trabajo (lenguaje, framework, patrones, etc), pero el entrenamiento requerirá de poco tiempo para poder empezar a producir. La universidad brinda las bases para que enfrentemos cualquier tipo de problemas, y la programación es de los más desarrollados.

Para que una persona logre recibirse será necesario un cierto nivel de lectura en inglés (los libros utilizados están en inglés), así que podría afirmar que el nivel de inglés está bastante desarrollado. Igualmente hace falta trabajar en paralelo para aprender a hablar y escribir correctamente en inglés para poder seguir progresando. No es responsabilidad de la carrera de informática enseñar inglés, es algo que tendremos que aprender por nosotros mismos.

En cuanto a la proactividad, en cada materia los profesores incentivan a los alumnos a seguir buscando, seguir investigando, no quedarse solamente con lo que se da en clase. Esto es algo muy valorable y que ayuda a no encerrarnos solamente en estudiar lo dado, sino a seguir buscando. Pero claro, esto depende muchísimo del alumno. Conozco mucha gente que ama la profesión y que durante la carrera se esforzó por aprender otras cosas, o profundizar en los temas que veía en clases, pero también conozco mucha gente que se quedó sólo con lo dado, e hizo lo justo y necesario para aprobar.


4. Cómo percibe la evolución del mercado laboral vinculado a nuestra disciplina en los últimos años y cuál es su expectativa para los próximos años en:

· el mundo: cualquier persona que no viva en un raviol sabe que a nivel mundial la tecnología abarca la mayor parte del mercado, todo, y cuando digo todo es TODO necesita de la informática, desde un transbordador espacial hasta el kiosco que quiere mantener un inventario de lo que vende, todos necesitan de la informática. El crecimiento se da a pasos agigantados y a veces cuesta mantenerse al día con tantos avances. La demanda por sistemas informáticos va a seguir creciendo, se va a seguir avanzando, por lo que va a haber cada vez más demanda. Actualmente, cualquiera que siga una carrera informática, tiene el futuro asegurado.

· Argentina: desgraciadamente en Argentina estamos bastante alejados en cuanto a tecnología, basta recordar el post donde hablé sobre la "supercomputadora" más potente que tenemos para darnos cuenta de esto. Además el gobierno no ayuda para nada, agrandando la brecha informática con impuestazos sin lógica, y no valorando correctamente el trabajo de investigación.
A pesar de todo esto, de a poco vamos progresando igual. A pasos más lentos, pero seguros. La informática te pasa por arriba, no es algo que se pueda evitar, tarde o temprano todo llega. Podemos ver varios ejemplos de ello. Basta ver como de a poco vamos adoptando distintas tecnologías de programación, como mejoró la conectividad a internet, cómo se fueron definiendo mejor los roles informáticos (administradores, programadores jr, administradores de seguridad, etc, etc), y muchas otras cosas.
Las posibilidades en Argentina se van agrandando, hace falta muchísima manos de obra informática, y las universidades brindan egresados de gran calidad, adaptados para cualquier problema a afrontar. Además la gran diferencia con el dolar y el euro favorecen muchísimo al mercado local, sólo hace falta que otros países empiecen a confiar más en la calidad brindada por los informáticos arentinos, algo que se viene dando bastante bien.

· Nuestra ciudad: actualmente las grandes fuerzas informáticas del país se encuentran definidas en unas pocas ciudades, como ser capital, córdoba, mendoza, rosario y algunas pocas más, por lo que como ciudad, todavía estamos bastante lejos. Actualmente la mayor salida laboral en la ciudad es la producción de software, la cual ha mejorado muchísimo gracias a la instalación de grandes empresas que incluso exportan software al extrangero. Desgraciadamente estas empresas toman al egresado como mano de obra barata, desmereciendo mucho el trabajo profesional que realizan (malditos explotadores!!!), el cual en ciudades como capital pagan muchísimo mejor.
Igualmente, la perspectiva es muy buena. En los últimos años se han instalado empresas interesantes y se abrió bastante el abanico de tareas que un informático puede desempeñar, con áreas como el multiprocesamiento paralelo, sistemas embebidos, desarrollo y funcionales SAP, seguridad en sistemas, además del ya comentado desarrollo de software importante (en tecnologías .Net y Java). Además existen rumores de empresas importantes que podrían instalarse en la ciudad en los próximos meses, lo cual abriría más el mercado, forzando a las empresas actuales a competir por empleados y aumentando la remuneración actual.
El hecho de tener una universidad que brinda muy buenos profesionales en el área, hará que todavía más empresas se fijen en el mercado de la ciudad y se irán instalando, es cuestión de tiempo.


5. Cuáles considera que son las principales dificultades que enfrenta un alumno de nivel medio al ingresar a la Universidad (en su experiencia personal y en la que pudo percibir en sus compañeros)

En mi caso particular y por lo que he visto en mis amigos y conocidos, el paredón más grande es el "abre tu mente". La universidad te fuerza a pensar por vos mismo, a arreglártelas sólo, a aprender cómo solucionar los diferentes problemas que se van planteando. Esto difiere mucho de la secundaria, donde todo está estipulado en fórmulas y pareciera que sólo hay una forma de hacer y entender las cosas. En la secundaria por poco te dicen hasta qué renglon de qué libro tenes que leer y no te alientan demasiado a informarte un poco más. Todo esto cambia en la universidad, donde tendrás que aprender a pensar (suena loco, pero es así), a abrirte la cabeza para entender cosas que parecen complejas o locas, pero que luego parecen tener total sentido (bueno, en algunos casos no tanto =D ).
Todo es cuestión de dedicación, de sobrepasar la frustración, de reintentar en los casos que no entendemos, de no desanimarnos por desaprobar una o dos (o como en mi caso, varios =P) parciales. El ritmo es bastante alocado y al principio cuesta ajustar los tiempos para estudiar y entender todo, pero todo es cuestión de adaptación y madurez.
La imagen es ilustrativa (las piezas se venden por separado)
En la corta experiencia que tengo como administrador de seguridad, me he topado con problemas aberrantes en aplicaciones hechas a medida y con proveedores de software que se encargan de vender el producto en partes, pero cobrando cada parte como un producto entero... hoy rebalse...

Cuando uno pienza en adquirir software, piensa en un programa completo, que cumpla con las tareas para las que se lo diseña, sea eficiente, confiable, usable, seguro, etc (pueden leer más sobre características de un soft de calidad en wiki). Ahora, parece que cada una de estas piezas se venden por separado!

Dejando de lado otras propiedades importantísimas como eficiencia, confiabilidad y demás, la parte que a mi me importa es la de seguridad... la cual suele ser a la que menos se le presta atención, y sobre la que los programadores tienen menos experiencia. El problema es que los programas vienen con un mínimo (casi inexistente) nivel de seguridad, y cuando uno exige que se implementen correctamente los controles necesarios para que el programa sea seguro, te lo cobran a parte!... la implícita frase "ah!, lo querías seguro?, eso es otro precio!" se hace presente con cada proveedor de software con el que tengo el agrado (?!) de tratar.

Pongamos algo en claro, la seguridad debe formar parte del software, sin seguridad, el software está incompleto. La seguridad NO es un add-on que se cobra por separado! Cuando se diseña software, se deben tener en cuenta los controles de seguridad. Es como si me vendieran un auto sin cerradura! la cerradura no me la cobran por separado, ya viene con el auto! acaso comprarían un auto sin cerradura? NO!, por eso yo no compraría un software que ni siquiera almacena passwords hasheados, define roles, o almacena un maldito log!

Realmente me parece una estafa total, una pésima calidad de trabajo y sobre todo, una tomada de pelo al usuario final. A cualquiera le puede pasar que se olvide colocar un control de seguridad o implementarlo incorrectamente, de hecho, los programas vienen con miles de bugs, pero de ahí a que quieras cobrar la seguridad como si fuera un agregado al software, es un robo.

Espero que las empresas desarrolladoras de software tengan en cuenta lo que es un software de calidad, capaciten a los desarrolladores en programación segura, y tengan un mínimo de decencia de corregir los errores, sin cobrar por estos como si se tratase de un agregado.


[Imagen tomada de Lego Laptop]