RSS |

Blog de Omar

Just another WordPress weblog

Advertisement

Archive for the ‘ Uncategorized ’ Category

Como lo prometido es deuda, estoy tratando de escribir más seguido en el blog. Dejando de lado el tedioso proceso de documentación de los proyectos que estoy realizando, dejando de lado el calor infernal que nos asfixia en Lima durante este verano y dejando de lado la pereza dominical que me invade cada fin de semana que me estoy atreviendo a escribir un nuevo post en el blog.

Antes de comenzar, es casi un requisito leer el post anterior donde habíamos revisado algunas técnicas backdoors que ahora vamos a utilizar: [Backdoors en Linux – Parte 01]

Google Hacking y backdoors

Hay algunos backdoors que son fácilmente de ubicar a través de algunas técnicas de Google Hacking, por lo general estos archivos son utilizados porque son empaquetados y están listos para ser utilizados. Los más comunes son los famosos C99.PHP, C100.PHP, R57.PHP y todas sus variantes. De hecho es muy fácil encontrar servidores que han sido vulnerados y cuyos sysadmins aun no han advertido del hacking ocurrido sobre sus servidores.

image

 

image

 

Ok y si son tan buenos backdoors que todos utilizan, ¿cuál es el problema? de hecho si hay problema, cuando se instalan estos backdoors las solicitudes a estas páginas se realizan a través del método GET y son muy evidentes cuando se revisan los logs, es decir, un administrador de sistemas puede notar algún movimiento extraño al llamar a un archivo que normalmente no forma parte de la aplicación. De hecho hay dos (02) maneras básicas para poder detectar posibles backdoors que podría utilizar un administrador de sistemas:

  1. A través de la evaluación de los logs del servidor: Esto se podría hacer manualmente, es decir buscar archivos clásicos utilizados como backdoors, [AQUÍ] una lista de los más utilizados. Existen herramientas que automatizan la revisión de los archivos de eventos en busca de palabras típicas de un evento de hacking.

    image

    Una herramienta muy interesante para analizar logs de un servidor APACHE se llama LORG y encuentra todo tipo de ataques realizados al servidor. Pueden encontrar mayor información del proyecto LORG en el siguiente enlace: [AQUÍ]. Yo lo instalé para probarlo y ver si detectaba un backdoor muy conocido como el C99.PHP y no lo identificó, realicé algunos ataques manuales de Inyección de Código SQL y funcionó muy bien, aquí si detecto el ataque, les dejo algunas gráficas para que vean como funciona.

    image

  2. A través de scripts que revisan los archivos tipo PHP en busca de funciones “maliciosas” en el servidor, es decir, funciones que no deberían ser utilizadas normalmente, por ejemplo, funciones: EVAL, SYSTEM, EXEC, etc etc. Al final lo que hace este script es buscar funciones dentro de los archivos y nos muestra un resumen de los archivos que ha encontrado con información de posibles puertas traseras.

    Existen varias herramientas que hacen esta revisión:

    - Neopi [Enlace AQUÍ]: De manera personal debo decir que este script realizado en Python no me gusto mucho, me mostraba muchos falsos positivos a pesar de que utilicé los diferentes mecanismos de detección, a pesar de eso pueden probarlo y sacar sus propias conclusiones.

    - PHP SHELL Detector [Enlace AQUÍ]: Este es mucho más simple de utilizar, basta copiar los archivos en el directorio raiz de nuestro apache y ejecutarlo desde el browser. Me gustó porque detectó los backdoors que había colocado en mi servidor de prueba. Lo recomiendo totalmente, aquí les dejo unos printscreen de los resultados obtenidos, en la imagen se puede observar como detectó un archivo PHP ofuscado y el clásico C99.PHP.

    image

    image

  3. Otro mecanismo para detectar los backdoors es buscar de manera manual funciones maliciosas. ¿De manera manual? Pues, es como si tuviéramos que buscar un string en unos archivos que están en determinada carpeta.

image

 

 

Hookworm: Un backdoor muy silencioso

Todas las técnicas arriba mostradas para detectar puertas traseras son las más básicas y seguro funcionan muy bien pero si queremos esconder algún backdoor hay muchas formas interesantes de poder hacerlo y obviamente sin que alguien pueda advertir de su presencia. Voy a detallar los pasos para tener un backdoor en el servidor, aunque primero voy a detallar un escenario para que se comprenda mejor:

Escenario:

Un atacante tiene acceso a través de SSH a un servidor Linux ya que obtuvo la contraseña, un patrón de contraseña utilizado por el administrador de servidores para todos los servidores de la organización. El atacante sabe que el acceso a través de SSH solo es posible desde la red LAN de la empresa y que sólo el puerto TCP/80 del servicio Apache se encuentra expuesto a Internet. Además, cabe la posibilidad que el administrador de servidores restrinja el acceso al puerto SSH a ciertas direcciones IP por lo que es imperativo dejar un backdoor que cumpla con tres (03) características: que le permita acceder con privilegios del usuario ROOT,  sea accedido desde Internet y que además sea lo mas sigiloso posible para pasar desapercibido.

Pasos a realizar:

1. Crear y compilar un archivo escrito en C para obtener un ejecutable. Configurar el SETUID para que se pueda ejecutar con permisos de ROOT.

2. Modificar un archivo el servidor web, de preferencia un archivo PHP que ya existe y añadir la siguiente línea:

image
3. Si reparan en el archivo PHP creado en el paso 02, lo que realmente hace es recibir la variable enviado a través de la cabecera HTTP, en este caso las cookies. Estas cookies recibidas son ejecutadas en el sistema operativo para acceder a cierta información. Lo único que nos falta es poder ejecutar comandos con privilegios de ROOT. Es aquí donde entra el paso 01, con el archivo escrito C y configurado el SETUID podemos obtener estos permisos. Nada complicado por si lo notan, sólo que sigiloso ya que no son enviadas a través de GET o POST.

A. Entonces creamos el archivo en C y lo compilamos para tener un ejecutable. Esto ya lo hicimos en un anterior POST donde está mejor explicado, puedes leer el detalle [AQUÍ]

 

B. Desde un navegador web en donde podamos modificar las cabeceras HTTP y colocar un valor en el cookie. Podríamos haber utilizado BURP SUITE o el TAMPER. Yo he utilizado el Burp Suite que se me hace más fácil de utilizar.

image

 

C. Ahora si ejecutamos comandos de manera conjunta con el backdoor que hemos dejado podemos pasar a convertirnos en ROOT y ser felices tan sólo una vez mas.

image

 

Finalmente, podríamos reemplazar la función SHELL_EXEC (  ) con la función EVAL(  ) de PHP para que pueda pasar más desapercibido todavía. Esto lo haremos en el video para no alargar mas el POST. Hasta pronto.

image

Pd: Este POST comenzó a escribirse el domingo 28 de Febrero de 2016 y terminó de escribirse el 09 de Marzo, me estoy haciendo viejo para escribir en el blog Triste. Saludos.

Popularity: 7% [?]

Si se han tomado la molestia de revisar el Top Ten de OWASP 2010 habrán notado que en la cúspide de esa concisa lista se encuentra el término “A1.- Inyecciones” y lejos de pensar que sólo existen las inyecciones del tipo SQL, lo cual no es cierto, hoy vamos a explicar y revisar las inyecciones del tipo PHP.

Lo cierto es que hace poco me topé con una página web con este tipo de vulnerabilidad, así que me he animado a explicar un poco como funciona esto. Por cierto en la lista candidata para el Top Ten del OWASP 2013 las vulnerabilidades del tipo Inyecciones sigue siendo la primera.

image

La historia es así: me contrataron para hacer la revisión de una página web (un Ethical Hacking), inicié revisando los formularios, los parámetros que se envían entre páginas, no suelo ponerle demasiada atención al XSS a menos que sean persistentes (no saben lo difícil que es explicar y que logren entender el riesgo de un XSS reflejado sobre una página web), empecé a buscar SQL Injection y que creen? si pensaste que sí, estas equivocado, nada!! no encontré nada.

Allí estaba yo… tirado en mi cama como una ballena varada en la orilla del mar pero no suplicando porque me regresen al agua sino preocupado por mostrar alguna vulnerabilidad que deje satisfecho a las personas que me habían contratado y es que cuando sólo les muestras XSS reflejado … te miran con cara de pocos amigos, como diciendo: “¿para esto te he pagado? no jodas pues!!!”.

Para este post voy a simular lo más posible la vulnerabilidad que encontré pero en mi aplicación web y obviamente no en la verdadera página vulnerable, ¿los motivos? no me quiero meter en problemas legales.
Aquí muestro la secuencia del ataque, espero les guste:

  1. Browseando encontré este formulario, no encontré inyecciones del tipo SQL se enviaba el comentario pero advertí que no se usaban los clásicos botones para “Enviar” o “Cancelar” el comentario del formulario sino que se utilizaban imágenes para realizar la misma función. Lo extraño era que para que las imágenes enviaran el formulario y cumplieran funciones distintas en realidad habían dos (02) formularios embebidos.

    image

  2. Revisé el código HTML y encontré los dos formularios, además encontré un campo invisible que también formaba parte del segundo formulario. Tranquilos en la siguiente imagen se ve y explico mejor esto para que todos los logren entender.

    image

  3. Como ya les comenté líneas arriba no encontré inyecciones del tipo SQL (una lástima realmente), así que decidí revisar las variables que se pasaban por el formulario cuando alguien decidía cancelar su comentario. Para analizar las variables que se pasaban en el formulario (hacia la misma página web si es que han notado el ACTION en el formulario) me apoyé del plugin de Firefox, TAMPER DATA. Aquí les muestro lo que me mostró el TAMPER cuando cancelaba el comentario, es decir cuando le daba click en la “X” del formulario.

    image

    Lo curioso ocurrió cuando advertí que al enviar el parámetro ELIMINAR cuyo valor era “eliminado”, aparecía encima del formulario un mensaje que decía que mi comentario había sido eliminado, un momento…. “ELIMINADO” es el valor de la variable, verdad? entonces… ¿qué pasa si modifico con el TAMPER el valor de esa parámetro? quizás sea sólo una coincidencia o de pronto algún STRING toma ese mismo valor y lo concatena.

    image

    La suposición era cierta, el parámetro “ELIMINAR” envía su valor a la página web y luego alguna variable toma ese valor y lo concatena con alguna cadena para mostrar el mensaje encima del formulario.

  4. Ahora toca entender un poco del lenguaje de programación PHP, vamos a tratar de ir suponiendo como el programador de la APP ha escrito el código. Antes de continuar debo aclarar que este punto (o sea el punto 4) no es un análisis que hice cuando realicé en verdadero Ethical sobre la página web, ya mas o menos sabía que debía colocar como valor del parámetro enviado (quizás sea algo de práctica y porque ya antes había visto esta vulnerabilidad y toca ser prácticos) y como este blog está dedicado a explicar como es que funcionan las cosas vamos a explayarnos un poco. Si quieren sólo ver como funciona el ataque sin entender ni papa pueden ir a otros blogs donde se jactan de lanzar un ataque sin explicar como funciona y al que tiene el atrevimiento de preguntar le terminan lanzando puntiagudos adjetivos como “lammer” o “script kiddies”, en fin….. esa gente son un caso, aquí vamos.

    image

    Entonces…. que pasaría si modificamos el valor de la variable $eliminar y lo ponemos algo más interesante como para ver que pasa con el código PHP. Podríamos poner algo así:

    image

    Hemos modificado la variable $eliminar y lo hemos con modificado convenientemente para que no genere ningún error de sintaxis, si se dan cuenta hemos colocado estratégicamente las comillas, los puntos y comas (;) y hasta agregamos una variable adicional para que se concatene con el resto del STRING. Perfecto!!! somos muy hackers!! sólo que si fuera así NO funcionaria. ¿por qué? sigue leyendo este post para enterarte el motivo. La verdadera salida en la web sería de la siguiente manera:

    image

    Si han logrado notar lo único que está ocurriendo es que se está concatenando como una cadena y se está haciendo un ECHO de la misma, nada mas y no se está ejecutando la función PRINT de PHP. Así que… lamentablemente la suposición no es correcta y así NO lo ha hecho el programador.


    ¿Entonces cómo lo ha hecho el programador?

    Pues toda la explicación anterior ha servido para entender como es que se hubiera podido concatenar cadenas con un parámetro modificado por un atacante, es decir, la explicación superior sólo sirvió para que se den una idea de como es el ataque realmente. Ahora si vamos a explicar como es que realmente el programador escribió el código, el programador escribió así realmente:

    image

    La función EVAL( ) de PHP está explicada en la página oficial de documentación del lenguaje: AQUÍ, y como verán permite que se ejecute automáticamente el valor de la variable sin necesidad de concatenar cadenas con puntos (.), obviamente usar la función EVAL( ) tiene sus riesgos y muchas veces es usado para obtener un RETURN del tipo NULL o FALSE y al parecer el programador la utilizó con ese propósito, si quieres entender más sobre la función EVAL( ) revisa estos dos links:

    - Aquí un blog donde lo explican paso por paso, muy detallado y muy didáctico: AQUÍ
    - En la página del proyecto OWASP también está explicado pero muy superficialmente, de igual forma conviene verlo: AQUI


    Importante:

    Sin la función EVAL( ) la inyección de código PHP no hubiera sido posible.

    Con el código que realmente escribió el programador, el resultado de la página web al modificar la variable $eliminar y colocar la función PRINT sería el siguiente:

    image

  5. Interactuando con el Sistema Operativo y CURL
    Ahora que ya sabemos como funciona la inyección de código PHP vamos interactuar con el Sistema Operativo (en este caso un Linux Fedora 14) colocando comandos que se ejecuten sobre el sistema. Básicamente usaremos la función EXEC ( ) que nos permitirá ejecutar comandos a nivel del sistema y lo mezclaremos con la función PRINT ( ) para que sean mostrados como resultado en la página cargada. Luego automatizaremos el ataque con un script que he desarrollado en PHP con CURL y que todo sea más sencillo.

    image

    Por ejemplo aquí hemos ejecutado el comando “WHOAMI” y nos ha devuelto como resultado “APACHE”, si prueban ejecutando otros comandos verán que les devuelve el resultado siempre y cuando el usuario Apache tenga los privilegios para ejecutarlo, sin embargo, hay un pequeño detalle con esto:

    A) Si el comando que ejecutamos devuelve más de una línea como resultado, por ejemplo, el comando “LS /ETC/” sólo se imprime en la pantalla la primera línea del resultado y no todo el listado del resultado.
    B) Que flojera estar ejecutando comando por comando con el TAMPER DATA, no terminaríamos nunca con lo que quisiéramos logra, así que toca automatizar el ataque con un SCRIPT.

  6. Automatizando el Ataque con CURL
    Desarrollé un pequeño script que automatiza el ataque y me permite colocar el comando que quiero ejecutar de manera sencilla, obviamente tocaría customizar el script para algún otro caso particular. Les comparto el script para que puedan revisarlo ya que no está nada complicado.

 

Ahora que ya he automatizado el ataque puedo hacer muchas cosas más con esta vulnerabilidad pero eso lo estoy haciendo en el videotutorial que voy a colgar mañana (al menos eso espero), cosas como: Ejecutar comandos en la base de datos y apoderarme del servidor jejeje.

Saludos,

 

Popularity: 18% [?]

Encapsulación Frame Relay

Frame Relay es un protocolo de capa 2 del modelo OSI, Enlace de Datos, y recibe el paquete de capa 3 y le agrega 2 señalizadores: de inicio y fin, el código de redundancia cíclica (CRC o FCS) y el DLCI.

6fr

DLCI: El valor mas importante de la trama y representa a la conexión virtual.

C/R: No esta definido.

EA (Extended Address): Si esta en 0 que detrás continua otro octeto y si esta en 1 que es el utlimo octeto.

FECN, BECN, DEA: Bits de control de congestion.

7fr

8fr

Nota:    PDU de Capa 3 – Paquete

PDU de Capa 2 – Trama

Asignaciones Frame Relay
Para poder asignar un DLCI en Frame Relay tenemos 2 maneras:

-          Asignación Estática: Esta configuración siempre es mas confiable
-          Asignación Dinámica: Usa ARP

Asignación Estática
El comando para la asignación estática es:

R1 (config-if)# frame-relay map protocol protocol-address dlci [broadcast] [ietf] [cisco].

La encapsulación ietf se usa al conectarse a un router no perteneciente a Cisco.

Asignación Dinámica
Por defecto si nosotros configuramos en un extremo DTE un VC, el protocolo ARP inverso automáticamente busca el VC y se enlaza sin hacer una configuración manual en el otro extremo, para evitar esto debemos desabilitar el arp-invero.

Interfaz de Administración Local (LMI)

Es necesario que los DTE puedan obtener información sobre el estado de la red Frame Relay, debido a eso se creo las extensiones LMI Frame Relay y obtener información del estado de conexión cada 10 segundos.
Existen varios tipos de LMI que son incompatibles entre si. El tipo de LMI del router debe ser igual al Switch Frame Relay. Los tipos de LMI son:

-          Cisco
-          Ansi
-          Q933a

Los router CISCO revisan los mensajes LMI y configuran automáticamente el tipo de LMI para que sean compatibles. Las tramas LMI se basan en las tramas Frame Relay, pero obviamente son diferentes.

9fr

Uso de LMI y ARP Inverso
Cuando R1 se conecta a la red Frame Relay, envia un mensaje de consulta de estado LMI a la red y la red envia un mensaje de estado LMI que contiene detalles de cada VC configurado en el enlace de acceso.

10fr

Si el router necesitas asignar los VC a las direcciones de cada de red, envía un mensaje ARP inverso desde cada VC y el otro extremo responde con la direccion IP; de esta manera se forman los circuitos virtuales con su correspondiente DLCI.

11fr

Horizonte Dividido
El horizonte dividido no permite que una actualización de enrutamiento recibida por una interfaz sea reenviada por la misma interfaz.

12fr Detrás de R1, R2 y R3 existen redes LAN que deben comunicarse, R2 recibe las rutas de las redes LAN de R1 y de R3 pero no puede reenviarlas debido a que la esta recibiendo la actualización por una única interfaz física. Es decir R3 no puede ver la red LAN de R1 y viceversa.
Una solución es crear otro CV con otros DLCI, generando un broadcast de actualización de enrutamiento que consumen ancho de banda y la otra solución es crear Interfaces Virtuales para que las rutas sean enviadas por interfaces virtuales distintas.

13fr

Y ya para terminar y para comenzar con el video tutorial, algunas terminologías que debemos tener en cuenta cuando arrendamos un servicio Frame Relay.

Velocidad de Acceso: Velocidad del medio fisico que se conecta desde nuestro DTE hasta el Switch Frame Relay, estamos hablando del bucle local.
Velocidad de Información Suscrita: Velocidad que hemos negociado y pactado con el ISP.

14frEntonces cuando arrendamos una línea Frame Relay pagamos por tres cosas:

-          Línea de acceso: Línea física
-          Los circuitos virtuales configurados
-          El CIR que estamos requiriendo.

Una ventaja de Frame Relay es que la capacidad total de la red que no se usa se puede compartir entre todos los clientes a través de RAFAGAS.

Las Rafagas
Las rafagas permite que se usen temporalmente el ancho de banda adicional (que no se esta usando)  en otras conexiones que la necesitan.
Aquí tambien debemos aprender algunos otros terminos:

CBIR: Velocidad de información de rafaga suscrita.
Es la velocidad negociada superior a la CIR, es decir nuestro CIR puede ser de 32 kbps pero nuestro CBIR negociado es de 48 kbps podemos transmitir a esa velocidad en ciertos momentos.

BE: Rafaga Excesiva
Es el termino usado para el ancho de banda disponible por encima de la CBIR hasta llegar a la velocidad total del enlace.

15fr

Las tramas enviadas por encima del CIR son marcadas como DE (elegibles para descarte).

16fr

Control de Flujo Frame Relay
Frame Relay no utiliza un control de flujo explícitamente hablando, lo que utiliza es un mecanismo de congestion notificación.

Recordemos otra vez la trama Frame Relay.

7fr

Los bits: FECN, BECN Y DE se encargan del control de flujo.
La logica es la siguiente:

-          Cuando una trama se envia por debajo del CIR, se envia sin problemas.
-          Si pase el CIR, utilizando el CBIR se marca como DE (elegigle para descarte)
-          Si excede el CBIR se descarta.

Frame Relay ademas usa un mecanismo de encolamiento en buffer, es ahí donde hace uso de los FECN (notificación explicita de congestion hacia delante) y BECN (notificación explicita de congestion hacia atrás).

17fr

Las tramas que llegan al Switch Frame se ponen en cola debido a que hay un exceso de Flujo y notifica a los DTE de los extremos con FECN y BECN.

Popularity: 11% [?]

Cuando mi pasión e inquietud por la redes empezaba a despertar (cuando tenia 15 años y estaba en el colegio tratando de aprobar esos cursos que hasta ahora no se porque estudie)  recuerdo haber leído el termino: “Frame Relay”. ¿Frame Relay? ¿Y eso como se come? Estaba claro que no sabia que era esa bendita palabra y para ser sincero los conceptos abstractos que se colocan en la Web no me ayudaron mucho.
Siempre me ha incomodado las personas que convierten un tema complejo en algo muchísimo mas complejo, con el fin de creer saberlo todo y acaparar la atención (ese tipo de gente abunda).
Hoy hablaremos de Frame Relay,  para entenderlo de manera sencilla y haremos un video tutorial con un par de ejercicios prácticos.

¿Qué es Frame Relay?

Es un protocolo WAN que permite hacer uso de una conexión WAN privada. Es decir…. Imaginemos que una empresa desea unir sus sucursales entre Lima y Pucallpa y desea que la conexión sea privada (que sus datos no pasen por la red pública de Internet), entonces tiene 2 opciones:

-          Conexión Dedicada: Líneas Arrendadas

-          Conexión Conmutada

  • Por Circuitos: ISDN (ya casi ni existen)
  • Por paquetes: Frame Relay

Ventajas de Frame Relay

-          Es obvio que una conexión dedicada demanda mucho más dinero

-          Frame Relay es más flexible

-          Frame Relay da un mayor ancho de banda, mejor fiabilidad y mejor resistencia a fallas que las líneas privadas

1fr

Creo que hasta aquí va todo, claro ¿verdad? Sigamos……..

¿Cómo es una Red Frame Relay?

Pues una Red Frame Relay no es muy complicada de aprender, en el cliente (la empresa que se contacta con un ISP) cuenta con un DTE en los extremos de la conexión, 2 routers, que se conecta al Switch Frame Relay que es administrado por el ISP.

2fr

Nota: La conexión entre el router del cliente y el Switch Frame Relay del ISP, se llama Bucle Local.

Los Circuitos Virtuales

Sigamos analizando la imagen superior, cuando dos ruteadores se conectan en una red Frame Relay forman CIRCUITOS VIRTUALES (VC). Con los VC podemos compartir el ancho de banda entre usuarios y varios sitios se pueden comunicar con otro sin usar líneas dedicadas.

Entonces…. volvamos a un ejemplo práctico y miremos la siguiente imagen:

3fr
El router de la parte inferior tiene que enviar un archivo al router de la parte superior y obviamente debe de pasar por la Red Frame Relay, ¿Cómo sabe que camino seguir? ¿Cuál es su circuito virtual? ¿Por qué Switchs Frame Relay debe pasar?
Es aquí donde surge otro término, los DLCI, estos son manejados y asignados por el ISP y solo tienen importancia local debido a que podría haber otros DLCI en otros enlaces, debemos de tener en cuenta que no son como las direcciones IPs.

Nota: El termino importancia local quiere decir que un mismo DLCI puede ser usado para otro circuito virtual.

Por ejemplo el router inferior cuyo DLCI es 102, podría usar el mismo DLCI para conectarse al router superior cuyo DLCI es 201 o al router cuyo DLCI 319.

4

Circuitos Virtuales Múltiples

Aprovechando que acabamos de tocar el tema de conexión múltiple con un único DLCI, hablemos de una de las propiedades importantes de Frame Relay, los circuitos virtuales múltiples.Frame Relay multiplexa estadísticamente, es decir que Frame Relay transmite solo una trama por vez pero por una única conexión física pueden coexistir muchas conexiones lógicas identificadas por el DLCI.

5

Nota: Aquí también podemos ver la ventaja económica de Frame Relay frente a las líneas dedicadas, en una línea dedicada deberíamos implementar nuevas conexiones físicas si quisiéramos establecer una nueva conexión en cambio con Frame Relay podemos usar un único enlace físico manejando distintos DLCI.

¡Listo! Con esto ya sabemos que es Frame Relay y como funciona (de manera general obviamente), lo que sigue es la parte interna de Frame Relay y que también vamos a tocar.

Popularity: 4% [?]

En ItacurucaDebo de reconocer que este año, el 2008, ha sido un buen año en lo personal, académico y profesional.

Un año que fue el éxodo de mi carrera universitaria, donde puse fin a 10 ciclos, 60 cursos y 4 años y medio de esfuerzo (sin nunca haber jalado un curso), que debo reconocer están dando sus frutos.

Un año donde he consolidado la escritura de este pequeño blog, aclarando que hubo momentos abrumantes donde tenia que ir al trabajo, universidad y enfrentar trabajos y exámenes finales, donde obviamente mi vista y dedos fueron victimas del cansancio y no pudieron escribir ni un solo post, sin embargo al final de este periodo retome mi blog.

En lo profesional sigo trabajando en el International Potato Center (CIP) y sigo administrando servidores Linux, aun recuerdo cuando llegue la primera vez al CIP jamás hubiera pensado quedarme todo este tiempo (ya me voy por los 2 años), debo reconocer que estoy muy feliz de trabajar en el CIP (no se si todos puedan decir lo mismo con el mismo entusiasmo que yo), mi trabajo no solo me ha ayudado a crecer profesionalmente sino que también me ha dado la oportunidad de viajar a Brasil al 2nd EELA GRID SCHOOL y conocer las riquezas de otros países.

Para terminar y no aburrirlos debo mencionar también que académicamente sigo capacitándome estudiando para mi certificación CCNA y estudiando ingles, espero este año además poder certificarme en LPI y ser un pingüino “maduron”.

Aquí comparto algunas fotos de mi viaje a Brasil y una exposición que hice también este año en la Universidad Nacional de Ingeniería para FLISOL.

 

FLISOL 2008 – UNI

Popularity: 2% [?]