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]
Hora en Linux y diferencias con Windows
Estos últimos días estuve experimentando problemas con la hora en Linux. Algo se rompió después de una actualización y el reloj estaba tomando mal la hora.
Igualmente esto ya me había pasado hace un tiempo, entre reiniciada en Linux y Windows, tenía problemas con la hora. Después de un poco de búsqueda, encontré la razón del problema, así que decidí compartir con ustedes cómo se maneja la hora en Linux.

El problema es básicamente que en Linux el sistema se configura para utilizar el reloj de hardware como hora universal (UTC o GMT) y calcula la hora local realizando la conversión correspondiente a nuestro país utilizando zonas horarias (timezone); mientras que Windows toma la hora de hardware directamente como hora local.
Y entonces qué?... bueno, si por ejemplo colocamos nuestro reloj de hardware para ser hora UTC, seteamos el timezone correspondiente a nuestro país, en Linux la hora estará bien, pero en Windows tenemos la hora UTC como hora local, y si colocamos la hora bien en Windows, tendremos mal la hora en Linux.

En Linux al bootear se lee la hora del reloj de hardware, se coloca en el reloj del sistema y luego se calcula la hora local en base al timezone que tengamos seteado. Por esto es que tenemos dos relojes, el de hardware y el de sistema, los cuales almacenarán horas diferentes y se modifican con comandos diferentes.

Para modificar la hora podemos utilizar el comando date, el cual modifica el reloj del sistema, por lo que las modificaciones no serán visibles luego de reiniciar, esto es algo que me hizo perder bastante tiempo...
El comando date no sólo nos permite setear la hora local, sino también ver la hora actual. Si corremos date sin argumentos, podemos ver la hora actual. Ahora, el funcionamiento básico para setear la hora con date es date <mes><dia><hora en formato 24><minutos>, así por ejemplo, si queremos decir que es 5 de septiembre a las 18:57, deberemos escribir date 09051857. date permite otros argumentos para poder decirle en qué formato le estamos pasando la hora, pero ese es el funcionamiento más básico y a mi me alcanza.
Una forma tal vez más visible, es utilizar el parámetro set, así podemos lograr setear el año también. Para el ejemplo anterior, el formato sería el siguiente: date --set "2009-09-05 18:57".

Como menciono en el párrafo anterior, date setea la hora del sistema, no la de hardware. Si queremos setear la hora de hardware, deberemos utilizar el comando hwclock. La forma más sencilla de setear la hora de hardware es acomodarla según la hora del sistema, es decir, sincronizamos el reloj de hardware con el del sistema. Para lograr esto, debemos ejecutar "hwclock --systohc", si es que no deseamos utilizar UTC, o bien "hwclock --systohc --utc
" si queremos que el reloj de hardware mantenga la hora UTC, el comando hará la conversión acorde al timezone.
Si le queremos dar la hora directamente al hardware (sin importar qué hora tengamos en el sistema), para el ejemplo del 5 de Septiembre a las 18:57, deberemos utilizar el comando: hwclock --set --date "2009-09-05 18:17"

Es interesante destacar el hecho de mantener la hora de hardware en UTC, todos los manuales UNIX aconsejan esto, dado que tendremos varias ventajas, como coordinar la hora con relojes de internet (o intranet), que el reloj se acomode a los cambios de hora en verano sin intervención, o el hecho de que muchos programas utilizan conversiones horarias para enviar datos a otros países.
Utilizar timezones en Linux es muy sencillo. Para ello tendremos que acomodar el valor /etc/localtime para que mantenga la zona adecuada. Hay dos formas de setear /etc/localtime, la más utilizada es crear un link simbólico a la zona correspondiente en /usr/share/zoneinfo. Si por ejemplo viven en Argentina provincia de Buenos Aires, deberían ejecutar el siguiente comando: ln -sf /usr/share/zoneinfo/America/Argentina/Buenos_Aires /etc/localtime. Cabe destacar que en algunas distribuciones, las zonas se encuentran en /usr/lib/zoneinfo en lugar de /usr/share/zoneinfo, así que presten atención.
Algo a tener muy en cuenta, y es el problema que estuve teniendo, es que en debian cambiaron la idea de linkear /etc/localtime a la zona correcta, y decidieron hacer que /etc/localtime sea una copia de la zona. El cambio surgió a raíz de un bug reportado a las listas de debian, donde si mantenemos el directorio /usr en una partición diferente a la raíz, tendremos un problema. El problema es que si se setea la hora antes de montarse la partición /usr, el sistema arrojará un error, dado que no puede seguir el link. Por esto, se decidió copiar la zona en /etc/localtime. Igual la solución es simple, ejecutar el comando "dpkg-reconfigure tzdata" y elegir en las pantallas subsiguientes la zona que deseamos utilizar.

El problema, para variar, es el maldito Windows, el cual por defecto no le da bola a los timezones y toma la hora de hardware como hora de sistema, rompiéndonos los esquemas. Por esto, si tenemos un esquema de boot dual (Linux/Windows), dependiendo el sistema que iniciemos, veremos una hora diferente. Para solucionar esto desde linux, si no nos importa utilizar hora basada en UTC, deberemos modificar la variable UTC leída al iniciar el sistema cuando se carga el valor del reloj de sistema. Esta variable se encuentra en /etc/default/rcS en sistemas debian o basados en debian, y en /etc/sysconfig/clock en Red Hat y derivados. Si no queremos utilizar UTC, será necesario colocar UTC=no dentro de los citados archivos, los cuales son archivos de texto editables con cualquier editor.
Ahora, esa es la idea, hacer UTC=no dentro de dichos archivos, pero a mi no me funcionó!, por lo que decidí utilizar como timezone UTC+0, osea, sin desfasaje UTC, como si viviera en Londres. Así que luego de solucionar el problema de que en debian no sirve linkear /etc/localtime a la zona UTC, terminé utilizando "dpkg-reconfigure tzdata" y elegir Etc -> UTC. Ahora tengo el problema solucionado.
En un foro leí que se puede utilizar la variable HWCLOCKPARS="--directisa" dentro de /etc/default/rcS y que de esa forma se solucionó el problema de muchos, pero a mi no me sirvió. Si alguno tiene alguna otra sujerencia, son bienvenidos a comentarla =D

Como siempre, espero que esto les ayude a comprender mejor el manejo del reloj en Linux y les permita configurar sus relojes para que marquen la hora que desean.


Algunas referencias:
Debian GNU/Linux System Administrator's Manual: Chapter 16 - Time
Linux Tips - Linux, Clocks, and Time
Debian Wiki - TimeZoneChanges
HowTo: Clock, Time, UTC, Dual boot with Windows
F*ck! Hotmail no se cierra!
Pensé que con los años dejaría de ver este tipo de mails, pero los años pasan y sigo recibiendo este mail, una y otra vez, cambia un poco la descripción, cambia el supuesto director de hotmail, pero el mensaje final es siempre el mismo "Hotmail se cierra!"...
Para el que sea más nuevo en el tema, vengo recibiendo este mail desde que utilizo internet, osea, desde el 2001, y estoy seguro que data de tiempos anteriores al 2001.
Es increíble, pero la gente sigue creyendo en esta clase de e-mails, a pesar de que lo reciben una y otra vez... cada vez que lo reciben, lo vuelven a mandar!!! BASTA! Hotmail no se cierra!, como se pueden imaginar que algo así puede llegar a ocurrir! y mucho menos que M$ valla a reconocer que tiene problemas de almacenamiento, eso sería como decir "ok, no servimos para esto, nos damos por vencidos"... estamos hablando de M$!
Por otro lado, si están teniendo problemas de almacenamiento no van a alentar a sus usuarios a mandar tonelada de mails que ocupen más almacenamiento!, es totalmente contradictorio!
Además, si se cierra hotmail, qué? dejan de existir los mails? deja de existir el chat? no, no y NO! existen miles de webmails gratuitos, y existen muchos protocolos de chat para utilizar! Como reemplazo perfecto podríamos utilizar Yahoo!/Yahoo! Messenger o Gmail/Gtalk, siendo el servicio de mail de google mucho mejor que el de hotmail...

Ahora, aquel desconfiado que todavía no se convenza con mis palabras se podría preguntar, si no es real, para qué enviarían un mail así?... bueno, tienen muchos motivos.
Por un lado puede utilizarse como una forma de Dennial of Service, saturando la red de mails, intentando voltear el servicio de hotmail... aunque esto data más del pasado, no creo que actualmente sea este el fin... el problema es que estos mails del pasado quedaron vagando por la red por años y siempre hay alguien que los reenvía.
Por otro lado tenemos una forma perfecta para distribuir malware, si el mail se encuentra infectado con alguna vulnerabilidad del browser o de nuestro cliente de correo, estamos listos.
También se puede realizar phishing, pidiendo que visitemos alguna página para registrar alguna información adicional y así regalarle nuestro nombre de usuario y contraseña a un tercero.
Otra posibilidad es ganar algunas visitas en alguna página para sumar plata con alguna forma de adsense.
Hay muchas finalidades para hacer que un mail llegue a las masas, incluyendo una bien infantil, la cual es, simplemente molestar y ver cuantos ignorantes reenvían el mail...

En fin, espero que cuando alguien reciba alguno de estos mails, googlee un poco, encuentre este post y no lo reenvíe más!!! Estoy realmente re podrido de seguir recibiendo "hotmail se cierra!"... hagan correr la bola!
Lo más leído en Agosto
Agosto fue un mes complicado y no tuve mucho tiempo para escribir muchos artículos, pero por suerte igualmente sigo teniendo lectores y varios artículos tuvieron muchas visitas! =)
Este es el resúmen de los 5 posts más leídos durante agosto:

1. Utilidad para hackear passwords de Linux y Windows. Este artículo que escribí en junio este mes se convirtió en el más leído! Parece q mucha gente tiene problemas recordando passwords... o queriendo acceder en otras máquinas =P

2. Crear máquina virtual en CentOS usando Xen. Otro artículo que escribí en junio, que si bien en su momento pareció pasar desapercibido, este mes recibió muchisimas visitas. Por suerte cada vez leo más gente utilizando Xen para virtualizar.

3. Grub configurando el sector de arranque. Claramente el más popular de los artículos que he escrito, mes a mes sigue apareciendo entre los más leídos, y eso que data de mayo. Igualmente no me sorprende para nada, la mayoría de la gente q instala Linux desea configurar grub para adaptarlo a sus necesidades.

4. Hacking Bluetooth ni tan fácil, ni tan imposible. Me alegra mucho que haya interesado este artículo, dado que le dediqué varias horas de investigación y me parece un tema muy interesante, ya todos los celulares traen bluetooth, así q todos estamos en pelígro. Este data de julio.

5. Uso de memoria: Firefox Vs Chrome Vs Safari Vs Opera. Otro que data de junio y despertó mucho interés, siendo el artículo más leído durante julio y ocupando el 5to lugar el pasado agosto. A todos nos interesa el uso de memoria de la herramienta más fundamental para la web: el browser.

Para terminar, quiero agradacer a todos los que me siguen, y espero que les gusten los artículos que tengo pensado escribir, ojalá en septiembre cuente con el tiempo necesario para hacerlo!