Inicio > Mis eListas > infohackers > Mensajes

 Índice de Mensajes 
 Mensajes 101 al 120 
AsuntoAutor
informativos.info infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info Infohack
informativos.info infohack
informativos.info infohack
Informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
informativos.info infohack
 << 20 ant. | 20 sig. >>
 
Infohackers.org
Página principal    Mensajes | Enviar Mensaje | Ficheros | Datos | Encuestas | Eventos | Mis Preferencias

Mostrando mensaje 155     < Anterior | Siguiente >
Responder a este mensaje
Asunto:[boletín_informativos] informativos.info #143
Fecha:Domingo, 19 de Septiembre, 2004  20:22:16 (+0200)
Autor:infohackers <infohackers @...........org>

Mensaje

 

Editado por AIH: www.infohackers.org

Boletín informativos.info

4.718 subscriptores

Boletín número 143

Hacktivismo y seguridad

19 de Septiembre de 2004


Sumario
 

Opinión: Monocultivos
 


Hace ya tiempo que se viene comentando por la red los peligros del monocultivo. No importa el sistema operativo que elijamos: si más del 90% de las máquinas lo usan, el peligro de que una vulnerabilidad crítica no parcheada se extienda es más que real. Los casos de CodeRed, Blaster, Sasser y la multitud de virus basados en Outlook Express e Internet Explorer lo prueban. Si creemos que la solución sería usar Linux o MacOS, por decir dos de los sistemas alternativos a Windows más usados, caeríamos en el error. Un fallo en el kernel Linux o en el núcleo del MacOS (y existen, no hay más que leer las noticias) nos llevaría a la misma situación si estos sistemas ocupasen la misma posición dominante que tiene en la actualidad Windows.

Queda claro, pues, que para la mayor seguridad de la Red, es conveniente que haya de todo. ¿Y para nuestra red interna? Si lo planteamos como usuario doméstico o de una pequeña empresa, es indiferente. Con un escaso número de máquinas, la caída de un único sistema posiblemente sea catastrófica, desde nuestro punto de vista. Pero, ¿y si tenemos 100 máquinas?. En este caso, nos encontramos ante la disyuntiva de elegir entre la facilidad de administración de usar un sistema homogéneo o la mayor seguridad para la continuidad de funcionamiento de varios sistemas distintos.

Hasta hace pocos años, la balanza se inclinaba de forma clara hacia la homogeneización. Las disparidades entre sistemas basados en Microsoft, los diversos tipos de *nix y los de la compañía de la manzana hacían muy difícil, sino imposible, montar una red heterogénea. En la mayor parte de los casos, para simplemente compartir archivos era necesario recurrir a software de terceras compañías, en ocasiones limitado o simplemente con una tasa de fallos muy elevada, por no hablar del coste adicional en licencias y mantenimiento. Por lo tanto, quedaba clara la dificultad de instaurar un sistema de directorio centralizado o un login único.

Hoy en día las cosas han cambiado. Todos los sistemas han ido migrando a una interoperatibilidad entre si, con soluciones como Samba (integrado en la mayor parte de las distribuciones de Linux y en MacOS X) , MS Services for Unix o MS Services for Macintosh. El protocolo estándar LDAP se ha incluido en los principales sistemas como servicio de directorios. LPR/LPD para impresión son soportados por la práctica totalidad de los sistemas. Incluso la tendencia a trasladar las aplicaciones a web ha facilitado mucho la cosa. Hoy es sencillo configurar un sistema para  acceder desde un Macintosh a una aplicación web ASP corriendo en W2k3/IIS contra una base de datos MySQL sobre Debian. La compatibilidad (no total, pero si suficiente) entre los documentos MS Office y OpenOffice.org permiten mayor libertad a la hora de elegir la suite ofimática. En casi todos los sistemas es fácil implementar scripts automáticos que, en general, serán fácilmente portables. Todo esto facilita enormemente la administración cruzada de sistemas heterogéneos.

Así pues, la pregunta en el aire es: ¿Ha llegado la hora de acabar con el monocultivo en la organización?

Luisma.
Miembro de la AIH.

   

Introducción a linux: level9
 


Bienvenidos a la última entrega de nuestro curso de Linux. En ella hablaremos de cómo crearnos nuestro propio Linux. Veremos la verdadera fuerza del código abierto creando los comandos que acepta nuestra shell mediante el comando ALIAS y nos crearemos asimismo un conjunto de órdenes de más sencillo manejo para nuestro Linux.

Todos hemos pasado alguna vez por el mal trago de pensar : " cómo leñes se escribia esto ?. " y por frustración acabábamos poniendo las órdenes en castellano en la shell y mandando tras varios mensajes de error a un lugar no demasiado agradable a Linux. Sí, ya sé que para eso está el man pero no es cuestión de estar maneando la perdiz a todas horas.

Pues bien, para evitar todo esto tenemos el comando "alias" :


kaskade@UnderworldDreams:~$ alias borrame='rm'
kaskade@UnderworldDreams:~$ ls
archivo1
kaskade@UnderworldDreams:~$ borrame archivo1
kaskade@UnderworldDreams:~$ls
kaskade@UnderworldDreams:~$


Con este sencillo comando, le damos a los comandos de la shell el nombre que nosotros queramos e incluso podemos asociar comandos sencillos a expresiones :

kaskade@UnderworldDreams:~$ alias copiate='cp -R'
kaskade@UnderworldDreams:~$ copiate /home/kaskade/curso_linux /home/kaskade/prueba
kaskade@UnderworldDreams:~$ alias listame='ls'
kaskade@UnderworldDreams:~$ listame /home/kaskade/curso_linux
carpeta_levels level_actual
kaskade@UnderworldDreams:~$ listame /home/kaskade/prueba
carpeta_levels level_actual

Y mi pregunta es ... podemos rizar el rizo con las preposiciones ?

kaskade@UnderworldDreams:~$ alias en=''

Con lo cual lo anterior se podría haber escrito como :

kaskade@UnderworldDreams:~$ copiate /home/kaskade/curso_linux en /home/kaskade/prueba

El único problema que tiene esto es que se guarda en memoria. Si queremos que una vez asociados nuestros comandos a los comandos de UNIX éstos permanezcan imborrables, tendremos que añadir al .bash_profile del usuario que va a usar esos comandos las sentencias alias que hayamos creado. Si queremos que éstas estén disponibles para todos los usuarios, basta con copiarlas en el /etc/bashrc

Conclusión : En un sistema como Linux código abierto, el saber manejarlo solo depende de nosotros. Sin duda una vez maqueado, usarlo es mucho más sencillo que cualquier otro sistema principalmente porque nosotros hacemos que funcione como nosotros queremos y lo adaptamos a como más sencillo nos es. Para prueba un botón:

Un servidor clama enlightenment por ser el escritorio más sencillo que jamás ha probado. Si habéis visitado alguna vez un cibercafé con algún sistema como rembo o alguno de estos en los que el escritorio solo tiene lo indispensable para su funcionamiento, entonces me entenderéis cuando os diga que enlightenment no tiene ni un solo icono en el escritorio, ni una sola barra .... nada. Todo lo manejas desde el menú contextual del ratón encima del escritorio precisamente porque tú mismo editas ese menú para que tenga solo lo que necesitas. Normalmente con poner las aplicaciones y los atajos a algún menú de configuración es más que suficiente para un servidor. Nunca usar un pc había sido tan simple y rápido como botón derecho --- > click en el programa a ejecutar.

Y hasta aquí el curso de Linux. Espero encarecidamente que alguno de nuestros lectores se esté dando de cabezazos contra Linux y aprendiendo para poder llegar a tener un sistema a su medida con el que pueda trabajar como él desearía sin ningún tipo de problema. Y sobretodo espero que siquiera alguna de las entregas le haya servido a algún avezado redandante ( antiwamente se les llamaba viandantes, los tiempos cambian :P ) para solucionar algún a primera vista insoluble problema.

Un abrazo a todo el mundo y sugerencias a : kaskade@infohackers.net

Hasta siempre !!!!


Kaskade y Belyt
Miembros de la AIH


Resumen de noticias de la semana
 


Denegación de servicio en Samba

La implementación Open Source del protocolo SMB/NetBIOS, Samba, es vulnerable a ataques de denegación de servicio a través de dos fallos en dos de sus daemons.

Fallos en el kernel de Linux

Dos fallos se han descubierto recientemente en el kernel de Linux que pueden llevar a la ejecución de código remoto con privilegios de root, en el caso peor.

Fallo de seguridad en el iChat de Apple

Apple ha publicado una actualización para su software de mensajería instantánea iChat.

El virus parlanchín

Un nuevo virus, el Amus, se está empezando a extender, aunque con baja intensidad. No sería noticia si no fuera de los primeros en usar las facilidades de reproducción oral.

Actualizaciones de seguridad de Microsoft

En sus ya tradicionales actualizaciones del segundo martes, Microsoft ha publicado dos este mes de Septiembre, correspondientes a un fallo crítico en la interpretación de JPG y otro en el filtro de conversión de Wordperfect.

SQL injection en vBulletin

Un error en la implementación de vBulletin lo hace vulnerable a ataques SQL injection.

 


El correo del lector
 


Esta semana no hemos recibido nada en el correo del lector. Os animamos a seguir participando.

Queremos, además, pediros perdón por un fallo humano que ha propiciado la distribución de un mensaje de spam a través del medio que usamos para este boletín. Procuraremos que no se vuelva a repetir.



Don
Miembro de la AIH

Copyright 2001-2004 - A.I.H.  Todos los derechos reservados. .

Para envío de noticias: informativos@infohackers.net.
Para envío de sugerencias y preguntas: el_lector@infohackers.net

Desarrollado por la A.l.H. - www.infohackers.org
Para darte de baja, envía un correo a la dirección: infohackers-baja@eListas.net

Para darte de alta, envía un correo a la dirección: infohackers-alta@eListas.net
Los números anteriores de este boletín se pueden consultar en elistas.net.
 






[Adjunto no mostrado: 6/ (application/octet-stream) ]
[Adjunto no mostrado: 5/ (application/octet-stream) ]
[Adjunto no mostrado: 3/ (application/octet-stream) ]
[Adjunto no mostrado: 4/ (application/octet-stream) ]
[Adjunto no mostrado: 2/ (application/octet-stream) ]
[Adjunto no mostrado: 1/ (application/octet-stream) ]