jueves, 15 de febrero de 2007

Cantidad o Calidad

Ja ja ja. Ya sé a que suena, pero me voy a explicar y lo entenderéis.
Estoy trabajando en la sustitución de una red LAN obsoleta y tengo que plantearme que características deseo para la nueva red en general, como sistema y en particular que voy a exigir al core y los conmutadores de acceso.
Hoy en una presentación de una exposición sobre materiales de alta tecnología, aplicados a las prácticas deportivas, uno de los oradores, enseñándonos una raqueta de tenis, nos decía: " Hoy en día, la tecnología aplicada al desarrollo de las raquetas, se esfuerza en conseguir materiales y productos más ligeros y más resistentes, pero los tenistas de élite, no usan ni las más ligeras ni las más resistentes. Esto se debe a que prefieren aquellas raquetas que les permiten tener una mayor sensación de control sobre la raqueta y sobre la pelota."
Me resultó interesante oír esto y al tiempo pensé en otro ejemplo. Es posible que a un corredor, no le interesen ni las zapatillas más ligeras, pero si aquellas que, aun con algo más de peso, sean más cómodas o mejoren el agarre al suelo, permitiéndole aumentar la velocidad.
¿Para que sirve una LAN?. Escoged vosotros:
  1. Para llevar enormes cantidades de datos, de una lado a otro, a la mayor velocidad posible
  2. Para llevar la información de un origen a un destino, con las mayores garantías se seguridad e integridad.

Posiblemente una mezcla de ambas es la mejor respuesta, pero ¿cual consideras más importante?.
Yo tengo una respuesta a esta pregunta, sin duda, la seguridad y la fiabilidad. Todos sabemos que en muchos casos se debe sacrificar la operatividad, para aumentar la seguridad, y estos sacrificios no dudamos en absoluto en realizarlos.

Revisando algún artículo sobre conmutación a nivel LAN, me he sorprendido de descubrir que la tecnología ha evolucionado muy poco en cuanto a la velocidad de los enlaces. Hace años, cuando compramos la primera red, se empezaba a utilizar la tecnología Gigabit, y se mencionaba la 10G, pero hoy nos encontramos, unos cuantos años después, con importantes limitaciones para garantizar que un conmutador con enlaces 10G no tenga bloqueos.
Ahora podríamos tirarnos de los pelos y decir, ¡Quiero 10G en todos mis enlaces!, pero, ¿lo vamos a utilizar?. Antes deberíamos de medir el uso de los enlaces, verificar si nuestros enlaces Gigabit, ya andan cerca de la saturación, y si no podríamos aligerar el tráfico en la red o agregar canales de enlace.

Como "afortunado" administrador de la red, hoy en día me preocupa mucho más la seguridad que la velocidad. La gente siempre podrá quejarse de que su PC va lento, incluso hay quien afirma que va más rápido que su PC, pero lo que nunca te perdonarán es que su información se pierda (resulte alterada), o que sea vulnerada la privacidad.
Considero que el esfuerzo a la hora de adquirir una nueva red LAN o de renovar la existente, debe ir orientado, principalmente a mejorar los mecanismos de control de acceso a la red y a la información, y que en un segundo plano deben quedar las latencias, los anchos de banda y demás medidas de velocidad.

Eficacia o eficiencia. Obviamente primero es la eficacia, alcanzar todos los objetivos, y después de esto, la eficiencia, alcanzarlos de la mejor manera posible, en este caso, la más veloz.

Recurriendo a otra frase publicitaria, a veces tan socorridas, a falta de memoria de nuestro excelso y fabuloso refranero: "La potencia sin control no sirve de nada". Venga, uso el refranero: "Quien mucho corre, pronto para".

Obviamente, podéis tener otras opiniones, y me gustaría que si consideráis que es más importante potenciar la velocidad de la red, que aumentar el control de acceso o control del tráfico que por ella circula, me hiciera cambiar de idea.

Un saludo y buenas noches.


martes, 13 de febrero de 2007

Objetivo de una auditoría de seguridad

En mi empresa, por falta de tiempo, hemos encargado una auditoría de seguridad a una empresa externa.
No hemos invertido nada de tiempo en saber qué es seguridad.
La inquietud personal me ha movido a leer algo del tema y voy a reflejar en este blog mis avances y cosas que vaya descubriendo.
Perdonad me de antemano mi falta de asiduidad, pero soy muy inconstante.
Lo primero que veo del trabajo que están desarrollando esta gente es lo inútil y poco duradero que resultará. Me explico.
Esta gente, está realizando un estudio de vulnerabilidades, analizando puertos y todo lo que sigue. Nos presentan un listado de las máquinas que han estudiado y sus vulnerabilidades, eso si, explicadas.
Ahora bien, que hacemos, cerrar la herida y seguir para adelante.
Esto beneficia en corta a la empresa, y a medio y largo plazo a la consultora. La justificación es obvia, hoy resolvemos la vulnerabilidad, pero mañana habrán 'n' nuevas. ¿Que tenemos que hacer?. Claro, volver a contratarles, si lo hicieron de p. madre.
Nooooo!.
Tenemos que aprender de nuestros errores, es decir, saber como es posible que esa vulnerabilidad estuviera allí, sin darnos ni cuenta. Pero más importante aun que esto, es establecer unos procedimientos, un método de trabajo que evite que la seguridad resulte algo preocupante cuando haces los presupuestos de un año para otro o cuando crees que te han entrado hasta la cocina.
Como es el lema recientemente inaugurado de este blog, saber cómo, en este caso como evitar problemas de seguridad, es más importante que saber qué, que problemas de seguridad son los que tienes en este momento. Sabiendo cómo, evitas el problema actual y futuro, sabiendo que problemas tienes, solo ayuda a resolver los problemas que tienes ahora, en este instante, y sin una reflexión posterior, no ayuda nada a solventar futuros problemas.

Espero haber sido claro. Sé que me he repetido mucho en una sola idea, pero la considero tan básica, que creo que la volveré a reiterar en varias ocasiones.

Buenas noches.

lunes, 12 de febrero de 2007

Vulnerabilidad Solaris 10 y telnet

Hoy me he quedado sorpendido con la grave vulnerabilidad de la herramienta telnet, en el Solaris 10 y según comentan en el Solaris 11. Nunca había visto algo tan simple. Basta con ponerte en un terminal y poner: telnet -l "-froot" host.domain.com, donde host.domain.com, es la máquina a la cual pretendes acceder.

Mi sorpresa a venido al verificar que esto permitía acceder a la máquina remota con una línea de comandos como superusuario. Por lo que he leído no hay todavía solución, aunque no tardará salir el parche. La solución a día de hoy, dejar de usar el telnet, que ya va siendo hora.

Alguien me tendrá que explicar algún día, porque se empeñan algunos administradores en usar el telnet, o mantener los puertos abiertos. ¿No hace lo mismo y mejor el ssh?.
La información más detallada la podéis encontrar en esta página. Yo corregiría el título y diría, ¿No hay bastantes razones para dejar de usar el telnet?.

Ya sabemos o deberíamos de saber todos que el telnet muy vulnerable, simplemente por enviar sin cifrar nada, ni la contraseña de inicio de sesion. Esto debería de ser motivo suficiente para haber anulado este protocolo en todas las máquinas.
No será tampoco por falta de buenos clientes de ssh, el putty y el secure shell, son más que suficientes.
¿POR DIOS? Pero si guindous no tiene un comandito en el cmd que lo hace!. Será por eso que no usamos el ssh!!.

domingo, 11 de febrero de 2007

ONO y sus DNS

Yo no hago más que cambiar las DNS. Las de ONO fallan más que una escopeta de feria, no se dan cuenta que los clientes piensan que pierden la conexión y eso puede probocarles bajas. Ellos sabrán.
Hoy me esta pasando algo que no me sucedía antes. Yo me decidí por las DNS de Telefónica 80.58.X.X. Pero hoy han dejado de funcionar, al menos desde ONO.
He buscado y probado otros, y lo más interesante es que la primera consulta funcionaba y las sucesibas, fallaban. Recomendable esta lista de DNS.
Al final, me he decidodo por probar las DNS de OpenDNS. Las localicé en este blog. Estas parece que responden rápido y que no mueren en la primera consulta.

Por cierto, las DNS: 208.67.222.222 y 208.67.220.220

PD.- Los he probado poco, pero, WOW, la navegación vueeela.

Suerte y estabilidad.