Usuarios de ordenadores con Mac OS X y linux fueron advertidos este fin de semana de que extremaran precauciones debido a un nuevo software malicioso que podría convertir sus ordenadores en ordenadores "zombis". Kaspersky Labs declaró que esta aplicación es multiplataforma y que también puede ejecutarse en ordenadores con Windows instalado.
#15 Todo el mundo hace bromas con el rm -rf /, pero cuanta gente lo ha probado? Curiosamente, si lo pruebas en una terminal, GNU/Linux te avisa HASTA TRES VECES, que lo que quieres hacer ES UNA PUTA LOCURA. Pero en fin, sigamos riendo la broma, no?
#22 ya lo dijo Spiderman: un gran poder conlleva una gran responsabilidad. Yo los sistemas operativos quiero que me dejen hacer todo, que ya me cuidaré yo de usarlo bien. La otra opción, que el sistema operativo te limite, va bien en algunos casos, pero al trabajar con ellos resulta molesto.
#19#20 Sin entrar en medidas complejas de seguridad que podrían ayudar en el tema de la seguridad (SELinux, Grsecurity, firmado de binarios, unhide, y otras), el simple hecho de usar 2 cuentas de usuario sin privilegios o utilizar un entorno "seguro" tipo kvm o lxc para probar nuevos programas o añadidos, ya supone librarse de un daño de la información privada importante.
Es posible usar 2 usuarios sin privilegios de modo que uno se usa para "cosas serias" y bien probadas (de fuentes fiables), y el otro usuario se usa para probar cosas de las que no sabemos bien si son fiables (paginas web con scripts, añadidos al navegador, programas binarios, etc...).
Además si disponemos de programas sniffers y traceadores de redes, se puede comprobar toda conexión saliente hacia fuera de nuestro equipo y de donde parte (puertos, programa, sockets, etc...).
Nadie se cree que no exista malware/virus/lo que sea/ para Linux, solo que teniendo un minimo de conocimientos y de seguridad, es muy improbable ser "contagiado" con algo.
Personalmente puedo asegurar que llevo mas de 13 años usando Linux como unico sistema (en un 95% de las veces). He instalado y he usado decenas de distribuciones con muchos programas de todo tipo (tanto abiertos/libres como binarios privativos y de dudosa procedencia). Nunca nunca nunca me he encontrado con un solo comportamiento destructivo o raro en mis sistemas ni mal funcionamientos debidos a esos virus/gusanos/malwares/etc. Puede que haya tenido suerte, pero no sera por haber puesto mucho cuidado.
#24 Es más complicado si sabes con lo que trabajas, está claro, pero es que el objetivo de un malware que quiere hacer un botnet (como este) es tener el máximo número de targets posibles, y evidentemente los usuarios técnicos, que son más difíciles de infectar, no son el principal objetivo.
De todas formas, pongo un par de pegas a lo que dices.
A lo primero, dos usuarios sin privilegios hoy en día en cualquier distribución no significa seguridad, porque los usuarios, repito, hoy en día, tienen acceso a cosas que antes era impensable para un usuario sin privilegios, hay un montón de servicios que se han transladado para bien o para mal al espacio de usuario. Ejemplos: el control de los dispositivos de red, el montaje de sistemas de ficheros, incluso iniciar/apagar el equipo, etc etc..
Puedes hacer tu usuarios con menos privilegios? claro, pero esto ya no es el comportamiento por defecto en la mayoría de las distribuciones.
editado:
releyendo esto, incluso podría decir que ni un jail sería 100% seguro, una VM si, pero no vas a tener una VM de sandbox para ir probando todo lo que usas. Yo tengo en el curro una de cuckoo para temas de malware, pero solo la uso cuando trabajo con muestras conocidas, no para el día a día.
A lo segundo, un rootkit por ejemplo, te ocultaría las conexiones salientes y entrantes, procesos, etc.. tendrías que hacer la captura fuera de tu equipo para que fuera realmente fiable, y .. siendo sinceros, capturar el tráfico raw de la red salvo que sospeches algo o estés haciendo alguna prueba concreta no es algo que se haga muy a menudo.
Por otra parte, aunque pudieras detectar el tráfico, primero debes separarlo de las conexiones legítimas, y seguramente esté ofuscado de alguna manera para que no puedas saber lo que hace. Como mínimo te llevaría mucho tiempo.
Y a lo tercero, un poco siguiendo este hilo, yo también llevo muchos años dedicándome a esto, y en concreto a la parte de seguridad llevo un buen tiempo y lo que puedo decir es que espero, o deseo, que nunca hubiera sido infectado en ningún sistema, pero la estadística es muy tozuda y.. saber!
Por cierto, todas las medidas de seguridad que mencionas ayudan, pero desde luego no evitan comportamientos maliciosos en todos los programas que metas en el equipo.
# pfctl -a '*' -sr
block drop all
pass all flags S/SA
block drop in on ! lo0 proto tcp from any to any port 6000:6010
pass out quick on re0 proto tcp from any to any port = 51413 flags S/SA
pass out quick on re0 proto udp from any to any port = 51413
pass in quick on re0 proto tcp from any to any port = 51413 flags S/SA
pass in quick on re0 proto udp from any to any port = 51413
pass out on re0 proto tcp all flags S/SA modulate state
pass in on re0 proto tcp from any to any port 5000:5100 flags S/SA
pass in on re0 proto tcp from any to any port 3748:3749 flags S/SA
pass in on re0 proto tcp from any to any port = 1270 flags S/SA
pass in on re0 proto tcp from any to any port = 80 flags S/SA
pass in on re0 proto tcp from any to any port = 443 flags S/SA
pass in on re0 proto tcp from any to any port = 22 flags S/SA
pass in on re0 proto udp from any to any port 5000:5100
pass in on re0 proto udp from any to any port 3748:3749
pass in on re0 proto udp from any to any port = 1270
pass out on re0 proto tcp from any to any port 5000:5100 flags S/SA
pass out on re0 proto tcp from any to any port 3748:3749 flags S/SA
pass out on re0 proto tcp from any to any port = 1270 flags S/SA
#28#30 El funcionamiento es esencialmente el mismo, de hecho en el artículo se habla de un malware basado en Java, así que la comparación me parece bastante relevante, portar el código de un sistema a otro es trivial.
#26
Un botnet como este establece la conexión desde tu equipo a un C&C, lo puede hacer a través de una web, de un server IRC, de un protocolo propio.. es imposible que con un firewall puedas discriminar una conexión de un software como este de uno legítimo, es simplificar demasiado.
y comprobad que no es un tema tan simple como "no le doy permisos y listo", porque algunos aprovechan vulnerabilidades conocidas, que pasa si un día se extiende uno y el sistema o la aplicación de la que aprovecha el fallo no está parcheado todavía? o si sacan algo que aproveche un 0day, pues que estás tan vendido como en cualquier otro sistema.
También se puede ver algo sobre las mecánicas de la comunicación con los C&C, como se ofusca, cifra y pone todos los medios para pasar inadvertido.
Por cierto #28, no se puede ser tan talibán, si vas a discutir con argumentos perfecto, si no deja de hacer ruido, gracias.
#31 en mi android no hay /etc/init.d/ así que será todo lo trivial que quieras, pero hay que hacerla. Pero vamos, si la cosa es poner pegas hasta que tengas la razón, no pasa nada, te la doy para que quedes contento y lo dejamos aquí. Yo entro en estos hilos porque me gusta leer y comentar cosas de seguridad, no a hacer peleas de egos.
#32 Peleas de egos?, tener la razón? pero de que hablas? tener la razón sobre que?
Si comenté algo es para aportar información bastante útil sobre el estado del malware en sistemas Linux que es evidente que la mayoría no conoce, por la prepotencia con la que se habla, ya me dirás en que quiero "tener la razón" :-?
Mi mención a android viene por los comentarios que se ríen del malware en Linux, como si fuera un sistema invulnerable.
Pongo el ejemplo de Android para demostrar que un sistema basado en Linux puede ser tan vulnerable como cualquier otro, pero también pongo ejemplos para Linux y BSD de escritorio en el enlace de #31.
Es curioso por cierto, porque en #18 hablas de que los virus de linux solo existen de oidas, etc, y que te gusta entrar en estos hilos a comentar cosas de seguridad, pero pongo un enlace a un foro donde puedes descargarte ese malware para linux, y la gente lo estudia y lo comenta y entonces el tema se convierte en una pelea de egos, impresionante.
#35 Me temo que no hemos interpretado la línea argumental del mismo modo. Disculpa si eso.
El malware es distinto de un virus porque hacer un malware es trivial, pero gracias por el enlace, le echaré un vistazo.
#25 Es cierto que Linux no es invulnerable (y creo que ningún sistema es invulnerable). Pero también es cierto que teniendo un poco de cuidado en usar fuentes confiables y usando un usuario sin privilegios es bastante improbable ser infectado por algún tipo de malware. No digo que no pueda ocurrir, pero hoy por hoy es improbable. Afortunadamente la mayoría de distribuciones disponen de mucho software, haciendo innecesario buscar programas por otras vias menos seguras. Por supuesto que algunas distribuciones deberán ponerse un poco las pilas en temas de seguridad, pero las herramientas existen. Como tu bien dices, mucho problema se debe al tema de permisos y privilegios.
El tema de los rootkits es muy antiguo y teniendo una maquina con ciertas medidas de seguridad se hace bastante dificil ser infectado. Sin dedicarme a la seguridad se me ocurren algunas medidas tan sencillas como por ejemplo: firma de binarios (bsign) o particiones importantes del sistema (/bin, /etc, /sbin, /usr, etc), que no se suelen modificar mucho salvo en actualizaciones, pueden ser instaladas en discos duros o dispositivos con protección contra escritura por hardware (via switch o boton fisico), con lo cual el rootkit pocos ficheros importantes del sistema podra suplantar y/o modificar. Todo eso sin hablar de parches o medidas mas sofisticadas como SELinux, PaX, etc.
Luego tienes utilidades como rkhunter, unhide, IDS/IPS, etc, que también pueden ayudar. Alguien con suficientes conocimientos puede crear daemons o procesos ocultos que controlen ciertos aspectos del sistema y emitan ciertas alarmas o avisos al usuario administrador.
Suponiendo que ya estés infectado por un rootkit o algo y logren ocultar las transmisiones o algo por estilo, si sera interesante disponer de algún sniffer o parecido, que este a la salida de ese sistema controlando el trafico saliente (no solo su contenido, sino puertos/protocolos o direcciones, aplicación que lo ha creado, etc...) y supongo que se puede averiguar si existe algún software malicioso que esta mandando información al exterior si el usuario sabe bien que es lo que se esta usando y que servicios de su sistema están activos y usando conexiones (también digo yo que se podrá limitar todo trafico o servicios posibles y con el sniffer externo comprobar si se sigue transmitiendo hacia el exterior en algún momento registrando todo trafico con logs o lo que sea).
#37 Uf, son medidas muy estrictas para un sistema que pretenda ser de uso general, muchas veces se dejan de lado soluciones muy eficaces porque en la práctica presentan muchos problemas de utilización.
Por ejemplo, algunos problemas:
- Con lo de proteger contra escritura las particiones: el usuario tiene que cambiar el comportamiento muy a menudo, en cada actualización (hay actualizaciones diarias de software), cada cambio es una posibilidad de infección.
- ¿Cómo discrimina el usuario el software "bueno" del "malo"?. Claro si solo instalas cosas de los repositorios (y confias en ellos, porque esto sería otro tema que daría para otro debate inacabable), entonces ok, pero esto en un sistema de escritorio, que suelen ser los objetivos de los creadores de malware (muchos datos personales, mucha info para vender..), es poco probable, porque el usuario siempre querrá instalarse el último steam, spotify, juego o driver de la gráfica que no estará en la distro.
- ¿Quién firma los binarios? y ¿cómo consigues la clave pública de quien lo firma?. Por ejemplo el sistema de firma de repos de debian/ubuntu está guay, pero se puede hacer un MiTM a la hora de que el usuario se descargue la clave PGP de un repo, y meterle después software malicioso a voluntad. Puede parecer exagerado, pero solo hay que pensar en 2 ejemplos: Stuxnet y Flame se distribuyeron como actualizaciones.. de Windows!!! y firmadas!!! con un certificado valido!!!(!uno!!111!). A mi eso me parece demoledor, por ejemplo. Remote code execution firmado.
- Un IDS o los chkrootkits y similares solo buscan amenazas conocidas basándose en firmas, el análisis de comportamientos está muy muy muy verde y las amenazas nuevas y/o ofuscadas ni las huelen. Igual que los antivirus, que están en horas bastante bajas.
Y así, al final está claro que una combinación de todo+educación del usuario ayuda, pero a lo que iba yo es que el sistema no es mejor o peor por ser Linux, todo tiene sus problemas y la experiencia nos está diciendo que si no hay más infecciones es por rentabilidad, no tanto por seguridad, que es lo que se pensaba hace unos años.
En cuanto a lo del sniffer, es un tema que me interesa mucho particularmente, la verdad, y la mejor solución que he visto es una basada en flows de tráfico (un sniffer sería demasiado, porque a ver quien analiza todo eso en una red un poco grande), y análisis basados en estadística para detectar comportamientos sospechosos en el tráfico.
#38 Para hacer un MITM debes estar en la misma red. A parte que el sistema de seguridad de Windows es de todo menos eso.
Luego ya sobre seguridad... mi sistema lo tienen bastante jodido para atacar. Los únicos ports que uso son dos juegos. No tengo servicios arrancados y PF hace su trabajo demasiado bien.
#39 No, un MiTM se puede hacer sin estar en la misma red perfectamente, solo que es más fácil así claro, pero puedes hacerlo por ejemplo si:
- Consigues inyectar una ruta
- Envenenar las resoluciones DNS
- Ponerte en cualquiera de los saltos intermedios
- Tomar control del sistema al que te conectas
, etc
Casi todas las opciones se pueden hacer con malware de diversos tipos, hay muchos muy sencillos que por ejemplo te cambian el hosts, o te redirigen a un DNS falso, y luego haces ya el MiTM o lo que sea. El propio ISP te puede hacer un MiTM, o la NSA (ala, conspiranoia time.. ah no, es que ya ha pasado realmente, ver por ejemplo el caso de Francia falsificando certificados SSL de google con una certificadora propia, para que los querian? pues eso, para hacer ellos un MiTM con cert verificado incluido)
#40 No quiero hacer spam, así que no voy a dar más datos, si interesa se puede buscar fácil de lo que hablo, pero justo esta semana vamos a sacar una entrega de un podcast en el que colaboro y en la entrega pasada le hicimos (le hice) una entrevista a Richard Stallman, que por supuesto abordó el tema del malware desde ese punto de vista que propones: "Cualquier software del que no puedas ver la fuente es malware", ese es su resumen básicamente, porque no puedes comprobar las fuentes etc.
Pero en el que vamos a sacar hoy (o mañana) le hicimos una entrevista a un experto en malware de la Universidad de Kiev, y le preguntamos que le parecía la conclusión de Stallman, y nos hacía una reflexión muy interesante, que se podría resumir en ... cualquier programa se puede desensamblar y ver su comportamiento (bueno, el lo podrá hacer fácilmente a los humanos nos cuesta un poco más), ¿por qué no se hace siempre? porque las líneas de ensamblador serían millones, y es demasiado. Pero el kernel de Linux, por ejemplo, tiene ahora mismo 17 millones de líneas de código, NADIE, nisiquiera Tolvards, ni RMS, nisiquiera los que mantienen los paquetes en las distribuciones, se han leido TODO el código, más bien es un sistema de confianzas en cadena, en el que cada uno tiene una reputación y se confía en que los cambios que haga no son maliciosos, si un desarrollador metiera código malicioso en el kernel, se tardaría meses o años en dar con el, como pasa con los bugs no-intencionados que se aprovechan como vulnarabilidades (no hay diferencia técnica entre una cosa y la otra, de hecho, no es que el malintencionado ponga begin.backdoor, etc). La única ventaja del tinglado este, es que si se sabe o se sospecha que un desarrollador mete código "malo" demasiado a menudo o a propósito se pueden separar los cambios del resto, pero vamos, que realmente open-source no es garantía de nada por si solo.
Con todo esto no quiero dar a entender que es lo mismo una cosa que otra, es evidente que es infinitamente mejor tener acceso al código fuente, pero quiero dejar claro lo importante que es no confiarse demasiado, porque los motivos que se dan a veces no son suficientes para no tomar precauciones, y lo malo es que se hace.
#41 " Pero el kernel de Linux, por ejemplo, tiene ahora mismo 17 millones de líneas de código, NADIE, nisiquiera Tolvards, ni RMS, nisiquiera los que mantienen los paquetes en las distribuciones, se han leido TODO el código, "
No uso Linux, uso openbsd, donde cada binario está compilado por el equipo de éste para funcionar, sustituyendo funciones inseguras por seguras.
EL código BSD es mucho más simple, por cierto, a nivel de kernel/userland que el de GNU/Linux. Lo digo sin trollear desde ya. Para auditarlo lo tienen mucho más facil, y más siendo OpenBSD un sistema operativo completo.
#42 Aún así, estamos hablando de cantidades ingentes de código.
Sólo piensa una cosa: Se descubren X vulnerabilidades cada mes, todas ellas han sido causadas por fallos de programación, ¿o no?, ¿y si alguno de ellos ha sido intencionado?
Es que a mi pensar que todo el mundo es bueno no me encaja, parece que los desarrolladores de opensource son distintos de la gente que vemos todos los días por la calle, en la tele, etc.. y no es así, alguno con mala idea o intereses habrá, y puede decir: aquí me voy a "olvidar" de programar un rato, y se podrá aprovechar eso para ejecutar código remoto haciendo X. Eso es un backdoor, no lo que la gente piensa que es :
Un ejemplo: http://en.wikipedia.org/wiki/NSAKEY -> en serio? haces un backdoor para la NSA y le llamas a la clave nsakey?, a mi me parece poco..creible..
#43 "Sólo piensa una cosa: Se descubren X vulnerabilidades cada mes, todas ellas han sido causadas por fallos de programación, ¿o no?, ¿y si alguno de ellos ha sido intencionado? "
En OpenBSD se lo piensan muy mucho sobre qué funcion meter. En serio, no entra cualquier mierda
"(yo tampoco lo digo por trolear, no quiero entrar en un neverending flame de licencias )"
Más que licencia, filosofía de diseño. Por licencia me gusta más GNU, pero prefiero OpenBSD, está todo muy simplificado y documentado.
#44 Pero puestos a minimizar codigo, para eso usamos Minix y asunto arreglado. OpenBSD que yo sepa no implementa MAC, y confian plenamente en su "limpieza de codigo". Yo personalmente creo que el codigo 100% libre de bugs/vulnerabilidades es casi una utopia. Creo que son necesarias otras medidas para minimizar riesgos como por ejemplo algunas de las que soporta Linux (Grsecurity, RSBAC, SElinux, apparmor, etc...).
#46 Tenemos jaulas en OpenBSD, NGINX se configura así por defecto. Y con MYSQL, otro tanto.
"hacer malfuncionar (o envenenar) la tabla de enrutamiento de alguno de los equipos que participan en la comunicación."
Con PF podemos desactivar eso. Tablas estáticas en plan paranoico como añadido. Buena suerte.
" (ya que lo mencionas, en la herramienta española Evil Foca implementaron algunos ataques IPv6 para hacer MiTM, y así.. la única solución para evitarlo es cifrar de extremo "
Idem. Con PF bien configudo ya pueden intentarlo, ya.
#48 Yo también se asegurar un sistema para que ciertos tipos de ataques no se produzcan, BSD, Linux o.. pero es imposible hacerlo invulnerable a todo porque a veces el usuario "colabora" o porque se aprovecha el funcionamiento del propio stack de comunicaciones para, en el caso de que no esté bien configurado, desatar comportamientos inesperados.
Que jo, en serio que no le tengo manía a OpenBSD, pero tal y como lo dices parece que lo instalas y es invulnerable, porque es muy seguro y muy guay, yo me alegro por tus sistemas, que parece que los aseguras bastante, no es mi intención decir lo contrario, sino llamar la atención con que muchos comportamientos por defecto de los sistemas, muchas veces sin intervención del usuario, o a veces con su "colaboración", pueden dar lugar a comportamientos no deseados, sea el sistema el que sea.
De todas formas, ya un poco por.. la semana que viene tengo que hacer unos labs de seguridad con unos alumnos, y ahora por curiosidad simplemente voy a poner OpenBSD en los clientes, a ver como responden, te mando ya las "gracias" de su parte que seguro que les hace mucha ilusión, je je .
#50 "a semana que viene tengo que hacer unos labs de seguridad con unos alumnos, y ahora por curiosidad simplemente voy a poner OpenBSD en los clientes, a ver como responden, te mando ya las "gracias" de su parte que seguro que les hace mucha ilusión, je je . "
Ya pueden configurarlos bien. Por defecto no están activas las SoftUpdates en el sistema de ficheros en fstab y la E/S es lenta sin ellos.
Sí, es una jodienda, pero se hace para soportar equipos muy muy limitados por defecto Y bueno, en rendimiento GNU/Linux es algo superior, pero en redes... PF es una verdadera pasada, y NGINX parcheado mola muchísimo.
Ah, y la documentación, "man afterboot" y "ls /usr/loca/share/doc/pkg-readmes". Todo está documentado. Todo binario, todo servicio y toda configuración en /etc.
#52 "Habra que ver el nuevo nptables de Linux para compararlo con PF." Por filosofía, espero que no sea algo ultrarecargado con parches, como lo de GNU.
#55 Me refiero al diseño y userland en general. Si nos ponemos en líneas generales...
GNU intenta crear un sistema parecido a Emacs. Demonios, procesos paralelos y miles de opciones para que todo el mundo esté contento según su modo de trabajar.
BSD hace lo mismo, pero a lo Vi. Espartano y simple, pero una vez configurado no lo tocas aunque actualices 8 veces en 4 años.
#59 Yo creo que Emacs te puede servir también para sysadmin. Lo primero es que tiene modos que emulan a VI. Luego tiene shell propia, permite sesiones en remoto. Dispone de emacsclient. Y la potencia y versatilidad que tiene Elisp no la tiene Vim ni de lejos. Ahora querían para la versión 25 de Emacs usar Guile y quizás scheme para sustituir a Elisp y darle capacidad de multihebra a Emacs. Ojala lo hagan y mientras sigan teniendo un Lisp en tiempo real para Emacs, seguirá siendo tan poderoso. Lisp es muy potente, tanto que hoy día lo siguen intentando imitar o copiar sus caracteristicas. Permite incluso modificarse a si mismo (su código) en tiempo de ejecución y dispone de compiladores e interpretes. Lastima que sea un poco complicado de entender y usar.
#61 VI, la mayor ventaja creo que es la de estar en todo UNIX viviente. Luego creo que sus teclas por defecto pueden ser mas "intuitivas" o rapidas que las de Emacs por defecto y darle mucho a ESC, . VI/Vim es util y rapido, pero en comparación a Emacs creo que solo le queda la virtud de estar instalado por defecto en muchos sistemas.
El mg es un microemacs no?
Es necesario sed si se tiene Perl?
En Linux creo que también viene instalado siempre por defecto Python (Ruby no se...).
En BSD viene Python por defecto?
Y por que elegir de los BSD a OpenBSD teniendo algo tan potente y a la vez seguro o versatil como FreeBSD??? Creo que si eligiera un BSD, seguro que seria FreeBSD. Creo que tenían un proyecto llamado TrustedBSD o algo así con FreeBSD (algo parecido a HardenedGentoo).
No, pero entre lanzar un binario a un intérprete, pues lo que mejor me vaya.
"En Linux creo que también viene instalado siempre por defecto Python (Ruby no se...).
En BSD viene Python por defecto?"
En OpenBSD no . En los demás, no sé.
"Y por que elegir de los BSD a OpenBSD teniendo algo tan potente y a la vez seguro o versatil como FreeBSD???"
Documentación, parcheo de la casa de binarios, PF, y que los ports se evitan en la medida de lo posible, así que casi todo está ya precompilado.
Y la sencillez, a años luz. De seguridad no hablo pues es redundante.
Y digo la documentación por que es el mejor UNIX documentado de lejos, y el más sencillo de administrar. En FreeBSD actualizando los flavors de los ports te puedes morir. En OpenBSD tengo que hacer 3 cosas, 2 de ellas scripts:
cvsupgrade; reboot.
makeworld; reboot.
pkg_add -vui. Fin de la historia.
#64 Y NetBSD? Parece también un sistema muy bien documentado y con código muy limpio. Creo que puede ser algo entre OpenBSD y FreeBSD (entre seguridad y rendimiento). Además me parece que OpenBSD era un fork de NetBSD, no?
Y expect o Tcl lo has usado alguna vez? he oido cosas buenas de expect para automatización pero nunca lo he probado.
No me cabe duda de que OpenBSD es un muy buen sistema y los BSD en general (aunque solo he usado un poco FreeBSD). Lo importante es que son sistemas abiertos y derivados de Unix que sigue siendo un muy buen sistema, cada uno con sus pros y sus menos pros, pero que funcionan de forma muy parecida y con arquitectura muy similar (al igual que Linux). Es por eso que me resulta tan difícil manejarme en Windows. Estoy tan acostumbrado al sistema tipo "Unix" que me ponen un Windows con su diseño o estructura y sus utilidades del sistema tan "liosas", y no se hacer casi nada que no sea trivial.
#68 " Y NetBSD? Parece también un sistema muy bien documentado y con código muy limpio. Creo que puede ser algo entre OpenBSD y FreeBSD (entre seguridad y rendimiento). Además me parece que OpenBSD era un fork de NetBSD, no?"
Buffff. Es muy bueno en máquinas antiguas, y el consumo de recursos es muy muy bajo, menos que un Debian LXDE, casi como Windows 98, pero depende de un huevo de ports que hay que compilar desde PKGSRC .
Amén que OpenBSD tiene DRI/KMS en el kernel.
Me gusta más OpenBSD por los binarios que ofertan. Los único port que tengo compilado es el Eduke32.
"s por eso que me resulta tan difícil manejarme en Windows. Estoy tan acostumbrado al sistema tipo "Unix" que me ponen un Windows con su diseño o estructura y sus utilidades del sistema tan "liosas", y no se hacer casi nada que no sea trivial."
En OpenBSD lo tienes todo tan extremadamente facil con los ficheros que te he dicho que tienes un NGINX con MYSQL tan rápido o más que Debian.
Configuras un poco sysctl, rc.conf, fstab para los softupdates y lees los pkg-readmes y es literalmente... copiar y pegar los comandos que te indican, por ejemplo, para configurar un OAMP.
En NetBSD hay que compilar todo, y en FreeBSD... es muchísimo más complejo que OpenBSD y también hay que compilar un huevo de cosas.
#69 Por cierto, ¿cuanto tiempo/años da soporte OpenBSD a sus distribución "STABLE"?
Hablas de las distribuciones basadas en codigo (que hay que compilar), como si fueran un problema. Yo no lo veo así. Si es cierto que pueden ser mas lentas de instalar/adaptar, pero pueden ser igual de seguras y muy rapidas o personalizables. FreeBSD creo que dispone de ambos metodos (Ports y paquetes compilados), no?
Y que te parece una Slackware donde no se parchea nada y se confía en los paquetes originales de sus propios desarrolladores? a fin de cuentas son los propios desarrolladores los que mejor conocen sus programas y también a los que se les informa de bugs encontrados para arreglarlos en siguientes versiones y tal.
Ports = se baja el código fuente de fuera, y se compila.
Paquetes. Se compila dentro de la rama de paquetes, y se asegura que esté ultraparcheado para ser estable y a prueba de bugs.
"FreeBSD creo que dispone de ambos metodos (Ports y paquetes compilados), no?"
En OpenBSD lo normal es meter binarios; en FreeBSD casi todo lo "avanzado" se recomienda recompilar.
De hecho, en OpenBSD la filosofía es "just works". Sin make show=FLAVORS ni leches.
"Por cierto, ¿cuanto tiempo/años da soporte OpenBSD a sus distribución "STABLE"? "
#74 Por lo que veo, OpenBSD tiene de soporte para "STABLE" unos 5 años (contando desde por ejemplo OpenBSD 4.0 hasta OpenBSD 4.9 que es la ultima versión de la rama 4). En la Rama 5 sera parecido, porque al parecer en la rama 3 era menos tiempo de soporte. Salen unas 2 versiones por año y llegan hasta la .9
Estaría bien que diesen 10/13 años de soporte como están dando ya en RHEL y derivados. Viejo pero extremadamente estable.
#c-63" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2113003/order/63">#63 Y si soy pesado en cuanto a la ayuda, con decirte que en OBSD documentan todo todito, y que leyendo /usr/local/share/doc/pkg-readmes y las MAN| FAQ haces lo que sea(Apache / Firewall / Bind ...) . Nada se dejan por documentar, en serio.
En el mundo GNU tristemente a veces se ven páginas MAN vacías. En OpenBSD no te pasará eso.
"man afterboot", y de ahí... a tirar millas
Por ejemplo, en mi Xorg.conf, las preferencias opcionales del chipset, y demás, estan comentadas con # y explicadas.
#59 Sobre el ejemplo de código de "cat", no lo he visto en profundidad, pero que sea mas largo o enrevesado no quiere decir que sea peor, porque también habrá que tener en cuenta las opciones/argumentos disponibles, las bibliotecas que se usan/llamadas, etc. Además habrá que mirar otras cosas como eficiencia del código o algoritmo, etc. También podemos observar que la versión busybox-cat es bastante corta y simple.
/* Differences from the Unix cat:
* Always unbuffered, -u is ignored.
* Usually much faster than other versions of cat, the difference
is especially apparent when using the -v option.
By tege@sics.se, Torbjorn Granlund, advised by rms, Richard Stallman. */
#67 Tampoco te creas que es muy difícil disponer del "cat" de 4.3BSD para Linux: sustituyes la variable "inline" por otro nombre, cambias un poco los argumentos de la función "main" y poco mas. Ya tienes el "cat" de BSD en Linux funcionando.
#72 En Linux también compila a la primera. Y la versión anterior que había mirado (4.3BSD) no es necesario tocar los argumentos de la función main, solo renombrar la variable "inline" porque el compilador de GNU lo tomara como palabra reservada seguramente.
Pensé que la de 4.3BSD era la misma que OpenBSD al ser derivado de ese sistema. Probare la de OpenBSD en Linux.
#44 Al final es un tema de confianza, habrá pocas vulnerabilidades del propio SO, pero las hay, y las que faltan, de todas formas tienes toda la razón en que de usar, usar lo más auditable y seguro posible.
Pero bueno, que si no es vía el software del que tienes el código, será del firmware del que no lo tienes, o del propio hardware.. está mal la cosa
Que haces, echas a los desarrolladores que salgan en la lista? pues no, porque todos cometen errores en algún momento, el caso es que es imposible diferenciar un fallo hecho a propósito (una puerta trasera) de uno cometido por error, aunque tengas el código delante.
Luego lo de desensamblar un binario, obviamente ofuscar el programa dificulta enormemente el estudiarlo, pero no lo hace imposible, porque en última instancia por muy ofuscado que esté tendrá que ejecutar las instrucciones que quiere para hacer su cometido, y en ese momento lo puedes "cazar" , es decir, que puede hacer análisis dinámico, meterlo en un sandbox y mirar que llamadas al sistema hace, a ficheros, tráfico, etc etc.. Con análisis estático se puede en última instancia desofuscar y ver el código también, pero requiere una cantidad de trabajo manual enorme, este precisamente es el mismo problema en el caso de los binarios comerciales ofuscados que en el de los virus, unos se ofuscan para que no los "crakees" y otros para que el antivirus no los detecte, en los dos casos tienen bastante éxito hoy en día contra herramientas automatizadas, pero no ante el análisis de un humano.
Y lo del MiTM es que se puede hacer de tantas maneras.. no necesariamente tienes que tener acceso a los routers, puedes spoofear tu MAC, tu IP, secuestrar el servidor DNS, hacer malfuncionar (o envenenar) la tabla de enrutamiento de alguno de los equipos que participan en la comunicación, hacerte pasar por el servidor DHCP, aprovecharte de los mensajes de ND de IPv6 (ya que lo mencionas, en la herramienta española Evil Foca implementaron algunos ataques IPv6 para hacer MiTM, y así.. la única solución para evitarlo es cifrar de extremo a extremo: RSA o DH+AES, por ejemplo, y luego verificar las claves en los extremos con algún tipo de medio seguro.
#47 Está en mi perfil, aunque solo suelo poner writeups de pruebas de CTF y poco más relacionado con la seguridad (aunque joer, lo acabo de mirar y las n últimas son de seguridad pero es casualidad), estoy intentando trasladar toda esa temática al podcast de Crónicas de Eurasia ( lo pongo ahora que la noticia esta enterrada, para evitar acusaciones de spam y eso )
#54 He visto un poco por encima tu blog y me pareció interesante. He visto varios artículos sobre criptografía/criptoanálisis y alguno sobre cracking/ensamblador. Me gusta el tema del cracking de binarios (desensamblador/decompilador, llamadas al sistema, etc). Hace mucho que estudie estructura de computadores y lenguaje ensamblador; la verdad es que me acuerdo de poco o casi nada, pero me parece muy interesante. Como me gusta mucho Linux, me interesaría aprender a usar bien utilidades como strace/ltrace/etc, gdb para usarlo como desensamblador, algún decompilador (si existe en LInux), conocer bien la estructura interna del formato ELF, y quizás algún depurador a nivel kernel. ¿Conoces algún libro sobre estos temas?
#58 En linux pues tienes objdump, radare2, gdb, y con esto ya tienes de sobra para entretenerte toda la vida
También puedes usar IDA/IDAPro para examinar binarios, sean del tipo que sean, es bastante más cómodo.
Libros pues no soy yo mucho de eso, en la web de radare hay enlazadas algunas cosas, y luego es ver lo que van haciendo los demás, leer writeups y practicar en CTFs, en ctftime.org en la sección de writeups tienes infinito material sobre esos temas, y para practicar, que al final es eso, practicar, fallar, aprender, practicar, etc..
editado:
Lo de los CTF lo digo por ir por una vía más didáctica y legal, puedes practicar con lo que quieras pero hacerlo con problemas que luego van a ser resueltos y explicados simplifica enormemente las cosas
#80 Gracias. No conocia radare. El IDA es comercial, no? Bueno, antes de meterme, tendre que repasar un poco el tema ensamblador y desde Linux que nunca lo he usado. Nasm, Yasm, As, nunca los use. sintaxis?
#81 Si, es comercial, tiene una versión gratuita de todas formas, y por ser, es más cómodo, y el algoritmo que usa para desensamblar es normalmente mejor que el lineal del objdump.
Repasar un poco el tema del ensamblador no es la palabra si quieres desensamblar cosas reales y entenderlas hay que darle muy duro
#82 Jeje, "un poco" no se acerca ni por asomo, me imagino. Nada, esto en 2 dias estoy haciendo ingenieria inversa a cualquier programa que se ponga por delante
#41 Oye pues voy a mirar lo del Podcast que parece interesante.
Codigo abierto no quiere decir que sea seguro. En el caso del Kernel Linux, se podria saber quien es el responsable de una determinada vulnerabilidad o codigo malicioso (aunque se tarde mas o menos tiempo en conocerla). Es cierto que son muchos millones de lineas, pero también es cierto que estan implicados muchos buenos desarrolladores.
Sobre el desensamblado del codigo binario, me imagino que tampoco serviran tecnicas de ofuscacion ni nada de eso, no?
Para los ataques MiTM tendran que tener acceso a los routers intermedios, no? Al final habra que usar otra Internet alternativa y esperar que IPv6 sea mas seguro.
#38 Yo creo que para tener un sistema bastante seguro se ha de ser un poco paranoico y por supuesto el sistema sera menos "amigable". Pero sigo creyendo que un sistema con la politica de codigo abierto y ciertas medidas de seguridad y de uso, puede ser relativamente seguro en comparación con algunos cerrados. Por supuesto que el usuario debe tener un minimo de conocimiento para que esa minima seguridad se cumpla.
Creo que unos repositorios de distribuciones como Debian o RedHat o incluso Slackware o Gentoo, son dificiles de falsear o comprometer. Poderse seguramente se podra, pero no creo que sea algo muy preocupante o que no se pueda descubrir en poco tiempo. Claro, si luego instalamos programas de dudosa procedencia y encima como superusuarios pues practicamente la seguridad se va al carajo. Has puesto ejemplos de Steam entre otros, y ya sabemos que es incluido de forma oficial en alguna distribucion, pero si deberiamos apostar por software abierto y "confiable", antes que binarios cerrados y no oficiales del sistema que usemos. Es una medida para aumentar nuestra seguridad (no quiere decir que ya estes seguro, pero por lo menos se puede averiguar si hay "gato encerrado"). Esto supone prescindir de mucho software, se debe elegir entre tener un sistema mas seguro-confiable o menos seguro-confiable (no digo totalmente seguro), por eso me gusta Linux, porque te da a elegir que es lo que quieres o como lo quieres.
Los binarios-paquetes de las distribuciones no tienen porque ser un problema de seguridad cuando se sabe que también se pueden descargar las fuentes y auto-compilar los paquetes para tu sistema. Incluso tienes distribuciones como Slackware donde los programas se compilan sin hacer ningun tipo de parcheado respecto a los originales de sus respectivos desarrolladores. Ejemplo: puedes tener el navegador en modo texto "Links" en Slackware tal y como distribuye su propio desarrollador (sin parcheado por parte de Slackware). Con lo cual puedes comparar el source distribuido por Slackware con el original de su propio desarrollador (el hacker que quiera meter aqui algo, tendria que meterlo primero en el paquete original que despues sería reprobado por los empaquetadores/compiladores de Slackware antes de sacar el paquete binario oficial y su paquete de codigo-fuente).
Los ejemplos que te he puesto de rkhunter, chkrootkit, IDS/IPS, los he puesto como otras ayudas (por supuesto que no siempre efectivas). También tenemos unhide para "procesos ocultos" y muchas medidas mas.
Lo del sniffer sería para usarlo en un sistema que tengamos sospecha de algún tipo de comportamiento indeseado y habria que restringir el trafico para poder detectar esos comportamientos "sospechosos".
Todo este rollo un usuario "normal" no aplicara nada posiblemente, pero creo que tampoco es trivial hackear un sistema (siempre que se use debidamente e intentar no usar programas de dudosa procedencia), y por rentabilidad creo que siempre se le puede sacar rentabilidad a una "victima", ya sea por robo de datos personales, bancarios, espionaje-chantaje, equipo zombie, etc...
Y android que es?, ah, que es Linux, y que tiene cientos de miles de variantes de malware conocidos (habrá más por ahí seguramente)
Y por cierto, la infección en este caso, la hace el malware aprovechando una vulnerabilidad en java, pero podría hacerlo aprovechando una en apache, en el kernel, o en passwd, y cada uno tendría su problemática y distribución característicos, pero desde luego no habría que hacer un chmod +x.. decir que no puede haber malware en sistemas Linux porque no se ve mucho es tener un profundo desconocimiento de como funciona el malware o ser muy optimista.
Me pregunto un par de cosas ¿Cómo la aplicación Java puede escribir en /etc/init.d sin tener permisos de root? y sobre todo ¿Cómo se produce la infección originalmente?
#3 tranki, que por ahora solo lo has visto en la web. Cuando lo veamos de verdad en un Mac, hablamos.
#4 tiene pinta de ser un virus "teórico". De esos que hay muchos pero que no se pueden propagar porque necesitan que alguien se lo baje expresamente y se lo instale como root.
#1 Ya sé que es multiplataforma, lo pongo en la entradilla. He subido la noticia para que los linuxeros se anden con cuidado y se pongan un condón en el dedo hasta que cese la amenaza.
#12 los virus de los linux son como los billetes de 500. Sabemos que existen por fotos en la web. Nunca hemos visto uno y estamos convencidos de que en nuestra vida muy posiblemente no nos encontremos nunca con uno en nuestras manos. Pero a todos nos gustaría tenerlo aunque solo fuera para saber lo que se siente.
bueno pues ademas de que necesita root en el caso de que te infectara el pc (q no va a pasar)
metes un live cd y borras o cambias ese archivo y arreglado pero si no desactiva java y se acabo el problema.
#8#6 Obviamente el virus no es de mac, ya que es un sistema operativo y no un lenguaje de programación. El caso es que afecta a mac y se decía que eran inmunes, no veo el zas por ningún lado.
En los comentarios de la página lo explican, para que el virus se autoejecute tendría que tener acceso root, y a menos que tú se lo des a posta (cosa improbable) como mucho tendrías el archivo del virus en el ordenador pero sin efecto alguno.
#3 Eso es un bulo que se repite como un mantra para desprestigiar a Mac, virus sí tiene, pero aparece 1 alerta cada x tiempo, que es cuando se ven los comentarios como el tuyo, no los miles de virus que encuentras para Windows, lo mismo pasa con Linux.
#11 De hecho lo que dice el reporte es que el virus se aloja en el directorio personal y se conecta a IRC. Para eso, de nuevo, no necesitas permisos especiales.
Comentarios
#12 Virus muy peligroso para Linux en fichero ejecutable .sh:
El fichero se llama halflife3.sh. Conteniendo el siguiente codigo virus muy peligroso para el usuario:
rm -rf ~
También existe versión mas "sofisticada" que pide permisos de "root". Contenido:
echo 'hola soy un virus muy malo malo malo'
rm -rf /
Son unos virus muy muy peligrosos para Linux. Yo llevo mas de 13 años usando Linux y nunca he visto nada parecido.
#15 Todo el mundo hace bromas con el rm -rf /, pero cuanta gente lo ha probado? Curiosamente, si lo pruebas en una terminal, GNU/Linux te avisa HASTA TRES VECES, que lo que quieres hacer ES UNA PUTA LOCURA. Pero en fin, sigamos riendo la broma, no?
#16 Pues será ahora, porque yo he borrado un par de distros así.
#22
#22 ya lo dijo Spiderman: un gran poder conlleva una gran responsabilidad. Yo los sistemas operativos quiero que me dejen hacer todo, que ya me cuidaré yo de usarlo bien. La otra opción, que el sistema operativo te limite, va bien en algunos casos, pero al trabajar con ellos resulta molesto.
#15 Claro y qué de un programa en java que se ejecute automáticamente por medio de alguna vulnerabilidad y haga el rm -rf ~?
#19 #20 Sin entrar en medidas complejas de seguridad que podrían ayudar en el tema de la seguridad (SELinux, Grsecurity, firmado de binarios, unhide, y otras), el simple hecho de usar 2 cuentas de usuario sin privilegios o utilizar un entorno "seguro" tipo kvm o lxc para probar nuevos programas o añadidos, ya supone librarse de un daño de la información privada importante.
Es posible usar 2 usuarios sin privilegios de modo que uno se usa para "cosas serias" y bien probadas (de fuentes fiables), y el otro usuario se usa para probar cosas de las que no sabemos bien si son fiables (paginas web con scripts, añadidos al navegador, programas binarios, etc...).
Además si disponemos de programas sniffers y traceadores de redes, se puede comprobar toda conexión saliente hacia fuera de nuestro equipo y de donde parte (puertos, programa, sockets, etc...).
Nadie se cree que no exista malware/virus/lo que sea/ para Linux, solo que teniendo un minimo de conocimientos y de seguridad, es muy improbable ser "contagiado" con algo.
Personalmente puedo asegurar que llevo mas de 13 años usando Linux como unico sistema (en un 95% de las veces). He instalado y he usado decenas de distribuciones con muchos programas de todo tipo (tanto abiertos/libres como binarios privativos y de dudosa procedencia). Nunca nunca nunca me he encontrado con un solo comportamiento destructivo o raro en mis sistemas ni mal funcionamientos debidos a esos virus/gusanos/malwares/etc. Puede que haya tenido suerte, pero no sera por haber puesto mucho cuidado.
#24 Es más complicado si sabes con lo que trabajas, está claro, pero es que el objetivo de un malware que quiere hacer un botnet (como este) es tener el máximo número de targets posibles, y evidentemente los usuarios técnicos, que son más difíciles de infectar, no son el principal objetivo.
De todas formas, pongo un par de pegas a lo que dices.
A lo primero, dos usuarios sin privilegios hoy en día en cualquier distribución no significa seguridad, porque los usuarios, repito, hoy en día, tienen acceso a cosas que antes era impensable para un usuario sin privilegios, hay un montón de servicios que se han transladado para bien o para mal al espacio de usuario. Ejemplos: el control de los dispositivos de red, el montaje de sistemas de ficheros, incluso iniciar/apagar el equipo, etc etc..
Puedes hacer tu usuarios con menos privilegios? claro, pero esto ya no es el comportamiento por defecto en la mayoría de las distribuciones.
A lo segundo, un rootkit por ejemplo, te ocultaría las conexiones salientes y entrantes, procesos, etc.. tendrías que hacer la captura fuera de tu equipo para que fuera realmente fiable, y .. siendo sinceros, capturar el tráfico raw de la red salvo que sospeches algo o estés haciendo alguna prueba concreta no es algo que se haga muy a menudo.
Por otra parte, aunque pudieras detectar el tráfico, primero debes separarlo de las conexiones legítimas, y seguramente esté ofuscado de alguna manera para que no puedas saber lo que hace. Como mínimo te llevaría mucho tiempo.
Y a lo tercero, un poco siguiendo este hilo, yo también llevo muchos años dedicándome a esto, y en concreto a la parte de seguridad llevo un buen tiempo y lo que puedo decir es que espero, o deseo, que nunca hubiera sido infectado en ningún sistema, pero la estadística es muy tozuda y.. saber!
Por cierto, todas las medidas de seguridad que mencionas ayudan, pero desde luego no evitan comportamientos maliciosos en todos los programas que metas en el equipo.
#c-25" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2113003/order/25">#25 uname -a
OpenBSD openbsd.my.domain 5.4 GENERIC.MP#2 amd64
# pfctl -a '*' -sr
block drop all
pass all flags S/SA
block drop in on ! lo0 proto tcp from any to any port 6000:6010
pass out quick on re0 proto tcp from any to any port = 51413 flags S/SA
pass out quick on re0 proto udp from any to any port = 51413
pass in quick on re0 proto tcp from any to any port = 51413 flags S/SA
pass in quick on re0 proto udp from any to any port = 51413
pass out on re0 proto tcp all flags S/SA modulate state
pass in on re0 proto tcp from any to any port 5000:5100 flags S/SA
pass in on re0 proto tcp from any to any port 3748:3749 flags S/SA
pass in on re0 proto tcp from any to any port = 1270 flags S/SA
pass in on re0 proto tcp from any to any port = 80 flags S/SA
pass in on re0 proto tcp from any to any port = 443 flags S/SA
pass in on re0 proto tcp from any to any port = 22 flags S/SA
pass in on re0 proto udp from any to any port 5000:5100
pass in on re0 proto udp from any to any port 3748:3749
pass in on re0 proto udp from any to any port = 1270
pass out on re0 proto tcp from any to any port 5000:5100 flags S/SA
pass out on re0 proto tcp from any to any port 3748:3749 flags S/SA
pass out on re0 proto tcp from any to any port = 1270 flags S/SA
Buena suerte le deseo al "virus" Java.
#28 #30 El funcionamiento es esencialmente el mismo, de hecho en el artículo se habla de un malware basado en Java, así que la comparación me parece bastante relevante, portar el código de un sistema a otro es trivial.
#26
Un botnet como este establece la conexión desde tu equipo a un C&C, lo puede hacer a través de una web, de un server IRC, de un protocolo propio.. es imposible que con un firewall puedas discriminar una conexión de un software como este de uno legítimo, es simplificar demasiado.
Echad un ojo a los writeups y las muestras que existen por ahí, por ejemplo :
http://www.kernelmode.info/forum/search.php?st=0&sk=t&sd=d&sr=posts&keywords=linux
y comprobad que no es un tema tan simple como "no le doy permisos y listo", porque algunos aprovechan vulnerabilidades conocidas, que pasa si un día se extiende uno y el sistema o la aplicación de la que aprovecha el fallo no está parcheado todavía? o si sacan algo que aproveche un 0day, pues que estás tan vendido como en cualquier otro sistema.
También se puede ver algo sobre las mecánicas de la comunicación con los C&C, como se ofusca, cifra y pone todos los medios para pasar inadvertido.
Por cierto #28, no se puede ser tan talibán, si vas a discutir con argumentos perfecto, si no deja de hacer ruido, gracias.
#31 en mi android no hay /etc/init.d/ así que será todo lo trivial que quieras, pero hay que hacerla. Pero vamos, si la cosa es poner pegas hasta que tengas la razón, no pasa nada, te la doy para que quedes contento y lo dejamos aquí. Yo entro en estos hilos porque me gusta leer y comentar cosas de seguridad, no a hacer peleas de egos.
#32 Peleas de egos?, tener la razón? pero de que hablas? tener la razón sobre que?
Si comenté algo es para aportar información bastante útil sobre el estado del malware en sistemas Linux que es evidente que la mayoría no conoce, por la prepotencia con la que se habla, ya me dirás en que quiero "tener la razón" :-?
Mi mención a android viene por los comentarios que se ríen del malware en Linux, como si fuera un sistema invulnerable.
Pongo el ejemplo de Android para demostrar que un sistema basado en Linux puede ser tan vulnerable como cualquier otro, pero también pongo ejemplos para Linux y BSD de escritorio en el enlace de #31.
Es curioso por cierto, porque en #18 hablas de que los virus de linux solo existen de oidas, etc, y que te gusta entrar en estos hilos a comentar cosas de seguridad, pero pongo un enlace a un foro donde puedes descargarte ese malware para linux, y la gente lo estudia y lo comenta y entonces el tema se convierte en una pelea de egos, impresionante.
#35 Me temo que no hemos interpretado la línea argumental del mismo modo. Disculpa si eso.
El malware es distinto de un virus porque hacer un malware es trivial, pero gracias por el enlace, le echaré un vistazo.
#25 Es cierto que Linux no es invulnerable (y creo que ningún sistema es invulnerable). Pero también es cierto que teniendo un poco de cuidado en usar fuentes confiables y usando un usuario sin privilegios es bastante improbable ser infectado por algún tipo de malware. No digo que no pueda ocurrir, pero hoy por hoy es improbable. Afortunadamente la mayoría de distribuciones disponen de mucho software, haciendo innecesario buscar programas por otras vias menos seguras. Por supuesto que algunas distribuciones deberán ponerse un poco las pilas en temas de seguridad, pero las herramientas existen. Como tu bien dices, mucho problema se debe al tema de permisos y privilegios.
El tema de los rootkits es muy antiguo y teniendo una maquina con ciertas medidas de seguridad se hace bastante dificil ser infectado. Sin dedicarme a la seguridad se me ocurren algunas medidas tan sencillas como por ejemplo: firma de binarios (bsign) o particiones importantes del sistema (/bin, /etc, /sbin, /usr, etc), que no se suelen modificar mucho salvo en actualizaciones, pueden ser instaladas en discos duros o dispositivos con protección contra escritura por hardware (via switch o boton fisico), con lo cual el rootkit pocos ficheros importantes del sistema podra suplantar y/o modificar. Todo eso sin hablar de parches o medidas mas sofisticadas como SELinux, PaX, etc.
Luego tienes utilidades como rkhunter, unhide, IDS/IPS, etc, que también pueden ayudar. Alguien con suficientes conocimientos puede crear daemons o procesos ocultos que controlen ciertos aspectos del sistema y emitan ciertas alarmas o avisos al usuario administrador.
Suponiendo que ya estés infectado por un rootkit o algo y logren ocultar las transmisiones o algo por estilo, si sera interesante disponer de algún sniffer o parecido, que este a la salida de ese sistema controlando el trafico saliente (no solo su contenido, sino puertos/protocolos o direcciones, aplicación que lo ha creado, etc...) y supongo que se puede averiguar si existe algún software malicioso que esta mandando información al exterior si el usuario sabe bien que es lo que se esta usando y que servicios de su sistema están activos y usando conexiones (también digo yo que se podrá limitar todo trafico o servicios posibles y con el sniffer externo comprobar si se sigue transmitiendo hacia el exterior en algún momento registrando todo trafico con logs o lo que sea).
#37 Uf, son medidas muy estrictas para un sistema que pretenda ser de uso general, muchas veces se dejan de lado soluciones muy eficaces porque en la práctica presentan muchos problemas de utilización.
Por ejemplo, algunos problemas:
- Con lo de proteger contra escritura las particiones: el usuario tiene que cambiar el comportamiento muy a menudo, en cada actualización (hay actualizaciones diarias de software), cada cambio es una posibilidad de infección.
- ¿Cómo discrimina el usuario el software "bueno" del "malo"?. Claro si solo instalas cosas de los repositorios (y confias en ellos, porque esto sería otro tema que daría para otro debate inacabable), entonces ok, pero esto en un sistema de escritorio, que suelen ser los objetivos de los creadores de malware (muchos datos personales, mucha info para vender..), es poco probable, porque el usuario siempre querrá instalarse el último steam, spotify, juego o driver de la gráfica que no estará en la distro.
- ¿Quién firma los binarios? y ¿cómo consigues la clave pública de quien lo firma?. Por ejemplo el sistema de firma de repos de debian/ubuntu está guay, pero se puede hacer un MiTM a la hora de que el usuario se descargue la clave PGP de un repo, y meterle después software malicioso a voluntad. Puede parecer exagerado, pero solo hay que pensar en 2 ejemplos: Stuxnet y Flame se distribuyeron como actualizaciones.. de Windows!!! y firmadas!!! con un certificado valido!!!(!uno!!111!). A mi eso me parece demoledor, por ejemplo. Remote code execution firmado.
- Un IDS o los chkrootkits y similares solo buscan amenazas conocidas basándose en firmas, el análisis de comportamientos está muy muy muy verde y las amenazas nuevas y/o ofuscadas ni las huelen. Igual que los antivirus, que están en horas bastante bajas.
Y así, al final está claro que una combinación de todo+educación del usuario ayuda, pero a lo que iba yo es que el sistema no es mejor o peor por ser Linux, todo tiene sus problemas y la experiencia nos está diciendo que si no hay más infecciones es por rentabilidad, no tanto por seguridad, que es lo que se pensaba hace unos años.
En cuanto a lo del sniffer, es un tema que me interesa mucho particularmente, la verdad, y la mejor solución que he visto es una basada en flows de tráfico (un sniffer sería demasiado, porque a ver quien analiza todo eso en una red un poco grande), y análisis basados en estadística para detectar comportamientos sospechosos en el tráfico.
Aquí hay un paper sobre el tema, y a partir de esto se han hecho herramientas interesantes, pero aún está muy verde el panorama: https://www.usenix.org/legacy/event/sec08/tech/full_papers/gu/gu.pdf
#38 Para hacer un MITM debes estar en la misma red. A parte que el sistema de seguridad de Windows es de todo menos eso.
Luego ya sobre seguridad... mi sistema lo tienen bastante jodido para atacar. Los únicos ports que uso son dos juegos. No tengo servicios arrancados y PF hace su trabajo demasiado bien.
#39 No, un MiTM se puede hacer sin estar en la misma red perfectamente, solo que es más fácil así claro, pero puedes hacerlo por ejemplo si:
a los humanos nos cuesta un poco más), ¿por qué no se hace siempre? porque las líneas de ensamblador serían millones, y es demasiado. Pero el kernel de Linux, por ejemplo, tiene ahora mismo 17 millones de líneas de código, NADIE, nisiquiera Tolvards, ni RMS, nisiquiera los que mantienen los paquetes en las distribuciones, se han leido TODO el código, más bien es un sistema de confianzas en cadena, en el que cada uno tiene una reputación y se confía en que los cambios que haga no son maliciosos, si un desarrollador metiera código malicioso en el kernel, se tardaría meses o años en dar con el, como pasa con los bugs no-intencionados que se aprovechan como vulnarabilidades (no hay diferencia técnica entre una cosa y la otra, de hecho, no es que el malintencionado ponga begin.backdoor, etc). La única ventaja del tinglado este, es que si se sabe o se sospecha que un desarrollador mete código "malo" demasiado a menudo o a propósito se pueden separar los cambios del resto, pero vamos, que realmente open-source no es garantía de nada por si solo.
- Consigues inyectar una ruta
- Envenenar las resoluciones DNS
- Ponerte en cualquiera de los saltos intermedios
- Tomar control del sistema al que te conectas
, etc
Casi todas las opciones se pueden hacer con malware de diversos tipos, hay muchos muy sencillos que por ejemplo te cambian el hosts, o te redirigen a un DNS falso, y luego haces ya el MiTM o lo que sea. El propio ISP te puede hacer un MiTM, o la NSA (ala, conspiranoia time.. ah no, es que ya ha pasado realmente, ver por ejemplo el caso de Francia falsificando certificados SSL de google con una certificadora propia, para que los querian? pues eso, para hacer ellos un MiTM con cert verificado incluido)
#40 No quiero hacer spam, así que no voy a dar más datos, si interesa se puede buscar fácil de lo que hablo, pero justo esta semana vamos a sacar una entrega de un podcast en el que colaboro y en la entrega pasada le hicimos (le hice) una entrevista a Richard Stallman, que por supuesto abordó el tema del malware desde ese punto de vista que propones: "Cualquier software del que no puedas ver la fuente es malware", ese es su resumen básicamente, porque no puedes comprobar las fuentes etc.
Pero en el que vamos a sacar hoy (o mañana) le hicimos una entrevista a un experto en malware de la Universidad de Kiev, y le preguntamos que le parecía la conclusión de Stallman, y nos hacía una reflexión muy interesante, que se podría resumir en ... cualquier programa se puede desensamblar y ver su comportamiento (bueno, el lo podrá hacer fácilmente
Con todo esto no quiero dar a entender que es lo mismo una cosa que otra, es evidente que es infinitamente mejor tener acceso al código fuente, pero quiero dejar claro lo importante que es no confiarse demasiado, porque los motivos que se dan a veces no son suficientes para no tomar precauciones, y lo malo es que se hace.
#41 " Pero el kernel de Linux, por ejemplo, tiene ahora mismo 17 millones de líneas de código, NADIE, nisiquiera Tolvards, ni RMS, nisiquiera los que mantienen los paquetes en las distribuciones, se han leido TODO el código, "
No uso Linux, uso openbsd, donde cada binario está compilado por el equipo de éste para funcionar, sustituyendo funciones inseguras por seguras.
EL código BSD es mucho más simple, por cierto, a nivel de kernel/userland que el de GNU/Linux. Lo digo sin trollear desde ya. Para auditarlo lo tienen mucho más facil, y más siendo OpenBSD un sistema operativo completo.
echo.c en OpenBSD:
#include
#include
#include
/* ARGSUSED */
int
main(int argc, char *argv[])
++argv;
nflag = 1;
">
else
nflag = 0;
while (*argv)
La simpleza de esos códigos hace que siemplemente mirando su CVS se pueda auditar increíblemente bien el SO.
#42 Aún así, estamos hablando de cantidades ingentes de código.
Sólo piensa una cosa: Se descubren X vulnerabilidades cada mes, todas ellas han sido causadas por fallos de programación, ¿o no?, ¿y si alguno de ellos ha sido intencionado?
Es que a mi pensar que todo el mundo es bueno no me encaja, parece que los desarrolladores de opensource son distintos de la gente que vemos todos los días por la calle, en la tele, etc.. y no es así, alguno con mala idea o intereses habrá, y puede decir: aquí me voy a "olvidar" de programar un rato, y se podrá aprovechar eso para ejecutar código remoto haciendo X. Eso es un backdoor, no lo que la gente piensa que es :
Un ejemplo:
http://en.wikipedia.org/wiki/NSAKEY -> en serio? haces un backdoor para la NSA y le llamas a la clave nsakey?, a mi me parece poco..creible..
http://en.wikipedia.org/wiki/Dual_EC_DRBG -> Un backdoor en la construcción de las curvas elípticas para el cifrado con ECC, pues ya suena mejor, es algo más sutil
o http://en.wikipedia.org/wiki/RdRand
#43 "Sólo piensa una cosa: Se descubren X vulnerabilidades cada mes, todas ellas han sido causadas por fallos de programación, ¿o no?, ¿y si alguno de ellos ha sido intencionado? "
)"
En OpenBSD se lo piensan muy mucho sobre qué funcion meter. En serio, no entra cualquier mierda
"(yo tampoco lo digo por trolear, no quiero entrar en un neverending flame de licencias
Más que licencia, filosofía de diseño. Por licencia me gusta más GNU, pero prefiero OpenBSD, está todo muy simplificado y documentado.
Y no, para evitar flames, uso GNU Emacs
#44 Pero puestos a minimizar codigo, para eso usamos Minix y asunto arreglado. OpenBSD que yo sepa no implementa MAC, y confian plenamente en su "limpieza de codigo". Yo personalmente creo que el codigo 100% libre de bugs/vulnerabilidades es casi una utopia. Creo que son necesarias otras medidas para minimizar riesgos como por ejemplo algunas de las que soporta Linux (Grsecurity, RSBAC, SElinux, apparmor, etc...).
#46 Tenemos jaulas en OpenBSD, NGINX se configura así por defecto. Y con MYSQL, otro tanto.
"hacer malfuncionar (o envenenar) la tabla de enrutamiento de alguno de los equipos que participan en la comunicación."
Con PF podemos desactivar eso. Tablas estáticas en plan paranoico como añadido. Buena suerte.
" (ya que lo mencionas, en la herramienta española Evil Foca implementaron algunos ataques IPv6 para hacer MiTM, y así.. la única solución para evitarlo es cifrar de extremo "
Idem. Con PF bien configudo ya pueden intentarlo, ya.
http://www.openbsd.org/faq/pf/filter.html
#48 Yo también se asegurar un sistema para que ciertos tipos de ataques no se produzcan, BSD, Linux o.. pero es imposible hacerlo invulnerable a todo porque a veces el usuario "colabora" o porque se aprovecha el funcionamiento del propio stack de comunicaciones para, en el caso de que no esté bien configurado, desatar comportamientos inesperados.
la semana que viene tengo que hacer unos labs de seguridad con unos alumnos, y ahora por curiosidad simplemente voy a poner OpenBSD en los clientes, a ver como responden, te mando ya las "gracias" de su parte que seguro que les hace mucha ilusión, je je .
Que jo, en serio que no le tengo manía a OpenBSD, pero tal y como lo dices parece que lo instalas y es invulnerable, porque es muy seguro y muy guay, yo me alegro por tus sistemas, que parece que los aseguras bastante, no es mi intención decir lo contrario, sino llamar la atención con que muchos comportamientos por defecto de los sistemas, muchas veces sin intervención del usuario, o a veces con su "colaboración", pueden dar lugar a comportamientos no deseados, sea el sistema el que sea.
De todas formas, ya un poco por..
#50 "a semana que viene tengo que hacer unos labs de seguridad con unos alumnos, y ahora por curiosidad simplemente voy a poner OpenBSD en los clientes, a ver como responden, te mando ya las "gracias" de su parte que seguro que les hace mucha ilusión, je je . "
Ya pueden configurarlos bien. Por defecto no están activas las SoftUpdates en el sistema de ficheros en fstab y la E/S es lenta sin ellos.
Y esto además
kern.maxvnodes=65536
kern.usermount=1
kern.maxfiles=65536
Sí, es una jodienda, pero se hace para soportar equipos muy muy limitados por defecto Y bueno, en rendimiento GNU/Linux es algo superior, pero en redes... PF es una verdadera pasada, y NGINX parcheado mola muchísimo.
Ah, y la documentación, "man afterboot" y "ls /usr/loca/share/doc/pkg-readmes". Todo está documentado. Todo binario, todo servicio y toda configuración en /etc.
Finalmente... OpenSMTPD
#51 Habra que ver el nuevo nptables de Linux para compararlo con PF.
#47 Se ve que controlas bastante en temas de seguridad. Tienes blog?
#52 "Habra que ver el nuevo nptables de Linux para compararlo con PF." Por filosofía, espero que no sea algo ultrarecargado con parches, como lo de GNU.
#53 no será tan malo Linux en tema de redes cuando algunos equipos de Cisco están basados en Linux.
#55 Me refiero al diseño y userland en general. Si nos ponemos en líneas generales...
GNU intenta crear un sistema parecido a Emacs. Demonios, procesos paralelos y miles de opciones para que todo el mundo esté contento según su modo de trabajar.
BSD hace lo mismo, pero a lo Vi. Espartano y simple, pero una vez configurado no lo tocas aunque actualices 8 veces en 4 años.
#56 Y que prefieres Emacs o vi???
#57 Código Emacs, sysadmin, vi o perl/sed a secas.
#58 Si te interesa, con OpenBSD y bajándote el código fuente de la rama STABLE puedes aprender un cojón y medio.
Compara la sencillez de codigo:
https://gist.github.com/pete/665971
#59 Yo creo que Emacs te puede servir también para sysadmin. Lo primero es que tiene modos que emulan a VI. Luego tiene shell propia, permite sesiones en remoto. Dispone de emacsclient. Y la potencia y versatilidad que tiene Elisp no la tiene Vim ni de lejos. Ahora querían para la versión 25 de Emacs usar Guile y quizás scheme para sustituir a Elisp y darle capacidad de multihebra a Emacs. Ojala lo hagan y mientras sigan teniendo un Lisp en tiempo real para Emacs, seguirá siendo tan poderoso. Lisp es muy potente, tanto que hoy día lo siguen intentando imitar o copiar sus caracteristicas. Permite incluso modificarse a si mismo (su código) en tiempo de ejecución y dispone de compiladores e interpretes. Lastima que sea un poco complicado de entender y usar.
#60 Hombre, a mí tambien me gustaría, pero es que ví, sed y perl están en todas partes, y en todo UNIX.
Ya podrían haber metido mg(1) por defecto como contraparte a vi(1) en las demás distros GNU y UNIX-likes.
http://es.wikipedia.org/wiki/Mg_%28editor%29
#61 VI, la mayor ventaja creo que es la de estar en todo UNIX viviente. Luego creo que sus teclas por defecto pueden ser mas "intuitivas" o rapidas que las de Emacs por defecto y darle mucho a ESC, . VI/Vim es util y rapido, pero en comparación a Emacs creo que solo le queda la virtud de estar instalado por defecto en muchos sistemas.
El mg es un microemacs no?
Es necesario sed si se tiene Perl?
En Linux creo que también viene instalado siempre por defecto Python (Ruby no se...).
En BSD viene Python por defecto?
Y por que elegir de los BSD a OpenBSD teniendo algo tan potente y a la vez seguro o versatil como FreeBSD??? Creo que si eligiera un BSD, seguro que seria FreeBSD. Creo que tenían un proyecto llamado TrustedBSD o algo así con FreeBSD (algo parecido a HardenedGentoo).
#62 "Además habrá que mirar otras cosas como eficiencia del código o algoritmo, etc"
http://www.openbsd.org/cgi-bin/cvsweb/
#63
" El mg es un microemacs no?"
Si, es un clon, pero sin LISP.
" Es necesario sed si se tiene Perl? "
No, pero entre lanzar un binario a un intérprete, pues lo que mejor me vaya.
"En Linux creo que también viene instalado siempre por defecto Python (Ruby no se...).
En BSD viene Python por defecto?"
En OpenBSD no . En los demás, no sé.
"Y por que elegir de los BSD a OpenBSD teniendo algo tan potente y a la vez seguro o versatil como FreeBSD???"
Documentación, parcheo de la casa de binarios, PF, y que los ports se evitan en la medida de lo posible, así que casi todo está ya precompilado.
Y la sencillez, a años luz. De seguridad no hablo pues es redundante.
Y digo la documentación por que es el mejor UNIX documentado de lejos, y el más sencillo de administrar. En FreeBSD actualizando los flavors de los ports te puedes morir. En OpenBSD tengo que hacer 3 cosas, 2 de ellas scripts:
cvsupgrade; reboot.
makeworld; reboot.
pkg_add -vui. Fin de la historia.
#64 Y NetBSD? Parece también un sistema muy bien documentado y con código muy limpio. Creo que puede ser algo entre OpenBSD y FreeBSD (entre seguridad y rendimiento). Además me parece que OpenBSD era un fork de NetBSD, no?
Y expect o Tcl lo has usado alguna vez? he oido cosas buenas de expect para automatización pero nunca lo he probado.
No me cabe duda de que OpenBSD es un muy buen sistema y los BSD en general (aunque solo he usado un poco FreeBSD). Lo importante es que son sistemas abiertos y derivados de Unix que sigue siendo un muy buen sistema, cada uno con sus pros y sus menos pros, pero que funcionan de forma muy parecida y con arquitectura muy similar (al igual que Linux). Es por eso que me resulta tan difícil manejarme en Windows. Estoy tan acostumbrado al sistema tipo "Unix" que me ponen un Windows con su diseño o estructura y sus utilidades del sistema tan "liosas", y no se hacer casi nada que no sea trivial.
#68 " Y NetBSD? Parece también un sistema muy bien documentado y con código muy limpio. Creo que puede ser algo entre OpenBSD y FreeBSD (entre seguridad y rendimiento). Además me parece que OpenBSD era un fork de NetBSD, no?"
Buffff. Es muy bueno en máquinas antiguas, y el consumo de recursos es muy muy bajo, menos que un Debian LXDE, casi como Windows 98, pero depende de un huevo de ports que hay que compilar desde PKGSRC .
Amén que OpenBSD tiene DRI/KMS en el kernel.
Me gusta más OpenBSD por los binarios que ofertan. Los único port que tengo compilado es el Eduke32.
"s por eso que me resulta tan difícil manejarme en Windows. Estoy tan acostumbrado al sistema tipo "Unix" que me ponen un Windows con su diseño o estructura y sus utilidades del sistema tan "liosas", y no se hacer casi nada que no sea trivial."
En OpenBSD lo tienes todo tan extremadamente facil con los ficheros que te he dicho que tienes un NGINX con MYSQL tan rápido o más que Debian.
Configuras un poco sysctl, rc.conf, fstab para los softupdates y lees los pkg-readmes y es literalmente... copiar y pegar los comandos que te indican, por ejemplo, para configurar un OAMP.
En NetBSD hay que compilar todo, y en FreeBSD... es muchísimo más complejo que OpenBSD y también hay que compilar un huevo de cosas.
#69 Por cierto, ¿cuanto tiempo/años da soporte OpenBSD a sus distribución "STABLE"?
Hablas de las distribuciones basadas en codigo (que hay que compilar), como si fueran un problema. Yo no lo veo así. Si es cierto que pueden ser mas lentas de instalar/adaptar, pero pueden ser igual de seguras y muy rapidas o personalizables. FreeBSD creo que dispone de ambos metodos (Ports y paquetes compilados), no?
Y que te parece una Slackware donde no se parchea nada y se confía en los paquetes originales de sus propios desarrolladores? a fin de cuentas son los propios desarrolladores los que mejor conocen sus programas y también a los que se les informa de bugs encontrados para arreglarlos en siguientes versiones y tal.
#73 En OpenBSD:
Ports = se baja el código fuente de fuera, y se compila.
Paquetes. Se compila dentro de la rama de paquetes, y se asegura que esté ultraparcheado para ser estable y a prueba de bugs.
"FreeBSD creo que dispone de ambos metodos (Ports y paquetes compilados), no?"
En OpenBSD lo normal es meter binarios; en FreeBSD casi todo lo "avanzado" se recomienda recompilar.
De hecho, en OpenBSD la filosofía es "just works". Sin make show=FLAVORS ni leches.
"Por cierto, ¿cuanto tiempo/años da soporte OpenBSD a sus distribución "STABLE"? "
http://www.openbsd.org/faq/faq5.html#Flavors
Y comercialmente:
http://www.mtier.org/news/openbsd-ports-lt-support/
#74 Por lo que veo, OpenBSD tiene de soporte para "STABLE" unos 5 años (contando desde por ejemplo OpenBSD 4.0 hasta OpenBSD 4.9 que es la ultima versión de la rama 4). En la Rama 5 sera parecido, porque al parecer en la rama 3 era menos tiempo de soporte. Salen unas 2 versiones por año y llegan hasta la .9
Estaría bien que diesen 10/13 años de soporte como están dando ya en RHEL y derivados. Viejo pero extremadamente estable.
#78 "Estaría bien que diesen 10/13 años de soporte como están dando ya en RHEL y derivados. Viejo pero extremadamente estable. "
Si tuviese más tirón comercial, pues vale.
Pero como por defecto tiene unos valores muy muy conservadores de ficheros, procesos, etc..., la gente se piensa que es lento y se arrastra.
#68 "Y expect o Tcl lo has usado alguna vez? he oido cosas buenas de expect para automatización pero nunca lo he probado. "
Pues no, se me hacía raro aprender TCL/TK .
#c-63" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2113003/order/63">#63 Y si soy pesado en cuanto a la ayuda, con decirte que en OBSD documentan todo todito, y que leyendo /usr/local/share/doc/pkg-readmes y las MAN| FAQ haces lo que sea(Apache / Firewall / Bind ...) . Nada se dejan por documentar, en serio.
En el mundo GNU tristemente a veces se ven páginas MAN vacías. En OpenBSD no te pasará eso.
"man afterboot", y de ahí... a tirar millas
Por ejemplo, en mi Xorg.conf, las preferencias opcionales del chipset, y demás, estan comentadas con # y explicadas.
#59 Sobre el ejemplo de código de "cat", no lo he visto en profundidad, pero que sea mas largo o enrevesado no quiere decir que sea peor, porque también habrá que tener en cuenta las opciones/argumentos disponibles, las bibliotecas que se usan/llamadas, etc. Además habrá que mirar otras cosas como eficiencia del código o algoritmo, etc. También podemos observar que la versión busybox-cat es bastante corta y simple.
#59 Sacado de la versión gnu-cat:
/* Differences from the Unix cat:
* Always unbuffered, -u is ignored.
* Usually much faster than other versions of cat, the difference
is especially apparent when using the -v option.
By tege@sics.se, Torbjorn Granlund, advised by rms, Richard Stallman. */
#66 Unix cat, no "BSD" cat .
Aún así el diseño de OpenBSD es para seguridad, GNU para rendimiento.
#67 Tampoco te creas que es muy difícil disponer del "cat" de 4.3BSD para Linux: sustituyes la variable "inline" por otro nombre, cambias un poco los argumentos de la función "main" y poco mas. Ya tienes el "cat" de BSD en Linux funcionando.
#71 La de System 7 he compilado directamente en OpenBSD .
Por cierto, el cat de 4.3BSD no es el de OpenBSD:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/bin/cat/cat.c?rev=1.20;content-type=text%2Fplain
#72 En Linux también compila a la primera. Y la versión anterior que había mirado (4.3BSD) no es necesario tocar los argumentos de la función main, solo renombrar la variable "inline" porque el compilador de GNU lo tomara como palabra reservada seguramente.
Pensé que la de 4.3BSD era la misma que OpenBSD al ser derivado de ese sistema. Probare la de OpenBSD en Linux.
#72 "cat" de OpenBSD compilado sin ningún warning en Linux y ejecutable.
Hay utilidades que son muy similares y usan librerias comunes en ambos sistemas.
#76 Sí, es normal que compile, suelen pocas especialidades los de OpenBSD.
Aún así con systemd y DBUS la cosa se hará bastante más dificil en un futuro.
#44 Al final es un tema de confianza, habrá pocas vulnerabilidades del propio SO, pero las hay, y las que faltan, de todas formas tienes toda la razón en que de usar, usar lo más auditable y seguro posible.
Pero bueno, que si no es vía el software del que tienes el código, será del firmware del que no lo tienes, o del propio hardware.. está mal la cosa
#45 Y ya se sabe, mira, por ejemplo:
Ubuntu: http://www.cvedetails.com/vendor/51/Ubuntu.html
OpenBSD: http://www.cvedetails.com/vulnerability-list/vendor_id-97/Openbsd.html
Que haces, echas a los desarrolladores que salgan en la lista? pues no, porque todos cometen errores en algún momento, el caso es que es imposible diferenciar un fallo hecho a propósito (una puerta trasera) de uno cometido por error, aunque tengas el código delante.
Luego lo de desensamblar un binario, obviamente ofuscar el programa dificulta enormemente el estudiarlo, pero no lo hace imposible, porque en última instancia por muy ofuscado que esté tendrá que ejecutar las instrucciones que quiere para hacer su cometido, y en ese momento lo puedes "cazar" , es decir, que puede hacer análisis dinámico, meterlo en un sandbox y mirar que llamadas al sistema hace, a ficheros, tráfico, etc etc.. Con análisis estático se puede en última instancia desofuscar y ver el código también, pero requiere una cantidad de trabajo manual enorme, este precisamente es el mismo problema en el caso de los binarios comerciales ofuscados que en el de los virus, unos se ofuscan para que no los "crakees" y otros para que el antivirus no los detecte, en los dos casos tienen bastante éxito hoy en día contra herramientas automatizadas, pero no ante el análisis de un humano.
Y lo del MiTM es que se puede hacer de tantas maneras.. no necesariamente tienes que tener acceso a los routers, puedes spoofear tu MAC, tu IP, secuestrar el servidor DNS, hacer malfuncionar (o envenenar) la tabla de enrutamiento de alguno de los equipos que participan en la comunicación, hacerte pasar por el servidor DHCP, aprovecharte de los mensajes de ND de IPv6 (ya que lo mencionas, en la herramienta española Evil Foca implementaron algunos ataques IPv6 para hacer MiTM, y así.. la única solución para evitarlo es cifrar de extremo a extremo: RSA o DH+AES, por ejemplo, y luego verificar las claves en los extremos con algún tipo de medio seguro.
#47 http://undeadly.org/cgi?action=article&sid=20110420080633
Alertas de seguridad en OpenBSD:
http://www.openbsd.org/security.html
#47 Está en mi perfil, aunque solo suelo poner writeups de pruebas de CTF y poco más relacionado con la seguridad (aunque joer, lo acabo de mirar y las n últimas son de seguridad
pero es casualidad), estoy intentando trasladar toda esa temática al podcast de Crónicas de Eurasia ( lo pongo ahora que la noticia esta enterrada, para evitar acusaciones de spam y eso 
)
#54 He visto un poco por encima tu blog y me pareció interesante. He visto varios artículos sobre criptografía/criptoanálisis y alguno sobre cracking/ensamblador. Me gusta el tema del cracking de binarios (desensamblador/decompilador, llamadas al sistema, etc). Hace mucho que estudie estructura de computadores y lenguaje ensamblador; la verdad es que me acuerdo de poco o casi nada, pero me parece muy interesante. Como me gusta mucho Linux, me interesaría aprender a usar bien utilidades como strace/ltrace/etc, gdb para usarlo como desensamblador, algún decompilador (si existe en LInux), conocer bien la estructura interna del formato ELF, y quizás algún depurador a nivel kernel. ¿Conoces algún libro sobre estos temas?
#58 En linux pues tienes objdump, radare2, gdb, y con esto ya tienes de sobra para entretenerte toda la vida
También puedes usar IDA/IDAPro para examinar binarios, sean del tipo que sean, es bastante más cómodo.
Libros pues no soy yo mucho de eso, en la web de radare hay enlazadas algunas cosas, y luego es ver lo que van haciendo los demás, leer writeups y practicar en CTFs, en ctftime.org en la sección de writeups tienes infinito material sobre esos temas, y para practicar, que al final es eso, practicar, fallar, aprender, practicar, etc..
#80 Gracias. No conocia radare. El IDA es comercial, no? Bueno, antes de meterme, tendre que repasar un poco el tema ensamblador y desde Linux que nunca lo he usado. Nasm, Yasm, As, nunca los use. sintaxis?
#81 Si, es comercial, tiene una versión gratuita de todas formas, y por ser, es más cómodo, y el algoritmo que usa para desensamblar es normalmente mejor que el lineal del objdump.
si quieres desensamblar cosas reales y entenderlas hay que darle muy duro
Repasar un poco el tema del ensamblador no es la palabra
#82 Jeje, "un poco" no se acerca ni por asomo, me imagino. Nada, esto en 2 dias estoy haciendo ingenieria inversa a cualquier programa que se ponga por delante
#41 Oye pues voy a mirar lo del Podcast que parece interesante.
Codigo abierto no quiere decir que sea seguro. En el caso del Kernel Linux, se podria saber quien es el responsable de una determinada vulnerabilidad o codigo malicioso (aunque se tarde mas o menos tiempo en conocerla). Es cierto que son muchos millones de lineas, pero también es cierto que estan implicados muchos buenos desarrolladores.
Sobre el desensamblado del codigo binario, me imagino que tampoco serviran tecnicas de ofuscacion ni nada de eso, no?
Para los ataques MiTM tendran que tener acceso a los routers intermedios, no? Al final habra que usar otra Internet alternativa y esperar que IPv6 sea mas seguro.
#38 Yo creo que para tener un sistema bastante seguro se ha de ser un poco paranoico y por supuesto el sistema sera menos "amigable". Pero sigo creyendo que un sistema con la politica de codigo abierto y ciertas medidas de seguridad y de uso, puede ser relativamente seguro en comparación con algunos cerrados. Por supuesto que el usuario debe tener un minimo de conocimiento para que esa minima seguridad se cumpla.
Creo que unos repositorios de distribuciones como Debian o RedHat o incluso Slackware o Gentoo, son dificiles de falsear o comprometer. Poderse seguramente se podra, pero no creo que sea algo muy preocupante o que no se pueda descubrir en poco tiempo. Claro, si luego instalamos programas de dudosa procedencia y encima como superusuarios pues practicamente la seguridad se va al carajo. Has puesto ejemplos de Steam entre otros, y ya sabemos que es incluido de forma oficial en alguna distribucion, pero si deberiamos apostar por software abierto y "confiable", antes que binarios cerrados y no oficiales del sistema que usemos. Es una medida para aumentar nuestra seguridad (no quiere decir que ya estes seguro, pero por lo menos se puede averiguar si hay "gato encerrado"). Esto supone prescindir de mucho software, se debe elegir entre tener un sistema mas seguro-confiable o menos seguro-confiable (no digo totalmente seguro), por eso me gusta Linux, porque te da a elegir que es lo que quieres o como lo quieres.
Los binarios-paquetes de las distribuciones no tienen porque ser un problema de seguridad cuando se sabe que también se pueden descargar las fuentes y auto-compilar los paquetes para tu sistema. Incluso tienes distribuciones como Slackware donde los programas se compilan sin hacer ningun tipo de parcheado respecto a los originales de sus respectivos desarrolladores. Ejemplo: puedes tener el navegador en modo texto "Links" en Slackware tal y como distribuye su propio desarrollador (sin parcheado por parte de Slackware). Con lo cual puedes comparar el source distribuido por Slackware con el original de su propio desarrollador (el hacker que quiera meter aqui algo, tendria que meterlo primero en el paquete original que despues sería reprobado por los empaquetadores/compiladores de Slackware antes de sacar el paquete binario oficial y su paquete de codigo-fuente).
Los ejemplos que te he puesto de rkhunter, chkrootkit, IDS/IPS, los he puesto como otras ayudas (por supuesto que no siempre efectivas). También tenemos unhide para "procesos ocultos" y muchas medidas mas.
Lo del sniffer sería para usarlo en un sistema que tengamos sospecha de algún tipo de comportamiento indeseado y habria que restringir el trafico para poder detectar esos comportamientos "sospechosos".
Todo este rollo un usuario "normal" no aplicara nada posiblemente, pero creo que tampoco es trivial hackear un sistema (siempre que se use debidamente e intentar no usar programas de dudosa procedencia), y por rentabilidad creo que siempre se le puede sacar rentabilidad a una "victima", ya sea por robo de datos personales, bancarios, espionaje-chantaje, equipo zombie, etc...
#12 #15 #18
Y android que es?, ah, que es Linux, y que tiene cientos de miles de variantes de malware conocidos (habrá más por ahí seguramente)
Y por cierto, la infección en este caso, la hace el malware aprovechando una vulnerabilidad en java, pero podría hacerlo aprovechando una en apache, en el kernel, o en passwd, y cada uno tendría su problemática y distribución característicos, pero desde luego no habría que hacer un chmod +x.. decir que no puede haber malware en sistemas Linux porque no se ve mucho es tener un profundo desconocimiento de como funciona el malware o ser muy optimista.
#20 Como dicen los de MalwareBytes la mayoría de las amenazas informáticas actualmente son malware y no el típico virus.
cierra la boca estamos hablando de gnu/linux (sistema gnu nucleo linux) y eso es android/linux (sistema android de google con nucleo linux) #20
#20 el artículo va sobre ordenadores de sobremesa.
jaja q bueno #15
Me pregunto un par de cosas ¿Cómo la aplicación Java puede escribir en /etc/init.d sin tener permisos de root? y sobre todo ¿Cómo se produce la infección originalmente?
Como mola. ¿ Y de dónde se puede bajar ?
#3 tranki, que por ahora solo lo has visto en la web. Cuando lo veamos de verdad en un Mac, hablamos.
#4 tiene pinta de ser un virus "teórico". De esos que hay muchos pero que no se pueden propagar porque necesitan que alguien se lo baje expresamente y se lo instale como root.
Me imagino que para eso tendrás que tener instalado java.
¿El titular porque solo pone esos dos sistemas operativos?, si pasa también con Ms Windows, el titular es muy partidista.
El reporte original: http://www.securelist.com/en/blog/8174/A_cross_platform_java_bot
A cross-platform java-bot
#1 Ya sé que es multiplataforma, lo pongo en la entradilla. He subido la noticia para que los linuxeros se anden con cuidado y se pongan un condón en el dedo hasta que cese la amenaza.
#0 arregla la entrada y agrega Windows.
Es de risa no poner a ese Sistema (in)operativo.
#12 los virus de los linux son como los billetes de 500. Sabemos que existen por fotos en la web. Nunca hemos visto uno y estamos convencidos de que en nuestra vida muy posiblemente no nos encontremos nunca con uno en nuestras manos. Pero a todos nos gustaría tenerlo aunque solo fuera para saber lo que se siente.
Edit
bueno pues ademas de que necesita root en el caso de que te infectara el pc (q no va a pasar)
metes un live cd y borras o cambias ese archivo y arreglado pero si no desactiva java y se acabo el problema.
Anda ya si los mac no tienen virus.
#3 el virus no es "de mac", sino de Java, que es multiplataforma.
#6 zas en toda la boca al listo de #3
#8 #6 Obviamente el virus no es de mac, ya que es un sistema operativo y no un lenguaje de programación. El caso es que afecta a mac y se decía que eran inmunes, no veo el zas por ningún lado.
#10 para afectar a mac tienes que instalarlo. Queriendo. Y ya de por sí, poca gente usa java en el día a día.
En los comentarios de la página lo explican, para que el virus se autoejecute tendría que tener acceso root, y a menos que tú se lo des a posta (cosa improbable) como mucho tendrías el archivo del virus en el ordenador pero sin efecto alguno.
#3 Eso es un bulo que se repite como un mantra para desprestigiar a Mac, virus sí tiene, pero aparece 1 alerta cada x tiempo, que es cuando se ven los comentarios como el tuyo, no los miles de virus que encuentras para Windows, lo mismo pasa con Linux.
#11 Es que depende de lo que haga el virus, para borrarme los archivos de mi home no necesitas permisos de root. Con eso ya me haces mucho daño.
#11 De hecho lo que dice el reporte es que el virus se aloja en el directorio personal y se conecta a IRC. Para eso, de nuevo, no necesitas permisos especiales.