jueves, 28 de mayo de 2009

Security A(r)t Work

Inicio esta sección de referentes en el ámbito de la PSI, incluyendo los que, por un motivo u otro, me hayan llamado la atención. Security A(r)t Work es una "delicia" en el campo, con una visión y una forma de "plasmar" los contenidos muy de agradecer.

martes, 26 de mayo de 2009

Bitácora de PSI.: Una de cuotas

En el capítulo anterior hemos hablado, entre otras cosas, de los sistemas de ficheros. Hoy trataremos de poner algunas barreras al campo en la forma de cuotas.

Es necesario definir cuotas en nuestros sistemas de ficheros, tanto locales como en red, especialmente en entornos multiusuario. Bueno, si tu máquina únicamente te tiene a ti por usuario, no será tan crítica esta tarea, aunque ...

Nuestro espacio de almacenamiento no suele ser infinito, por lo que será necesario limitar su uso. No es bueno dejar llenar nuestros discos duros. Como mínimo poner cuotas al número de bloques e inodes por usuario y, o, grupo. De forma resumida para vuestras máquinas de laboratorio podéis utilizar este mini-howto "Debian Disk Quota Management". Para asignar cuotas podrás utilizar el quotatool o el edquota. Normalmente se definen varias cuotas tipo a usuarios que se utilizan para asignar a otros usuarios:

$ sudo edquota -p ...

# for i in `cat /etc/passwd [pipe] cut -f1 -d:`; do edquota -p $i; done

Este último comando asignará cuota a todo usuario del /etc/passwd, incluido root, admin, etc. Si quieres asignárselo a un grupo determinado, según el caso, puedes utilizar algún pequeño "script" o comando para seleccionar los usuarios afectados.

En este punto, utilizamos unas viejas conocidas en el mundo de los procesos, las llamadas "fork bombs", que sirve para ilustrar la necesidad de configurar otro tipo de cuotas, como las de procesos. Es bastante habitual encontrarnos en la actualidad máquinas multiusuario con cuotas de disco, pero no de procesos. Tal vez la más conocida, publicada y comentada de las "fork bombs" sea :(){ :[pipe]:& };:

De forma resumida, abre un terminal como usuario y ejecuta dicha cadena. En el caso de que el sistema no tenga cuotas de proceso, se comerá el procesador de la máquina y la dejará tirada. Esta cadena es una función llamada : que se auto-llama de forma recursiva dos veces y que se vuelven a llamar, como diría el inminente Buzz Light Year, "hasta el infinito y más allá". Esta función se puede reescribir de la siguiente forma para una mejor comprensión:

mifuncion(){ mifuncion[pipe]mifuncion& };mifuncion

Para microsoft en un cmd si se ejecutas un fichero por lotes mifuncion.bat cuyo contenido sea %0[pipe]%0 el efecto será el mismo. Existen otras muchas fork bombs, pero que no tienen ningún interés más que el de ilustrar la necesidad de definir cuotas en los distintos subsistemas gestionados por nuestros sistemas operativos. Aunque aquí veremos cuotas para el sistema de ficheros y procesos, recuerda que también tenemos otros recursos que pueden requerir de cuotas, como por ejemplo nuestros interfaces de red (por IP, servicios, etc.), para evitar posibles abusos (traffic shapping y QoS).

En el caso de cuotas de proceso, en los equipos del laboratorio (debian) tienes el fichero de configuración de linux-pam /etc/security/limits.conf. En el que podrás definir cuotas para distintos elementos, por ejemplo.:

@colegas hard nproc 100
@enemigos hard nproc 10

La primera línea definiría un límite "hard" de número de procesos a los usuarios del grupo colegas de 60 y, en la segunda, de 10 para los enemigos.

* hard nproc 60

Esta línea establecerá un límite de procesos de 60 para todo bicho que pulule en el equipo, a excepción del root. No olvides que un proceso puede generar un gran número de procesos. Analizar el perfil de los procesos de tus usuarios y sus necesidades te permitirá definir la política de asignación de cuotas. Bajo ningún concepto debemos considerar la típica coña de "usuario bueno, usuario muerto". Nosotros trabajamos para ellos y, sin ellos, nuestro trabajo no tendría sentido.

Y, es suficiente con las cuotas que hemos visto?. En el caso del fichero /etc/security/limits.conf podrás definir, al igual que se hace con nproc, límites para otros parámetros (fuente fichero de configuración de las debian de laboratorio).:

core limits the core file size (KB)
data max data size (KB)
fsize maximum filesize (KB)
memlock max locked-in-memory address space (KB)
nofile max number of open files
rss max resident set size (KB)
stack max stack size (KB)
cpu max CPU time (MIN)
as address space limit
maxlogins max number of logins for this user
maxsyslogins max number of logins on the system
priority the priority to run user process with
locks max number of file locks the user can hold
sigpending max number of pending signals
msgqueue max memory used by POSIX message queues (bytes)
nice max nice priority allowed to raise to
rtprio max realtime priority

Otros muchos parámetros configurables del sistema los encontrarás en /etc/login.defs y /etc/pam.d/common-password

password required pam_unix.so nullok obscure min=4 max=8 md5

¿Qué opinas de la línea anteriore que puedes localizar en los ficheros common-password de las máquinas de laboratorio?. ¿Qué opinas del uso de password md5 de longitud mínimo 4?. ¿Debemos enviar al md5 a hacerle compañía al crypt?. De momento no, pero requiere unos ciertos cuidados, que recuerdan a los últimos días del crypt.

Para que puedas dedicar un poco de tiempo a probar alguna herramienta, señalar dos dedicadas a la reproducción de ataques por fuerza bruta sobre una gran cantidad de servicios, Medusa y THC Hydra. Sin entrar en IDSs de propósito general, existen herramientas para su detección y filtrado, como fail2ban, denyhosts, blocksshd o sshdfilter. Su funcionamiento se centra en la identificación en los ficheros de "log" de ataques por fuerza bruta desde determinadas IPs para su filtrado normalmente mediante iptables. Será necesario incluir excepciones, para no filtrar lo que no se debe, y tener en cuenta la posibilidad de paquetes IP spoofing que nos puedan producir el filtrado de equipos confiables.

Y la pregunta que está en el aire, ¿no vas a dar más niveles RAID?. Hemos llegado hasta aquí hablando de sistemas de ficheros y RAIDs, y no hemos terminado nuestra aventura. Es hora de cerrarla, y descubrir al asesino.

Se analiza el funcionamiento de los RAID3 y 4, de los que no incluyo en esta entrada nada, al no ser de gran interés para nosotros. El RAID5, uno de nuestros clásicos, ilustra la utilización de información de paridad distribuida entre un grupo de discos para garantizar la recuperación ante el "casque" de un disco duro. El RAID5 incrementa el rendimiento respecto al 3 y 4, evitando el cuello de botella de tener toda la paridad en un único disco duro.

Desde un punto de vista operativo, la mayoría de los RAID que montamos son 0, 1 y 5. Existen otros muchos RAID, pero no son de este mundo -:). Recuerda que los discos duros se pueden llenar (el próximo día de clase hablaremos de LVM), se pueden estropear, te los pueden robar. RAID puede proporcionar un cierto nivel de seguridad, pero no funciona ante un borrado accidental de ficheros, no sustituye al backup, no protege de incendios, inundaciones, etc. También puedes plantear hacer RAID sobre discos remotos, por ejemplo con Fibre Channel.

En algunas ocasiones los RAID se van de fiesta y se montan RAID10 (grupos de "mirrors" "stripeados") o RAID01 (grupos de "stripeados" "mirroreados") [estos últimos términos son el resultado de un proceso de fusión, mis disculpas a la RAE].

Aunque los RAID pueden incrementar el rendimiento también puedes plantear el uso de distintos planificadores de entrada salida a disco o ajustar algunos de sus parámetros. Sin duda alguna, el "tunning" es un deporte maravillo que, por desgracia, se practica poco.

Recuerda que la partición de swap puede darle mucho trabajo a tu disco. No te olvides dimensionar al swap adecuadamente, y meterlo en un disco rápido. También puedes crear varias particiones de swap y distribuirlas entre varios discos, asignándoles prioridades. De esta forma, tu swap podrá irse de vacaciones a varios discos, y utilizar eso que se llama acceso concurrente.

Otra instalación que puede sernos de interés es hacer "mirroring" del sistema operativo. Y finalmente, para que puedas crear, monitorizar y hacer todo tipo de pruebas con los RAID en los equipos del laboratorio, el mdadm.

Avaliación

Información y cartel remitido por el Rectorado.
-----------------
PROFESORADO DA UDC

Achégase o cartel anunciador da Avaliación Docente, para que poida darlle publicidade entre o seu alumnado colocándoo na aula, na porta do seu despacho, ou onde estime conveniente.

Grazas pola súa colaboración
Saúdos cordiais
avaliemos at udc.es

domingo, 24 de mayo de 2009

Reporte de errores.: Código Técnico de la Edificación (CTE)

Adjunto reporte literal de errores respecto a la entrada "Sector Inmobiliario TIC". Revisaré las modificaciones y todo el CTE para hacer un upgrade de mi cabeza.
-------------------------
"La norma NBE-CT79 se encuentra actualmente derogada, viniendo a ser sustituida por el documento básico DB-HE: Ahorro de energía y la norma CPI-96 por el documento DB-SI: Seguridad en caso de incendio. Todos ellos forman parte del nuevo Código Técnico de la Edificación, conocido por CTE que vienen a sustituir a las antiguas Normas Básicas de la Edificación. Han ido entrando en vigor de forma escalonada y de algunos de ellos ya han ido saliendo modificaciones.

Este es el enlace desde donde se pueden descargar.: http://www.codigotecnico.org/index.php?id=33

Hacer hincapié que este código es una norma prestacional y no prescriptiva como venían siendo las anteriores."
--------------------------
Gracias Estefanía por el reporte de errores, y especialmente al amigo que te hizo el reporte. Le puedes decir que no se corte en remitirme directamente cualquier error, modificación o sugerencia sobre los temas tratados, u otros que puedan ser de intrerés. Que siempre serán muy bienvenidos. Se han hecho las oportunas modificaciones en la entrada de referencia.

Otro enlace de interés.: http://www.ffii.nova.es/puntoinfomcyt/Formulario-Lseg01.asp

sábado, 23 de mayo de 2009

Bitácora de PSI.: Vida salvaje (la redundancia)

Seguridad y redundancia, dos términos íntimamente ligados. Al igual que la "hydra" de la fotografía, la redundancia a distintos niveles nos podrá proporcionar, entre otros, sistemas tolerantes a fallos, alta disponibilidad, computación distribuida y balanceo de carga. En este punto deberemos tener presente la organización "hardware" de nuestros sistemas que, en muchas ocasiones, pasará por la instalación de "clusters" y "blades" (los tipos de enlaces de ambos son autoexplicativos, y recuerda que en algunas ocasiones puede ser aconsejable "casarte" con alguna empresa y cubrirte la espalda con algún tipo de soporte). Tampoco debemos olvidarnos del mundo de la computación GRID. Además, la virtualización y paravirtualización de nuestros sistemas proporciona, entreo otras muchas ventajas, una gran flexibilidad, sin entrar en los posibles problemas de seguridad añadidos a este tipo de aproximaciones y a sus hypervisores.

Todo en la naturaleza utiliza la redundancia como mecanismo de protección-supervivencia. Muchas especies tienen docenas, cientos o incluso miles de crías. Como es lógico, este parámetro está relacionado con su índice de supervivencia. En resumen, se busca perpetuar la especie garantizando la supervivencia de un determinado número de individuos, al igual que nosotros buscamos garantizar la supervivencia de nuestros sistemas y servicios. Si tomamos un único individuo, la redundancia está presente en nuestro sistema de visión y auditivo, más que nada para poder disfrutar del estéreo de los sentidos, dos pulmones, dos riñones, ..., y un corazón (en este último caso más bien por un problema de consumo, de energía). Siempre hay elementos que saldría demasiado caro redundarlos.

La genética y la evolución siempre está presente en nuestros sistemas. La capacidad de adaptarnos a situaciones cambiantes es un cualidad muy deseable. Si estás interesado en estos temas te recomiendo alguno de los proyectos fin de carrera que propuse y dirigí cuando era joven, y que sobre los distintos subsistemas gestionados por nuestros sistemas operativos, se desarrolló todo un conjunto de algoritmos genéticos para proporcionar un sistema automático de ajustre de nuestros sistemas, facilitando su adaptación a distintos entornos, tanto "hard" como de aplicativo. Un ejemplar de cada uno de ellos está disponible en la biblioteca de la FI de la UDC. La monitorización y ajuste de nuestros sistemas es una tarea compleja. Por lo tanto, todo sistema automático que mejore el rendimientos de nuestos operativos, constituira un primer paso para hacer a nuestros sistemas operativos un poco más listos.

Si pensamos en nuestra infraestructura, encontramos redundancia a todos los niveles.

- Tal vez nuestras redes de comunicaciones constituyen el elemento más importante a la hora de pensar en redundancia. Si las redes fallan, todo falla. Debemos tener en cuenta tanto líneas redundantes como activos redundantes. Los caminos que nos unen son múltiples, variados y multitecnología. Hay bits que vuelan, otros navegan y, los que más me gustan a mí, hacen espeleología. Y recuerda, tal y como hemos visto en aventuras anteriores, que existen otros muchos mundos, otras muchas redes.: de suministro eléctrico, de alimentación ininterrumpida, de agua, de gases, de puesta a tierra, etc.

- CPDs redundantes o, como mínimo, la parte más importante, el almacenamiento. Un servidor se puede sustituir (es cuestión de €s), la pérdida total de los datos y de todo soporte disponible puede no serlo. ¿Qué hubiese pasado si nuestra empresa y todos sus sistemas hubiese estado en las torres gemelas o en la torre windsor? (bueno, sin contar con disponer de "backups" de todo en la caja innifuga de la windsor). Además, este nivel de redundancia nos permitirá jugar con distintos esquemas de alta disponibilidad y balanceo de carga, etc., sobre infraestructura en distintos edificios. Recuerda que muchas de estas tareas podrás delegarlas en equipamiento "hardware" especializada, como puedan ser los balanceadores de carga, aceleradores SSL, etc. Aunque en clase referencié algunos de estos dispositivos, no los incluyo aquí por no hacer publicidad. Si algún proveedor de este tipo de sistemas llega a esta entrada y está interesado en presentar alguno de sus "cacharros" a un grupo de unos 60 futuros profesionales, que no dude en contactar. Por favor, abstenerse comerciales.

Observación para los alumnos.: Es habitual encontrar comerciales que siempre tienen una respuesta afirmativa a cualquier cuestión técnica del tipo si se puede hacer tal o cual cosa que, a posteriori, se vuelve prácticamente inviable. Cuando te entrevistes con comerciales, procura documentarte bien sobre el tema a tratar y, de ser posible, ponle algún examen sobre cuestiones que tengas claras y sean poco viables para ver su grado de fiabilidad. Y recuerda que no encontrarás un buen comercial que antes no haya sido buen técnico. Esto mismo se puede aplicar a los directivos y gestores de personal. Vivimos en un mundo en el que con cierta frecuencia se trata de "vender la moto", aunque "menos mal que nos queda Portugal".

- Backups redundantes. Son demasiadas las veces que asistimos a situaciones en las que en el momento de necesitar un "backup", no está en las condiciones que debería, o con la política adecuada a nuestras necesidades. Una buena política de "backups" nos dejará dormir más tranquilos por la noche. Tampoco es aceptable entrar en un CPD y encontrar DLTs de "backup" zapateados por las mesas.

Sobre "backups", haciendo memoria de los tiempos en los que ejercía la segunda profesión más antigua del mundo, al inicio de los noventa utilizaba el tar sobre cintas de 150 Mb. Todo estaba planificado y organizado pero, la primera vez que necesité recuperar algo, mi dispositivo me recibió con un checksum error. Que hijo de puta, con perdón, pensé yo. En esas fechas descubrí que habría ciertas tareas que se debían hacer en single user, o buscar una utilidad un poco más evolucionada e inteligente que un simple tar. Pero bueno, con un poco de imaginación al final se pudo hacer la recuperación. Pasaron unos años y las unidades de cinta de 4mm. llegaron a poblar nuestras mesas (ellas nunca lo harían, no las dejes abandonados encima de la mesa). Ahora pensábamos en Gb, en lugar de Mb., y la compresión de la información entró en nuestras vidas. Era habitual encontrar "backups" sobre cpio, dump-restore, afio, etc. También empezamos a exportar disco en red y a hacer "backups" a disco, mucho más rápido. Finalmente, antes de dejar de ejercer esta gratificante profesión, se instaló un sistema de "backup" en red, un IBM server con el software de "backup" TSM, Tivoli para los amigos, con un primer nivel de "backup" a disco, en el que predominaba como mecanismo de seguridad el RAID5, y un segundo nivel de transferencia a un dispositivo de LTOs. Sin duda alguna las posibilidades de planificación de "backups" en este tipo de sistemas permiten una flexibilidad más que suficiente para atender las peculiaridades de todo tipo de entornos, sistemas y usuarios.

- No quiero dejar fuera de esta sección otro elemento importante a redundar, al menos parcialmente, se trata del personal. Es habitual encontrarnos profesionales que utilizan todo tipo de estrategias para garantizar, muchas veces en un proceso oscurantista, que todo está bajo su único control. No es un delito, pero toda organización deberá tratar de redundar, en la medida de lo posible, total o parcialmente según sea el entorno de trabajo, las atribuciones más críticas del personal técnico. Como decía y dice Rosendo, "esto es la fauna, chaval". Pero también puedes encontrarte el típico centro con buenos profesionales, que planifican todo el trabajo, las migraciones, etc., etc. En estos casos los servicios proporcionados y el trabajo desarrollado pueden llegar a pasar desapercibido para los usuarios y, o, directivos. En algunas situaciones se puede llegar a pensar que sobra personal o que parte del mismo se puede derivar a otras tareas. En el lado opuesto esta el entorno de trabajo que no planifica o hace mal los desarrollos. Se puede llegar a dar la situación que cada cierto tiempo el usuario se percata de problemas en el servicio, así como los directivos, y de la gran labor que desarrolla ese personal técnico y la enorme necesidad de contratar nuevo personal para que todo funcione bien. En estos casos siempre suele aparecer el "técnico" salvador que, después de generar grandes problemas, los soluciona para aplauso de todos los que asisten al circo. Obviamente, contratar nuevo personal no suele solucionar el problema. Pero bueno, siempre queda la opción de coger a los mejores técnicos y aplicar la redundancia por medio de la clonación. Esto último no es posible, pero identificar el trabajo bien hecho debe ser una de las principales tareas de cualquier directivo. Obviamente, será difícil, por no decir imposible, que un directivo pueda llegar a desarrollar bien su trabajo, si antes no ha sido un buen técnico, o al menos aceptable. Como consejo, no tengas prisa por llegar a la cima de la montaña, disfruta de la ascensión. Y recuerda que la cima no es el paraíso.

Finalizamos la clase con un clásico de la redundancia en almacenamiento, los sisetmas RAID (Redundant Array of Inexpensive Disks). En este punto se incluyen conceptos como "hot swap", cabinas de disco, SCSI (Small Computer System Interface), SATA, "Fibre Channel", SAN (Storage Area Networks), "fabric director", etc.

Se analizan los niveles RAID básicos.:

- Lineal (muy bonito en la teoría, pero no sirve para nada)

- 0 "stipping" (utiliza n discos con almacenamiento en paralelo sobre los mismos). Un fichero se almacena en varios discos duros. Este nivel busca un incremento en el rendimiento de la I-O a disco, sin aportar redundancia-seguridad en el almacenamiento. Habitual encontrarlo en sistemas de edición de vídeo (el "rendering" suele comer todo rendimiento a disco que le podamos proporcionar), cálculo científico intensivo (modelos climáticos, biología molecular, etc.) y, en general, en todo entorno que mueva grandes cantidades de datos con nuestros discos. A nivel operativo, señalar que podemos hacer RAIDs de particiones o particiones de RAIDs. Es habitual que, con el tiempo, se tengan que adquirir nuevos discos duros y, por lo tanto, convivan distintos tipos de discos. Una buena organización mejorará los rendimientos o, al menos, no los empeorará. ¿qué pasaría si en un RAID 0 o 1 algunos discos duros fuesen más lentos que otros?

- 1 (mirror). En este nivel existe una redundancia total del almacenamiento, garantizando la disponibilidad del sistema ante casques de dispositivos. Obviamente, todo tiene un coste, y este caso requerirá una doble inversión. Recuerda que si únicamente dispones de una controladora de discos, podrás estar protegido ante la "muerte" de discos, pero no de controladora. Redundar las controladoras y organizar los discos adecuadamente te proporcionará otro nivel de seguridad.

En este punto, antes de continuar con los RAID, se analiza el proceso de "bautizo" de un disco duro. Un disco duro no se puede montar según te llega de fábrica, hay que bautizarlo (particionarlo y generar el sistema de ficheros). Aunque los discos duros virtuales de nuestro laboratorio no se puedan tocar, al ser ficheros, requieren seguir el mismo proceso. No puedo tratar de montar un disco duro que no ha sido particionado, ni generado su sistema de ficheros. El fdisk y el mkfs te podrán solucionar dicha tarea. El fichero /etc/fstab será el encargado de definir la información de montado. En clase se analiza el formato del /etc/fstab y las opciones que podemos encontrarnos. No incluyo en esta entrada nada al respecto, al estar ampliamente publicado en diversas fuentes. También analizamos el conjunto de ficheros y directorios que nos podemos encontrar en el, como dice la literatura, "pseudo" sistema de ficheros /proc.

Concluimos la clase con una cuestión, ¿qué sistemas de ficheros utilizaremos?. La respuesta no es cualquiera, o el reiserfs o ext3 que es el que suelo encontrarme. Si dentro del comando fdisk selecionas la opción l verás varias decenas de sistemas de ficheros distintos. Entonces, para que tantos?. Pues bien, los sistemas de ficheros son como el vino, los hay buenos y malos, unos aconsejables para ciertas comidas y otros para otras. A nadie se le ocurre tratar de meter un fichero de 4 GB en un disco FAT. Por lo tanto, deberemos tener en cuenta factores como los discos duros y buses disponibles, tamaño de los ficheros y directorios, números de lecturas y escrituras, patrón de los accesos a disco y carga de trabajo, algoritmos o planificadores disponibles, gestión de bloqueos, estrategias de reconstrucción ante "casques", etc. Dejamos el tema aquí exponiendo dos posibles configuraciones de un mismo servicio, el de correo electrónico que, según utilicemos "mbox format" o "maildir format" las implicaciones en cuanto al sistema de ficheros serán radicalmente opuestas.

Para terminar, hablando de rendimimiento y seguridad en el almacenamiento, un curioso video de rendimiento con SSDs (fuente Tomás, gracias). Además, no debemos olvidarnos que el cifrado de los sistemas de ficheros tienen su implicación en el rendimiento.

next gen discs

De los muchos emails que me llegan con noticias de nuestro mundillo, algunas de las cuales están relacionadas con los temas tratados en clase, son varias las que merecen nuestra atención, aunque no me queda otra que hacer una selección. Adjunto contenido email remitido por F.A.R.M.
-------------
Encontré un artículo que es relevante de acuerdo al tema que diste en clases pasadas sobre almacenamiento y respaldo de información. Unos investigadores han logrado crear una especie de disco compacto capaz de almacenar el equivalente a 2,000 DVD’s utilizando una tecnología de 5 dimensiones (3 espaciales y dos extras: espectral y polaridad). Esperan que una aplicación comercial llegue en 5-10 años, y podría marcar una nueva manera de guardar respaldos de nuestra información. Enlace de la noticia aquí.
----------------
Sobre el tema, los interesados en otros trabajos relacionados con dispositivos de almacenamiento de alta capacidad, señalar por ejemplo los diferentes desarrollos en sistemas holográficos. Para más información Holography System Development Forum (HSDF).

Pdt.: Sin duda alguna los futuros y cada vez más cercanos procesadores de varias decenas de núcleos requerirán de nuevos planteamientos jerárquicos de almacenamiento, empezando por las caches y terminando por los discos.

miércoles, 20 de mayo de 2009

What's the Next Web Stack?

Revisando el documento "Sun cloud-computing technology scales your infrastructure to take advantage of new business opportunities" de Sun microsystems, entre las aportaciones identificadas, incluyo en esta entrada la titulada "What's the Next Web Stack?. Sin duda alguna, todo estudiante en tecnologías debe moverse en la dirección que marca el mercado que, a fin de cuestas, es el que define las oportunidades laborales. En resumen, en dicho documento figura la siguiente "evolución", o más bien "mutación".:

Año estelar 1998.: Netscape - BEA/SAP - Oracle
Año estelar 2008.: Apache - PHP/Perl/Python - MySQL
Año estelar ????.: lighttpd - Hadoop - MogileFS

Señalar que la nueva tripleta está pensada para computación y almacenamiento distribuido que, en muchos casos, incluye virtualización a distintos niveles. En los últimos años se está poniendo de moda la comida "light" que, por cierto, tiene muchas ventajas, pero también alguna desventaja. Pensando en el tema que estamos dando en clase esta semana destacar MogileFS, y lo que parece ser aporta una gran cantidad de ventajas. Lo pondré en la cola de las muchas cosas que quiero probar, que por cierto, empieza a ser demasiado grande.

Sobre "cloud computing" recomiendo una pequeña visita a las soluciones y tecnologías aportadas por Enomaly, Elastra (muy interesante el documento Elastic Computing y sus aportaciones sobre "next generation of IT infraestructure?"), Right Scale, 3Tera, Joyent, Mosso, Sun Microsystems & Amazon web services. En esta relación encontrarás diversas soluciones, herramientas y tecnologías de "cloud computing", alguna de ellas disponible en versión "free" para descargar, así como servicios de "cloud hosting".

Ser bueno, y bajaros de la nube, o tal vez subiros,

Observaciones.: Las cuestiones tratadas en esta entrada se salen de la temática-temario de la asignatura de PSI. De todas formas, creo que tiene la suficiente importancia como para dedicarle unos minutos. Sin duda alguna, es importante saber "a dondeeee vaaaamos".

martes, 19 de mayo de 2009

Financial Cryptography and Data Security '10 (January 25-28, 2010 - Tenerife. ES)

Financial Cryptography and Data Security is a major international forum for research, advanced development, education, exploration, and debate regarding information assurance, with a specific focus on commercial contexts. The conference covers all aspects of securing transactions and systems.

Info.: http://fc10.ifca.ai/

Bitácora de PSI.: Sector inmobiliario TIC

Todo "profesional" tiene un pasado. Las decisiones tomadas son las que definirán las características presentes de un profesional, así como la capacidad para adaptarse a un entorno muy cambiante que requiere en todo momento tomar decisiones, que podrán ser más o menos acertadas. Todo requiere tiempo, y lo que nace mal, muere peor. Como dice el refrán "el que siembra espinas que no espere cosechar flores", aunque yo tengo uno propio "el que plante conocimientos, no sé lo que recogerá, pero al menos tendrá bien amueblada la cabeza".

Entrando en materia, hoy hemos seguido "peleando" con las prácticas de laboratorio. Como es típico de nuestra profesión, nada es lo que parece, y tenemos que adaptarnos a los imprevistos.

En nuestra clase de teoría hemos seguido hablando de UPSs. Se ha planteado un ejemplo de equipamiento, analizado su consumo, planificado el crecimiento a corto-medio plazo y definido las características de una SAI para dicho caso. Los sistemas de UPS deben ser gestionados y monitorizados adecuadamente, tanto en sistemas centralizados como distribuidos. Distinguimos varios sistemas de gestión.:

a) nada, que el usuario llame por teléfono cuando las máquinas se vengan abajo. Sin duda alguna el elegido por un buen profesional -:)
b) UPSs con interface serie y software de gestión. Aceptable en la pequeña empresa.
c) UPS con conexión a red IP, y normalmente con SNMP para integrar en el sistema de gestión. Recomendable para empresas grandes. En este caso no te olvides de conectar los activos de red a la UPS -:) y protegerlas adecuadamente.

Como ejemplo de sistema para monitorizar y gestionar una UPS y los equipos conectados a la misma, se dispone de varias herramientas, como NUT (Network UPS Tools).

También hemos visto las Normas de Estabilidad Eléctrica, en la forma del correspondiente Reglamento Electrotécnico de Baja Tensión (RBT), así como la directiva y la orden CTE de Compatibilidad Electromagnética. En pocas palabras y de forma muy resumida, no se puede mezclar el vino con el agua. No puedo meter el cableado de fibra por los huecos del ascensor. No puedo meter líneas de datos junto a cableado de alta tensión, etc., etc. Todo esto incluye distancias entre los elementos, aislantes, etc.

Una parte importante de la clase la hemos dedicado a una red que suele pasar desapercibida en nuestros edificios de TIC respecto a las de datos, etc. Es la Red de Toma de Tierra. En primer lugar se presentan algunas normas de referencia, como la EN50310:2009 o la J-STD-607-A "the purpose of this standard is to enable the planning, design, and installation of telecommunications grounding and bonding systems within a building with or without prior knowledge of the telecommunications systems that will subsequently be installed. This standard also provides recommendations for grounding and bonding of customer owned towers and antennas. This telecommunications grounding and bonding infrastructure supports a multivendor, multiproduct environment as well as various system installation practices". Se analizan los distintos elementos que constituyen una Red Radial de Tierra y sus características básicas.


El acondicionamiento térmico de las instalaciones estár recogido dentro del artículo 15, del Código Técnico de la Edificación (CTE), sobre exigencias básicas de aHorro de Energía (HE), respecto a la limitación de la demanda energética, rendimiento de las instalaciones térmicas, etc. A nuestros "cacharros" les suele gustar vivir en climas más bien fresquitos -:). Nuestros "cacharros" consumen mucha energía, por lo que el desarrollo de eco-CPDs deberá empezarse a considerar como un parámetro importante en su diseño y desarrollo. Hasta la fecha únicamente tengo constancia de desarrollos de ecoCPDs de Sun Microsystems.

También hemos hablado de pirómanos. En cuanto a la seguridad ante incendios, el CTE dispone el Documento Básico (DB), sobre exigencias básicas de Seguridad en caso de Incendio (SI), respecto a la propagación interior y exterior, evacuación, instalaciones de protección contra incendios, intervención de bomberos y resistencia estructural al incendio (nuestro agradecimiento al amigo de Estefanía por las correcciones, no hay como disfrutar de un domingo con la lectura de un BOE -:))

Enlace de interés.: http://www.ffii.nova.es/puntoinfomcyt/Formulario-Lseg01.asp

Este punto me ha permitido introducir la próxima temática, el uso de redundancia como mecanismo de protección. En la actualidad es necesario el contemplar en nuestros CPDs la posibilidad de desastres, como los incendios, atentados, etc. (obviamente según el tipo y tamaño de la empresa). Estos temas se tratarán más adelante, en el contexto de la llamada Alta Disponibilidad y Sistemas Tolerantes a Fallos. En estos casos, la única solución pasa por la redundancia, que puede ser a distintos niveles. Como ejemplos, la torre Windsor de Madrid, o las Torres Gemelas de Nueva York.

En resumen, nuestros edificios TIC están compuestos de un gran número de redes que, según los casos, pueden compartir infraestructura. Entre ellas destacar, la red de datos, de vigilancia y control de acceso, de alarma, de tensión eléctrica, de tomas a tierra, de almacenamiento (SAN), de "backup", redes de aguas, de aguas sucias, de gases, de ascensores, de acondicionamiento térmico, de detección de incendios, de control de energía y del aire, de espionaje, etc., etc. Como puedes comprobar, son muchas las redes además de la de datos, por lo que siempre tendremos que tener en mente todas ellas. Aquí podríamos hablar de edificios inteligentes, pero creo que se sale de la temática de la asignatura, unido a que esa rara acepción, no creo posible encontrarla en un edificio.

lunes, 18 de mayo de 2009

II Programa de prácticas de verano en empresa (remuneradas)

Información remitida por la FUC.
--------------
Estimado amigo/a:

Dende a Fundación Universidade da Coruña queremos informarche que puxemos en marcha o II PROGRAMA DE PRÁCTICAS DE VERÁN TEMPUS. Programa de prácticas en empresas remuneradas dirixido a estudantes universitarios para o próximo período vacacional.

Si estás interesado e necesitas información ponte en contacto coa Unidade de Emprego e Formación da FUAC.

Más información en http://www.fundacion.udc.es/

sábado, 16 de mayo de 2009

Ensuring Data Security During Hardware Disposal

Noticia disponible en http://www.darknet.org.uk/2009/05/ensuring-data-security-during-hardware-disposal/

Hemos hablado de seguridad a nivel físico, de la necesidad de aplicar mecanismos de protección a nivel físico, del hardware. Todo "hardware" tiene un ciclo de vida y, tras la vida, nuestros equipos se pueden reencarnar en nuevas vidas. Lo que para unos es chatarra, para otros es un tesoro. Pero, ¿qué pasa con nuestros equipos que dejan de dar servicio?. Entre otras muchas cuestiones, sus discos duros, los dispositivos de backups, etc., siguen soportando información durante muchos años que, incluso después de un mal-borrado, se podría llegar a recuperar. Como ejemplo, la noticia que encabeza esta entrada.

A nivel funcional, señalar la existencia de herramientas para hacer un borrado de nuestros dispositivos de almacenamiento magnético, de tal forma que ningún análisis forense pueda recuperar la información (DBAN y Eraser). Si manejas información crítica, sin duda alguna deberás definir un método de reciclaje al nivel de las circunstancias, evitando que los equipos puedan darte un susto en su segunda vida o, en caso de duda, siempre puedes pulsar el botón de autodestrucción. Aunque a todos nos gusta probar técnicas y herramientas como metodología de aprendizaje, no pruebes estas herramientas en tus discos duros. Y de hacerlo, un backup completo previo o imagen te vendrá muy bien. -:)

Puedes complementar el tema con "La recuperación de datos, un arma de doble filo"

Para borrado seguro de ficheros destacar, entre otros, srm, wipe o shred. Como todo en este mundo, toda herramienta proporciona un "arma" muy valiosa tanto para el lado oscuro, como para el de la luz, unos por protección de la información y, los otros, para eliminación segura de cualquier posible rastro.

viernes, 15 de mayo de 2009

Bitácora de PSI.: Protejamos nuestro físico

Nuestra historia cuatrimestral comenzó con una clásica clasificación de categorías de ataques (interceptación, interrupción, modificación y generación). Como ejemplo de la primera analizamos toda la problemática del "sniffing" en nuestras redes, incluyendo las posibilidades de ataques-engaño a los protocolos seguros. El estudio del DoS y DDoS nos sirvió para ilustrar la segunda categoría de ataque. El uso de otras técnicas en conjunción con las técnicas y herramientas de "sniffing", DoS y DDoS proporcionan nuevos ejemplos para ilustrar la categoría de modificación y generación. Aunque podríamos continuar nuestra aventura analizando otros muchos casos, es el momento de evolucionar a una nueva aventura.

Las categorías de ataques afectan a los datos, software y hardware. Hemos jugado en prácticas con los dos primeros, y no debemos olvidarnos del tercero, del hardware, de la seguridad a nivel físico. La segunda parte de la clase la dedicamos a proporcionar diferentes ideas generales en este nivel.

1.- Aislamientos de los CPD, salas de comunicaciones, etc. Mecanismos.: Llave convencional, videoporteros, tarjetas (barras, magnéticas, inteligentes, proximidad) y sistemas biométricos.

En este punto se analizan los mecanismos de funcionamiento y las principales ventajas y desventajas de cada uno, así como las posibilidades de combinación. En todo momento se pone como ejemplo instalaciones de control de acceso existentes. En cuanto a su instalación, se analizan las ventajas y desventajas de utilizar una VLAN de control de acceso sobre la infraestructura-activos de red existente. Hubo un tiempo en que coexistían en nuestros organismos un gran número de redes (datos, vídeo, telefonía, vigilancia, etc.), y otro, en el que todo convivía en una misma red y, en cierto sentido, se hacián compañía. En todo momento se indican algunas posibilidades de sabotaje a estos sistemas.

2.- Sistemas de videovigilancia. En este desarrollo se sigue un planteamiento similar al del punto 1.

3.- Red eléctrica. Aquí tenemos una de las muchas redes de nuestros edificios, con su cableado y mecanismos de seguridad (diferenciales y magnetotérmicos). En este punto analizamos la necesidad de UPSs o SAIs. Parámetros como tiempo vs. consumo., calidad y rectificado de señal, tipos de SAIs, unidad KVA, VAi, tiempos de alimentación, selección de SAIs, son algunos de los conceptos tratados.

Entre los aspectos "cacharreo" tratados en esta clase, incluyo en esta entrada la forma de proteger el grub. A este respecto, dado que grub ha evolucionado, recomendable visitar la entrada "Password en grub2" del blog de Uxío.

Y aquí dejamos esta historia, para próximos capítulos.

Bitácora de PSI.: Who is who & Metallica is metallica (parte I)

La primera parte de la clase, tras 2 horas de prácticas en laboratorio, la dedicamos a introducir distintos organismos y su aportación al mundo de la seguridad y, en especial, a su estandarización.

Iniciamos esta andadura con el NIST (National Institute of Standars & Technology) y se presentan algunos de sus principales Federal Information Processing Standards (FIPS), o la National Vulnerability Database (NVD), como herramientas de gran relevancia en PSI.

El Institute for Security and Open Methodology (ISECOM) también pone a nuestra disposición un buen conjunto de metodologías y desarrollos en "compromise detection", "secure programming", "security politics", "security testing", etc.

En un tercer bloque analizamos algunos de los estándares en seguridad de la ISO. Partimos de la ISO17799 (estándar de seguridad en información) y vemos su evolución a la ISO27001, que se centra en la gestión de la seguridad de la información, e ISO27002, sobre buenas prácticas en seguridad en la forma de objetivos de control y controles recomendados. Obviamente ambos estándares son complementarios. Finalizamos la aventura de la ISO con las ISO27003, 05 y 11.

Finalizamos la primera parte de la clase con el Standard of Good Practice for Información Security del Information Security Forum (ISF).

"Cuando has experimentado con todo tipo de ataques, métodos y herramientas en seguridad, las metodológicas te proporcionarán la energía y el orden necesario para conseguir un cierto nivel de equilibrio-abstracción de nivel superior en la profesión. Como es lógico, todo requiere su tiempo"

jueves, 14 de mayo de 2009

Autómatas y "creación" musical

SÁBADO 16 DE MAYO
DÍA INTERNACIONAL DE LOS MUSEOS

Actuación del artista londinense
STEPHEN CORNFOR
DOXIDE CURRENTS
22:00 h.

VISITA GUIADA NOCTURNA
a la exposición temporal
'antes de ayer y pasado mañana,
O LO QUE PUEDE SER PINTURA HOY'

de 23:00 a 00:00 h.
gratuita y sin reserva de plaza

STEPHEN CORNFORD es un artista multidisciplinar londinense que juega con la interacción y la provocación en sus instalaciones sonoras, actuaciones en directo y creaciones audiovisuales. Estos trabajos, que se cuentan entre los más personales del momento, mezclan la acción humana y la automatización de procesos sonoros mediante el diseño y utilización de máquinas capaces de tocar, de forma no siempre ortodoxa, instrumentos como el violín, la guitarra eléctrica o el piano. Buen ejemplo de ello sería la banda Human Separation, en la que el propio Cornford y su compañero Matthew Appleby se convierten en directores de un grupo de autómatas que toca varias guitarras y una batería, dentro de un proceso en el que la acción humana no se ejerce directamente sobre los instrumentos, sino sobre las máquinas que los manejan.

Sobre su actuación del próximo sábado, titulada Oxide Currents, Cornford nos comenta lo siguiente: "SSCD_6.2 es un equipo de cassette delay de construcción casera creado a partir de viejas grabadoras y componentes electrónicos básicos, en homenaje a máquinas obsoletas como el Dynacord Space Echo y el Watkins Copycat. Permite grabar material acústico y reproducirlo al mismo tiempo que la cinta viaja a lo largo de sus seis pletinas. Esta máquina hace alusión a la historia de la llamada Tape Music, abarcando tanto la música concreta como la música procesada. La baja fidelidad de la cinta asegura que ninguna de las señales retardadas sea una repetición del sonido acústico original. En ArtEx Sonora II utilizaré este equipo para crear complejos enjambres de sonidos a partir de fuentes aparentemente sencillas, como pequeños objetos, vasijas, una viola o la propia sala del concierto."

Entrada libre
Aforo limitado
Aparcamiento gratuito
Autobús urbano Nº11

MACUF. Museo de Arte Contemporáneo UNION FENOSA
Avda. de Arteixo 171 15007 A Coruña
http://www.macuf.com/

miércoles, 13 de mayo de 2009

Conferencia.: "The impact of Cloud Computing and Virtualisation"

Profesor: Mark Baker da Escola de Enxeñería de Sistemas e Comunicación da Universidade de Berkshire en U.K.

Data: martes 19 maio
Hora: 10:30
Lugar: aula 3.3 da FIC da UDC

martes, 12 de mayo de 2009

Bitácora de PSI.: Seguimos de monitorización

Seguimos con comandos básicos de ayuda a la monitorización. Entre ellos, uname, uptime, time, ps, vnstat, df, du, who, gprof, ping, traceroute, etc. Otro conjunto de comandos evolucionados lo constituyen dstat, iftop, tcptrack, vnstat y atop. Se presenta la utilidad y salida de dichos comandos, sin entrar en posibles opciones. Para más información ver sus man.

Otro ámbito de herramientas es del chequeo de integradad. Entre ellas sxid, tripwire o ViperDB.

Entre los muchos apartados de la práctica 2 (parte II), de las posibles opciones de uso, el tripwire y el vnstat os permitirán resolver un par de ellos. Otras herramientas se centrar en falsear el comportamiento de las máquinas y sus servicios. Entre ellas, el DTK (Deception Toolkit).

Hasta este punto hemos visto herramientas de monitorización de equipos, sin pensar en las posibilidades de entornos centralizados de monitorización de un gran número de activos. Aunque se podrían desarrollar soluciones propios con lo visto, en la actualidad existe una gran cantidad de herramientas para dicha tarea. Entre ellas, Pikt, zabbix, munin, Nagíos, NTOP. MRTG (Multi Router Traffic Grapher) y OSSIM (Open Source Infraestructure for Security Monitoring). De forma generealizada estas herramientas o hacen uso de agentes propios en el lado cliente o del protocolo de gestión SNMP (Simple Network Management Protocol), con o sin soporte de las MIB (Management Information Base).

"De nada sive disponer de todo tipo de sistemas de monitorización, "logs", detección de intrusiones, analizadores de vulnerabilidades, sistemas de alarma más o menos inteligentes, etc. en entornos en los que nadie analiza la información y, como mínimo, atiende las alarmas. Tener este tipo de sistemas está muy bien pero, sin duda alguna, requiere un cierto control de toda la información y alarmas gestionadas".

Concurso de seguridad del cambRED_09

Los días 8, 9 y 10 de mayo se ha celebrado en el Pabellón Polideportivo de Cambre (A Coruña) el cambRED_09.
Como en todo evento de esta naturaleza, no ha faltado el concurso de seguridad. En esta edición el ganador del mismo ha sido una alumno de PSI, Jose Cribeiro. Querido alumno, te has ganado un punto extra en la asignatura.
Adjunto información remitida por Jose sobre el desarrollo del concurso.
-------------------------------------
Para el concurso de seguridad te daban la ip de una maquina que era la que tenías que atacar, y escalar privilegios en ella sabiendo que había un user que se llamaba cambred cuya contraseña te decían que era muy fácil. La contraseña era cambred.

Si te conectabas a la máquina por ssh al puerto 22 y tras escribir login y pass, entrabas en la máquina y nada más hacer un ls normal te dabas cuenta que algo no iba bien ya que en lugar de sacar un ls normal, sacaba un ls -l, si intentabas algún otro comando básico, como podía ser un cd para entrar en algún directorio te decía que no existía, así que rápidamente te dabas cuenta de que estabas en un honey.

Tras cerrar la conexión y hacer port discovery sobre la maquina con nmap te sacaba que había otro puerto abierto el 1010, así que como no había ningún otro puerto, y se sabía que tenías que tener acceso a la máquina y se sabía también que era por ssh, te conectabas a la máquina en el puerto 1010 por ssh y ya estabas realmente dentro. Una vez dentro podías descubrir fácilmente la existencia de 3 users además de root, cambred, cambred2, y cambred3.

Como en todos los niveles del juego tenías pista en forma de README.cambred al leer el del directorio de cambred te decían que al usr cambred le gustaban los irc al estilo de la vieja escuela, mientras seguía investigando y explorando el terreno en el que me encontraba decidí hacer un ls -R -lisa y viendo el resultado encontré un fichero de configuración de un cliente de irc, el irssi, entre muchas cosas en el fichero de configuración había una línea en la que se hablaba de un canal de irc y que el password del user cambred2 era una cadena cifrada, así que tras googlear un poco sabías que la cadena estaba cifrada con ROT-13, la descifrabas y ya tenías tu pass para cambred2.

Bien, una vez pasado el primer nivel, volvías a leer el README.cambred, de este user y te decía que las cosas no son lo que parecen y que a veces se escondían cosas tras cortinas de humo. Además del README.cambred había un ejecutable que te decía, "enséñame la patita por debajo de la puerta -dijo el cordero" y después te preguntaba por el password. Así que supuse que la contraseña se encontraba escrita en claro dentro del código fuente del ejecutable así que use strings para sacar las posibles cadenas de texto y casualmente una de ellas decía, "esta es la contraseña de cambred3"

Te conectabas como cambred3, y tenías otro README.cambred que te decía que tenías que aprovechar los errores de los programadores, y existía también un ejecutable que se llamaba rootls, que como su nombre indica hacía ls sobre un directorio con permisos de root, así que podías hacer: ./rootls /root/, y ver lo que había y veías que había otro README.cambred así que mi objetivo principal ahora mismo era leer el README.cambred del directorio /root/, investigando un poco y haciendo gdb sobre rootls desensamblándolo, pasándole también strings descubrí otra pista que decía que 640 bytes deberían bastar, y además descubrí que se hacía una llamada directamente a /bin/ls, así que decidí enfocar el ataque buscando un buffer overflow, con una cadena de 640bytes, y poniéndole al final un /bin/cat y descubrí que ejecutaba el cat pero que no era capaz de hacer que funcionase correctamente con los parámetros que le pasaba en el buffer anterior así que al final hice un programa que leía el fichero /root/README.cambred y ejecute el ./rootls "aquivaunacadenade640caracteres"/home/cambred3/"miejecutable" y listo ya había leído el fichero, que me decía que fuese corriendo a junto del los de la organización a decirles la frase: "En Sevilla la Lluvia es una maravilla"

viernes, 8 de mayo de 2009

Bitácora de PSI.: Monitorización más o menos "inteligente"


Un alumno en prácticas me plantea una cuestión “una máquina puede presentar un cuello de botella, se puede degradar su performance por múltiples causas, ser atacada por diversos métodos, incluidos los de denegación de servicio, etc., pero, ¿cómo puedo detectar esta situación?"

Sin duda alguna es la cuestión que, en el punto en el que nos encontramos, se debería plantear. En un primer momento, existen dos posibilidades.:

- No hacer nada y que sean los propios usuarios de nuestros sistemas los que, cuando un sistema presente un mal funcionamiento o una degradación en sus prestaciones, nos avise.

- Disponer de distintos sistemas de monitorización y alarmas en los sistemas administrados o, al menos, en servidores relevantes. Señalar que en este punto no estamos hablando de sistemas como puedan ser los IDSs, que entrarían en otro apartado relacionados con la monitorización y detección de intrusiones, o los sistemas de análisis de vulnerabilidades.

La primera opción supone tener que curar a un paciente cuando está en una situación crítica, sin contar todas las implicaciones de prestar un mal servicio a nuestros usuarios-clientes. Bajo ningún concepto debemos proceder de esta manera. En todo momento deberemos pensar en un mínimo de herramientas que nos faciliten la monitorización de los sistemas.

En este punto, iniciamos la aventura con las opciones básicas de "accounting" de procesos y usuarios.

El clásico paquete acct nos proporcionará unas herramientas básicas de monitorización de procesos y usuarios. Comandos como el ac, lastcomm, sa, last, lastb, entre otros, nos proporcionan algunas posibilidades básicas. Se estudian los parámetros de salida de los mismos.

En un segundo nivel se analiza el paquete sysstat como herramienta básica de monitorización de los distintos subsistemas gestionados por los sistemas operativos de nuestras máquinas, tanto en "tiempo real" como sobre bases de datos históricas, que nos permiten analizar el "performance" de las máquinas en cualquier momento pasado.

En toda monitorización un parámetro que debemos definir es el período de muestreo. Obviamente este deberá ajustarse a los objetivos de los posibles estudios sobre las muestras. Señalar que toda monitorización también supone una sobrecarga en el sistema que, de ser necesario, debería cuantificarse. En el marco del paquete sysstat se analiza la salida obtenida por los comandos iostat, mpstat, sar, top, vmstat y free, así como las opciones para garantizar el muestreo histórico de parámetros del sistema y el tratamiento de los mismos por los "scripts" sa1, sadc y sa2. También se incluye el comando sadf para exportar los datos a CSV o XML. Nuevamente se analizan los principales parámetros de salida de todos ellos.

Se incluye una herramienta no menos importante, la ISAG (Interactiva System Activity Grapher) que, sobre un entorno gráfico permite seleccionar un fichero del subsistema sysstat en binario (saXX) y mostrar los datos de muestreo históricos de forma gráfica. Sin duda alguna estos gráficos nos proporcionan de una forma visual mucha información sobre la evolución del "performance" en los distintos subsistemas gestionados por el sistema operativo.


Para concluir, señalar que de nada nos sirve disponer de muchos datos sin una cierta capacidad de análisis y, o, sistemas de alarma. Es necesario "conocer" las salidas producidas y las posibles interacciones e implicaciones de las mismas para, con ellas, sacar conclusiones que nos permitan tomar decisiones. Nuevamente llegamos a la “palabreja” que aparece cada poco en la asignatura, "tomar decisiones". Sin duda alguna, el profesional que nunca toma decisiones, o hace que sean otros los que las tomen, nunca se equivocará. Pero este es otro de los muchos puntos que diferencia un buen profesional de uno mediocre. Todo responsable del sector TIC debe potenciar a aquellos profesionales que toman decisiones y, muy especialmente, a los que asumen las posibles responsabilidades de las mismas, incluso en los casos no acertados.

martes, 5 de mayo de 2009

Bitácora de PSI.: Otra de zoombies

Hoy nos hemos dedicado a la otra problemática de nuestra profesión, el día a día de nuestro trabajo, pero en este caso considerando una empresa que debe "capear" un ataque DDoS. Una buena referencia al respecto.:

- Network DDoS Incident Response Cheat Sheet de Lenny Zeltser

Si administrar sistemas tiene una cierta problemática, la administración de personas, de personal, es mucho más compleja.