lunes, 17 de agosto de 2009
miércoles, 12 de agosto de 2009
Pendrives y NTFS
Aún no sé bien por qué uso NTFS como sistema de ficheros en mis pendrives. En Mac OSX tengo soporte para EXT3; entonces, no debería utilizarlo. Supongo que será por si tengo que llevar algún documento a la copistería, o intercambiar ficheros con lusers. El caso es que un pendrive que uso a menudo, al intentar montarlo en Debian GNU/Linux o Ubuntu, Gnome me invita amablemente a que lo inserte en una máquina Windows y ejecute el famoso chkdsk(Checkdisk). Cómo no me parecía una solución demasiado ética, por cuestiones obvias, me puse a buscar información y encontre la herramienta ntfsfix. No estoy seguro, pero supongo que esta herramienta forma parte de ntfsprogs. Como dice en su página del manual, ntfsfix corrige errores comunes en NTFS, pero no es una versión para Linux de chkdsk. Sólo repara inconsistencias.
Ejemplo de uso:
Por cierto, sí forma parte de ntfsprogs, al final de la página del manual indica: ntfsfix is part of the ntfsprogs package(...)
Ejemplo de uso:
root@alberto:/home/alberto# ntfsfix /dev/sdf1
Mounting volume... FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdf1 was processed successfully.
Por cierto, sí forma parte de ntfsprogs, al final de la página del manual indica: ntfsfix is part of the ntfsprogs package(...)
martes, 11 de agosto de 2009
vim
Al principio fue la línea de comandos...y usaba vi. Me parecía un coñazo, "Demasiado complicado", me decía a mí mismo. Recuerdo que en un intento frustado de cursar el LPI, en el 2001, me presentaron a Nano; no a Nano el compañero de Bilo, sin al editor. Me parecía fácil de usar.Hasta hace un año, cuando me preguntaba qué editor usaba en el terminal, respondía "Nano", y muchos "talibanes" se llevaban las manos a la cabeza, y con más "desprecio que razón" exclamaban "Pero si eso es para nenazas, no conoces vi", "Sí.",respondía,"pero Nano me parece sencillo y cumple todas(las pocas) funciones que necesito." Después de este largo caminar por el Lado Oscuro de los editores, hace un año, he vuelto a vi, mejor dicho a vim. La razón principal, pese a tener una curva de aprendizaje más elevada, en mi opinión,es un editor más completo que Nano. Me gusta mucho, por ejemplo, que puedas ejecutar comandos directamente en el editor(desconozco si Nano lo hace); o lo bien que funciona con expresiones regulares. Esta mañana he visitado la web de vim(versión mejorada de vi), la entrada de la Wikipedia. He encontrado una Guía de Referencia Rápida en castellano, recomendada para los osados que quieran dejar el Lado Oscuro de los editores...
lunes, 10 de agosto de 2009
De vuelta...
Después de 15 días de vacaciones, estoy de vuelta en Compostela. Sin lugar a dudas me ha venido bien el descanso, aunque apenas me he separado del portátil. La conexión 3G cunde mucho, sobre todo si te desplazas: me he conectado desde Compostela,Mugardos,Ponferrada,Santander... y me ha servido para estar al día, revisar correo y demás. Dentro de un mes volveré a estar de nuevo ocioso, 6 días, los últimos del año ya, pero pensando más que nada en la VI Edición del Kernel 2009.
Sé que no he escrito mucho durante los últimos dos meses, y anoto en mi mente ponerme al día con el blog...que pronto cumplirá dos años, y sería una pena perder la buena y sana costumbre de escribir. Sí tengo cosas interesantes que decir y contar. Ayer de noche, repasaba un número atrasado de Todo Linux, y leí de la existencia de un paquete llamado libtrash, que es la Papelera de Reciclaje, pero para la consola. Hoy por la mañana, tenía pensado escribir algo sobre este paquete, pero he encontrado en la red cosas tan interesantes como esta.
Otra perla con la que me he topado esta mañana ,es un libro : "Implementación de Servidores GNU/Linux" , de Joel Barrios, un clásico entre los clásicos, siempre presente en cualquier documentación o manual sobre GNU/Linux.Se puede descargar una copia en esta URL.
De momento, esto es todo!
Sé que no he escrito mucho durante los últimos dos meses, y anoto en mi mente ponerme al día con el blog...que pronto cumplirá dos años, y sería una pena perder la buena y sana costumbre de escribir. Sí tengo cosas interesantes que decir y contar. Ayer de noche, repasaba un número atrasado de Todo Linux, y leí de la existencia de un paquete llamado libtrash, que es la Papelera de Reciclaje, pero para la consola. Hoy por la mañana, tenía pensado escribir algo sobre este paquete, pero he encontrado en la red cosas tan interesantes como esta.
Otra perla con la que me he topado esta mañana ,es un libro : "Implementación de Servidores GNU/Linux" , de Joel Barrios, un clásico entre los clásicos, siempre presente en cualquier documentación o manual sobre GNU/Linux.Se puede descargar una copia en esta URL.
De momento, esto es todo!
lunes, 3 de agosto de 2009
Reflexiones, DMZs, Postfix y libertad...
Este post es una respuesta a un email que me ha enviado un amigo las semana pasada. Muchas líneas son opiniones personales,otras reflexiones sobre lecturas
recientes, otras...
Eliminar y Exponer
Resulta curioso, pero sería yo quien formularía la pregunta ¿Por qué eliminarlos? ¿Rendimiento? ¿Mal o pésimo funcionamiento? ¿Mantenimiento? ¿Coste? Si la única pregunta que en este contexto tiene sentido es la última, tienes un problema; si dudan en alguna de las anteriores, si son personas sensatas, por lo menos vamos a intentarlo.
En primer lugar, y dejando a un lado si el S.O de la máquina que hace relay es GNU/Linux o no, personalmente jamás expondría una maquina corriendo Microsoft Windows a Internet, pudiendo evitarlo. Es más, jamas expondría una máquina a Internet pudiendo evitarlo, en todo caso, para eso se diseñan las DMZs, y máxime si la solución alternativa es una o varias máquinas corriendo algún sabor UNIX y con alguna licencia libre y gratuíta. Los motivos a continuación:
Estabilidad: El diseño de un S.O Unix/Linux dista años luz de un S.O Microsoft. Unix es C, C es robuztez y estabilidad. Unix es un conjunto de aplicaciones pequeñas y simples, que cumplen una sola función y lo hacen bien, por ejemplo iptables o fetchmail. Microsoft Windows, sin embargo está y por lo que se deduce, estará, encadenado a ficheros .exe y actualizaciones dependientes del trabajo de un único grupo de programadores asalariados. Es cierto que con los “Boletines del Segundo Martes” intentan acercarse al ritmo de desarrollo y corrección de bugs de S.O GNU/Linux tipo Debian o Red Hat, o BSD como FreeBSD, todo indica a que su trabajo está orientado a un simple Service Pack cada X meses o años.
Mantenimiento: Una maquina Unix requiere de unos conocimientos mínimos de Administración para que las funciones que realice, las haga bien. Una vez configurada, pueden pasar años hasta que requiera un mantenimiento que se aleje del típico de la actualización de software y parches de seguridad. En multitud de ocasiones, una máquina Unix mal configurada por un/unos Administradores con conocimientos escasos del software con el que están trabajando, puede dar la impresión de necesitar más tareas o tiempo de mantenimiento que una máquina corriendo Microsoft Windows: nada más lejos de la realidad. Visite netcraft.com y o top500.org y podrá comprobar que tienen en común el 88% de los 500 computadores más “potentes” del momento: un S.O Linux. ¿Casualidad? No creo que DELL, NASA se basen en casuísticas para el elegir el S.O de sus Servidores.
Seguridad: Partiendo de la base de que ningún S.O es seguro si está conectado a una red de computadores, me gustaría hacer incapié que el concepto de Seguridad Informática es un proceso continuo y lineal, en contraposición a una series de medidas puntuales, como por ejemplo, añadir una cadena -j DROP a iptables para que “impedir que megano haga pings a fulano”. En palabras de J.Pérez Agudín “La seguridad ha de ser entendida como un equilibrio, la inversión en seguridad ha de estar a la altura de la importancia de la información a proteger”. Volviendo al eterno dilema de por qué Linux es más seguro que Microsoft Windows, me gustaría comentar:
Desarrollo continuo: la comunidad de desarrolladores trabaja a diario publicando parches y liberando nuevas versiones. No hay necesidad de esperar a que una empresa considere oportuno “vender” un nuevo producto para tener software actualizado.
Mejor diseño de S.O de base. Nos referimos en la práctica, a que por ejemplo, ante una vulnerabilidad en Postfix, si un usuario pudiese supuestamente tomar el control de la máquina, sólo lo haría con el usuario con el que se ejecute el proceso, es lo que se conoce como CHROOT o jaulas de usuario. En Microsoft Windows también es posible, pero no se ejecutan por defecto todos los procesos con usuarios diferentes.
Diversidad de Entornos: El núcleo de Windows Server es el mismo para las distintas versiones, por lo que en la práctica resulta muy sencillo aplicar un exploit a dichas versiones. Sin embargo, dada la diversidad de versiones, tanto de BSD como de Linux, un exploit en Fetchmail puede causar distintos daños o nulos dependiendo del entorno, fundamentalmente en versiones del Kernel y del software de las herramientas de seguridad configuradas en la (SELinux o AppArmor de Novell).
Dejando a un lado la disyuntiva Windows vs Unix, me gustaría dedicar unas líneas a comentar el supuesto caso de exponer una máquina a la red Internet. ¿Se puede evitar ? A mi modo de ver, la respuesta es : Sí. Un sí rotundo. En este caso concreto hablamos de una máquina que recibirá el correo directamente desde los servidores SMTP del remitente. Se presupone que el nuevo (re)diseño de la arquitectura de red resultante debe como mínimo superar las prestaciones del anterior, prestando atención, a mi modo de ver, a los siguientes puntos.
Ancho de Banda: En ningún caso, en mi opinión , se debería conectar una maquina que sirva SMTP a una línea convencional, tipo ADSL o Cable, al tratarse de líneas asíncronas no se garantiza en ningún momento un caudal mínimo, que garantice un servicio fiable. Mi recomendación son líneas simétricas de datos , SHDSL o similares.
Direccionamiento: Se presuponen unos requisitos mínimos en la calidad del servicio de la nueva instalación. El direccionamiento Ipv4 de los actuales ISP deja mucho que desear. Compruebe una dirección IP al azar de la red 0.Red-217-127-182.staticIP.rima-tde.net, podrá comprobar como “se mezclan” en el pool de direcciones tanto direcciones públicas para usuarios domésticos como usuarios de perfil empresarial. ¿ Cree realmente que este rango estará totalmente limpio en listas RBL? Mi opinión es que no.
Mantenimiento: Imagine que en un momento dado, su router cabecera, el que envía los paquetes al Firewall para que los procese y los enrute hacia su máquina de correo, recibe del orden de 15.000 correos por minuto. ¿Qué haría en este supuesto? ¿ Dispone de los activos de red necesarios para bloquear automáticamente este tráfico? ¿ Dispone de los recursos humanos necesarios para solucionar esta incidencia? En mi opinión, a no ser que el número de usuarios superase los miles(4.000 usuarios por ejemplo), confiaría la recepción del correo electrónico a un proveedor de Hosting: Arsys, Dinahosting, 1&1...etc. A menudo, estas empresas gestionan sus propios Sistemas Autónomos
“Razones rápidas por las que no implementar Exchange”.
“Exclavitud empresarial”. Si se utilizan aplicaciones liberadas bajo estándares abiertos, las actualizaciones y parches de seguridad las tendrá disponibles de forma libre y gratuíta. Por el contrario si elige Exchange Server, Microsoft Corporation no le garantizará bajo ningún concepto la frecuencia de actualizaciones, ni mucho menos, el código fuente de la aplicación. No sólo para poder modificar el código, sino para poder compilarlo específicamente para su arquitectura y “sacar” el verdadero rendimiento de la aplicación que elija como su software de Servidor SMTP.
Económicas. Impensable pagar por las diferentes versiones de una aplicación. Es más, Postfix por ejemplo, sólo libera una versión de su aplicación; virtud o defecto. Mi opinión es que es una virtud; que combina flexibilidad, al poder adaptarse tanto grandes despliegues, como a pequeños componentes de hardware, tipo routers o access points.
Seguridad. Postfix, por ejemplo, lo ha desarrollado Wietse Venema, autor de herramientas como los TCP Wrappers o el Coroner Toolkit. Es un reputado experto en seguridad informática y eso , como mínimo es una garantía de calidad. Que Red Hat, IBM o Debian GNU/Linux incluyan Posftix en su cojunto de paquetes quiere decir algo, no cree? ¿Conoce algún sistema de Bugtraq? Visite securityfocus y podrá comprobar que Exchange tiene más de 1800 reportes de errores, en contraposición a los 220 de Postfix. Si ha todo esto sumamos que Posftix, o Qmail o Sendmail o Exim corren perfectamente en GNU/Linux, Mac OS X o diversos sabores de *BSD ¿ Duda de Posftix o software similar no es seguro?.
Flexibilidad. Combinar Postfix con Spamassassin o ClamAV es un ejemplo de flexibilidad. Empresas como este o Kaspersky han desarrollado versiones específicas de sus productos.¿Cree realmente que si este producto no tuviese la calidad suficiente, estas empresas habrían desarrollado versiones para GNU/Linux o BSD?
Estándares: Unos de las características fundamentales en el desarrollo de aplicaciones libres es el cumplimiento, estricto en la mayoría de las ocasiones, de estándares de programación y comunicaciones.
Virus. Hablar de correos electrónicos es hablar de virus. Una máquina Unix no se bloqueará por que el virus X se adjunte al correo Y.
Alberto Permuy Leal
Agosto 2009
recientes, otras...
Reflexiones, DMZs, Postfix y libertad...
Con la poca información que me has dado, me atrevo, ya sabes que la ignorancia tiene la virtud del atrevimiento, a dividir las cuestiones que formulas en dos partes: la primera, a la que denominaré "Eliminar y exponer", y la segunda, “Razones rápidas por las que no implementar Exchange”.Eliminar y Exponer
Resulta curioso, pero sería yo quien formularía la pregunta ¿Por qué eliminarlos? ¿Rendimiento? ¿Mal o pésimo funcionamiento? ¿Mantenimiento? ¿Coste? Si la única pregunta que en este contexto tiene sentido es la última, tienes un problema; si dudan en alguna de las anteriores, si son personas sensatas, por lo menos vamos a intentarlo.
En primer lugar, y dejando a un lado si el S.O de la máquina que hace relay es GNU/Linux o no, personalmente jamás expondría una maquina corriendo Microsoft Windows a Internet, pudiendo evitarlo. Es más, jamas expondría una máquina a Internet pudiendo evitarlo, en todo caso, para eso se diseñan las DMZs, y máxime si la solución alternativa es una o varias máquinas corriendo algún sabor UNIX y con alguna licencia libre y gratuíta. Los motivos a continuación:
Estabilidad: El diseño de un S.O Unix/Linux dista años luz de un S.O Microsoft. Unix es C, C es robuztez y estabilidad. Unix es un conjunto de aplicaciones pequeñas y simples, que cumplen una sola función y lo hacen bien, por ejemplo iptables o fetchmail. Microsoft Windows, sin embargo está y por lo que se deduce, estará, encadenado a ficheros .exe y actualizaciones dependientes del trabajo de un único grupo de programadores asalariados. Es cierto que con los “Boletines del Segundo Martes” intentan acercarse al ritmo de desarrollo y corrección de bugs de S.O GNU/Linux tipo Debian o Red Hat, o BSD como FreeBSD, todo indica a que su trabajo está orientado a un simple Service Pack cada X meses o años.
Mantenimiento: Una maquina Unix requiere de unos conocimientos mínimos de Administración para que las funciones que realice, las haga bien. Una vez configurada, pueden pasar años hasta que requiera un mantenimiento que se aleje del típico de la actualización de software y parches de seguridad. En multitud de ocasiones, una máquina Unix mal configurada por un/unos Administradores con conocimientos escasos del software con el que están trabajando, puede dar la impresión de necesitar más tareas o tiempo de mantenimiento que una máquina corriendo Microsoft Windows: nada más lejos de la realidad. Visite netcraft.com y o top500.org y podrá comprobar que tienen en común el 88% de los 500 computadores más “potentes” del momento: un S.O Linux. ¿Casualidad? No creo que DELL, NASA se basen en casuísticas para el elegir el S.O de sus Servidores.
Seguridad: Partiendo de la base de que ningún S.O es seguro si está conectado a una red de computadores, me gustaría hacer incapié que el concepto de Seguridad Informática es un proceso continuo y lineal, en contraposición a una series de medidas puntuales, como por ejemplo, añadir una cadena -j DROP a iptables para que “impedir que megano haga pings a fulano”. En palabras de J.Pérez Agudín “La seguridad ha de ser entendida como un equilibrio, la inversión en seguridad ha de estar a la altura de la importancia de la información a proteger”. Volviendo al eterno dilema de por qué Linux es más seguro que Microsoft Windows, me gustaría comentar:
Desarrollo continuo: la comunidad de desarrolladores trabaja a diario publicando parches y liberando nuevas versiones. No hay necesidad de esperar a que una empresa considere oportuno “vender” un nuevo producto para tener software actualizado.
Mejor diseño de S.O de base. Nos referimos en la práctica, a que por ejemplo, ante una vulnerabilidad en Postfix, si un usuario pudiese supuestamente tomar el control de la máquina, sólo lo haría con el usuario con el que se ejecute el proceso, es lo que se conoce como CHROOT o jaulas de usuario. En Microsoft Windows también es posible, pero no se ejecutan por defecto todos los procesos con usuarios diferentes.
Diversidad de Entornos: El núcleo de Windows Server es el mismo para las distintas versiones, por lo que en la práctica resulta muy sencillo aplicar un exploit a dichas versiones. Sin embargo, dada la diversidad de versiones, tanto de BSD como de Linux, un exploit en Fetchmail puede causar distintos daños o nulos dependiendo del entorno, fundamentalmente en versiones del Kernel y del software de las herramientas de seguridad configuradas en la (SELinux o AppArmor de Novell).
Dejando a un lado la disyuntiva Windows vs Unix, me gustaría dedicar unas líneas a comentar el supuesto caso de exponer una máquina a la red Internet. ¿Se puede evitar ? A mi modo de ver, la respuesta es : Sí. Un sí rotundo. En este caso concreto hablamos de una máquina que recibirá el correo directamente desde los servidores SMTP del remitente. Se presupone que el nuevo (re)diseño de la arquitectura de red resultante debe como mínimo superar las prestaciones del anterior, prestando atención, a mi modo de ver, a los siguientes puntos.
Ancho de Banda: En ningún caso, en mi opinión , se debería conectar una maquina que sirva SMTP a una línea convencional, tipo ADSL o Cable, al tratarse de líneas asíncronas no se garantiza en ningún momento un caudal mínimo, que garantice un servicio fiable. Mi recomendación son líneas simétricas de datos , SHDSL o similares.
Direccionamiento: Se presuponen unos requisitos mínimos en la calidad del servicio de la nueva instalación. El direccionamiento Ipv4 de los actuales ISP deja mucho que desear. Compruebe una dirección IP al azar de la red 0.Red-217-127-182.staticIP.rima-tde.net, podrá comprobar como “se mezclan” en el pool de direcciones tanto direcciones públicas para usuarios domésticos como usuarios de perfil empresarial. ¿ Cree realmente que este rango estará totalmente limpio en listas RBL? Mi opinión es que no.
Mantenimiento: Imagine que en un momento dado, su router cabecera, el que envía los paquetes al Firewall para que los procese y los enrute hacia su máquina de correo, recibe del orden de 15.000 correos por minuto. ¿Qué haría en este supuesto? ¿ Dispone de los activos de red necesarios para bloquear automáticamente este tráfico? ¿ Dispone de los recursos humanos necesarios para solucionar esta incidencia? En mi opinión, a no ser que el número de usuarios superase los miles(4.000 usuarios por ejemplo), confiaría la recepción del correo electrónico a un proveedor de Hosting: Arsys, Dinahosting, 1&1...etc. A menudo, estas empresas gestionan sus propios Sistemas Autónomos
“Razones rápidas por las que no implementar Exchange”.
“Exclavitud empresarial”. Si se utilizan aplicaciones liberadas bajo estándares abiertos, las actualizaciones y parches de seguridad las tendrá disponibles de forma libre y gratuíta. Por el contrario si elige Exchange Server, Microsoft Corporation no le garantizará bajo ningún concepto la frecuencia de actualizaciones, ni mucho menos, el código fuente de la aplicación. No sólo para poder modificar el código, sino para poder compilarlo específicamente para su arquitectura y “sacar” el verdadero rendimiento de la aplicación que elija como su software de Servidor SMTP.
Económicas. Impensable pagar por las diferentes versiones de una aplicación. Es más, Postfix por ejemplo, sólo libera una versión de su aplicación; virtud o defecto. Mi opinión es que es una virtud; que combina flexibilidad, al poder adaptarse tanto grandes despliegues, como a pequeños componentes de hardware, tipo routers o access points.
Seguridad. Postfix, por ejemplo, lo ha desarrollado Wietse Venema, autor de herramientas como los TCP Wrappers o el Coroner Toolkit. Es un reputado experto en seguridad informática y eso , como mínimo es una garantía de calidad. Que Red Hat, IBM o Debian GNU/Linux incluyan Posftix en su cojunto de paquetes quiere decir algo, no cree? ¿Conoce algún sistema de Bugtraq? Visite securityfocus y podrá comprobar que Exchange tiene más de 1800 reportes de errores, en contraposición a los 220 de Postfix. Si ha todo esto sumamos que Posftix, o Qmail o Sendmail o Exim corren perfectamente en GNU/Linux, Mac OS X o diversos sabores de *BSD ¿ Duda de Posftix o software similar no es seguro?.
Flexibilidad. Combinar Postfix con Spamassassin o ClamAV es un ejemplo de flexibilidad. Empresas como este o Kaspersky han desarrollado versiones específicas de sus productos.¿Cree realmente que si este producto no tuviese la calidad suficiente, estas empresas habrían desarrollado versiones para GNU/Linux o BSD?
Estándares: Unos de las características fundamentales en el desarrollo de aplicaciones libres es el cumplimiento, estricto en la mayoría de las ocasiones, de estándares de programación y comunicaciones.
Virus. Hablar de correos electrónicos es hablar de virus. Una máquina Unix no se bloqueará por que el virus X se adjunte al correo Y.
Alberto Permuy Leal
Agosto 2009
Suscribirse a:
Entradas (Atom)