WINE 7.0-rc6 llega corrigiendo 47 fallos y con muchas mejoras para videojuegos

WINE 7.0-rc6

Pues ya tenemos una Release Candidate más de las que tuvimos el año pasado. En el desarrollo de WINE 6.0, tras más de 20 versiones bisemanales, lanzaron cinco RC antes de la versión estable, pero WineHQ ha lanzado hace unas horas WINE 7.0-rc6. Por lo que se ve en la nota de este lanzamiento, falta le hacía, porque en la parte de errores corregidos han mencionado nada menos que 47. Para poder comparar, cuando lanzan una versión cada dos semanas suelen mencionar más o menos una treintena de «bug fixes».

Pero lo cierto es que en estas semanas no se introducen tantas modificaciones. En total, en WINE 7.0-rc6 han realizado 50 cambios. Entre ellos, WineHQ no destaca ninguno, pero leyendo la lista de «novedades», entre comillas, hay muchas que mejoran la experiencia de los videojuegos, como Star Wars Episodio 1, Racer, Saints Row: The Third, Microsoft Flight Simulator 2000, Deus Ex: Human Revolution, Sniper Elite 4, Lego Stunt Rally, FIFA 11, Guild Wars 2, World of Warcraft. No son los más modernos, pero siempre es bueno poder jugarlos decentemente (que me lo digan a mí que ahora tiro mucho de PPSSPP).

WINE 7.0 podría llegar la semana que viene

Ya está disponible la versión de desarrollo de Wine 7.0-rc6. Se espera esta sea la última versión candidata antes de la versión final 7.0.

Novedades de esta versión:
– Sólo correcciones de errores, estamos en la congelación del código.

WINE 7.0-rc6 es la versión que sucede a la rc5 y ya se puede descargar desde este enlace y este otro enlace. Siempre ponen a nuestra disposición dos enlaces, y yo añado el segundo porque WineHQ lo pone en sus lanzamientos, pero no suele funcionar. Lo que sí funciona es hacer lo que explican en la página de descargas, entre lo que tenemos la posibilidad de añadir el repositorio oficial para sistemas operativos como Debian y Ubuntu.

Si deciden que aún tienen que pulir más el software, la semana que viene lanzarán WINE 7.0-rc7, pero si todo va bien lanzarán ya la versión estable

from Linux Adictos https://ift.tt/33ERl0B
via IFTTT

El kernel GNU Linux-Libre 5.16 se ha lanzado

GNU Linux-libre

Como bien sabes, el kernel vainilla de Linux, el de kernel.org, es en su mayoría de código abierto y libre, pero existen algunas partes, como cierto firmware y algunos controladores agregados por terceros, que son propietarios, de código cerrado. Sin embargo, para los que no quieren esos blobs binarios, pueden contar con una versión «limpia» y 100% libre que se lanza de forma periódica con las últimas versiones del núcleo. Se trata de GNU Linux-Libre.

Alexandre Oliva ha anunciado este lanzamiento, por tanto, ya está entre nosotros GNU Linux-Libre 5.16. Básicamente es un kernel Linux 5.16 al que se le ha limpiado esas partes no libres, y que han sido sustituidas por otras libres. Se han eliminado blogs como los drivers WiFi mt7921s y rtw89 (8852a), el controlador para pantalla táctil ili210x, i.MX DSP Remoteproc, el driver de audio qdsp6, y algunos otros de la arquitectura ARM64 (AArch64).

A parte de estos cambios para hacer de Linux 5.16 un kernel libre de código propietario, GNU Linux-Libre 5.16 no ha renunciado a ninguna de las funciones y mejoras introducidas en la versión upstream, como futex2 para acelerar videojuegos con WINE, soporte para AMX (Intel Advanced Matrix Extensions), las novedades y mejoras para los sistemas de archivos, soporte AMT (Automatic Multicast Tunneling), actualización para compresión Zstd (Zstandard), soporte para los SoCs Qualcomm Snapdragon 690, los nuevos parches de seguridad agregados a esta versión, etc.

Este kernel GNU Linux-Libre se pude instalar en cualquier distribución, aunque para mayor facilidad, los desarrolladores de esta modificación del kernel también proveen de paquetes binarios para sistemas Debian y derivados, así como para Red Hat y derivados. De esa forma, se evita tener que descargar las fuentes, configurar, compilar e instalar el binario obtenido, ya que se puede usar las herramientas de gestión de paquetes para la instalación.

Más información sobre GNU Linux-Libre – Sitio oficial del proyecto

from Linux Adictos https://ift.tt/3GsWnMc
via IFTTT

No hay sorpresas: Ubuntu 22.04 usará Linux 5.15

Ubuntu 22.04 con Linux 5.15

Hace dos días nos hacíamos eco de una noticia que afirmaba que Ubuntu 22.04 se podrá instalar en la Raspberry Pi 4 de 2GB. Hoy tenemos que volver a hablar del sistema operativo desarrollado por Canonical, pero esta vez por el kernel que usará. Jammy Jellyfish, nombre en clave de 22.04, será una versión LTS y, como era de esperar, usará el último kernel Long Term Support que hay disponible, aunque en estos momentos aún no ha recibido esa etiqueta.

Linux 5.10 fue una versión LTS, pero en un principio, si no recuerdo mal, sólo iba a estar soportado durante dos años. Cuando la comunidad dio un paso al frente y se aseguró el mantenimiento, se amplió el soporte. Con Linux 5.15 estamos más o menos en las mismas: estará soportado durante más tiempo que las versiones normales, pero de momento no tanto como 5.10. Y en kernel.org aún no está marcado como LTS, sólo como «Stable».

Ubuntu 22.04 llegará con GNOME 42

Ahora mismo, y si no cambian las cosas como lo hicieron con 5.10, Linux 5.15 estará soportado hasta octubre de 2023. Un año y medio de soporte no es mucho para una versión Long Term Support de Ubuntu, pero la otra opción sería usar Linux 5.16-5.17, soportados alrededor de tres meses. Linux 5.15 se lanzó a finales de octubre de 2021, por lo que no será una versión de las más modernas, pero era la opción más lógica y no creo que haya sorprendido a nadie.

Ubuntu 22.04 Jammy Jellyfish está ahora mismo en desarrollo, y la versión estable llegará el 21 de abril. Entre sus novedades, se espera que use GNOME 42 (actualmente usa GNOME 40) y la última versión de libadwaita, pero sólo unas pocas aplicaciones estarán totalmente adaptadas o re-basadas en GTK4. Estará soportado durante cinco años, por lo que, si no amplían el soporte de Linux 5.15, podría ser buena idea actualizar el kernel a finales de 2023.

from Linux Adictos https://ift.tt/3I3yNpr
via IFTTT

Clonezilla Live llega ahora con el kernel Linux 5.15 LTS

Clonezilla Live es una distribución, basada en el repositorio  Debian Sid, de arranque en vivo bastante conocida, ya que aporta multitud de herramientas para la resolución de problemas, restauración, el clonado de imágenes de disco, particionamiento, etc. Esta distribución está mantenida por Steven Shiau, y recientemente ha anunciado el lanzamiento de la versión Clonezilla Live 2.8.1, que viene potenciada con el kernel Linux 5.15.5 LTS por defecto.

Tras un mes y medio de desarrollo, tras el lanzamiento de la versión 2.8, por fin ha llegado. Ahora podrás descargar y usar Clonezilla Live 2.8.1 con uno de los últimos kernel lanzados con soporte a largo plazo. La versión previa de esta suite estaba potenciada por Linux 5.14, que llegó al fin de su ciclo de vida en noviembre del 2021.

Este kernel no solo significa disponer de los últimos parches y novedades implementadas en el núcleo, también es una ventaja para Clonezilla Live, que verá cómo se mejora el soporte de hardware. Por otro lado, la integración de este kernel no es lo único nuevo en esta versión del Live, también se han incluido mejoras en el soporte de detección de discos hd1, hd2, etc., se ha agregado una nueva función para evitar que se divida el archivo de imagen de una partición cuando se guarda una imagen por el script ocs-sr.

Otra de las novedades de esta versión de Clonezilla Live es que ha añadido soporte para dracut para mejorar la restauración de sistemas CentOS Linux 6.x. Por otro lado, se han corregido varios bugs que estaban afectando a versiones anteriores, también hay actualizaciones para mejorar los scripts, se han actualizado también las traducciones de varios lenguajes en los que está disponible este sistema, etc.

Si te interesa, puedes descargarlo ahora de forma totalmente gratuita y quemarla ISO en un disco óptico o en una memoria USB:

Descargar Clonezilla Live – Sitio web oficial

from Linux Adictos https://ift.tt/3rBx7NF
via IFTTT

Clonezilla Live llega ahora con el kernel Linux 5.15 LTS

Clonezilla Live es una distribución, basada en el repositorio  Debian Sid, de arranque en vivo bastante conocida, ya que aporta multitud de herramientas para la resolución de problemas, restauración, el clonado de imágenes de disco, particionamiento, etc. Esta distribución está mantenida por Steven Shiau, y recientemente ha anunciado el lanzamiento de la versión Clonezilla Live 2.8.1, que viene potenciada con el kernel Linux 5.15.5 LTS por defecto.

Tras un mes y medio de desarrollo, tras el lanzamiento de la versión 2.8, por fin ha llegado. Ahora podrás descargar y usar Clonezilla Live 2.8.1 con uno de los últimos kernel lanzados con soporte a largo plazo. La versión previa de esta suite estaba potenciada por Linux 5.14, que llegó al fin de su ciclo de vida en noviembre del 2021.

Este kernel no solo significa disponer de los últimos parches y novedades implementadas en el núcleo, también es una ventaja para Clonezilla Live, que verá cómo se mejora el soporte de hardware. Por otro lado, la integración de este kernel no es lo único nuevo en esta versión del Live, también se han incluido mejoras en el soporte de detección de discos hd1, hd2, etc., se ha agregado una nueva función para evitar que se divida el archivo de imagen de una partición cuando se guarda una imagen por el script ocs-sr.

Otra de las novedades de esta versión de Clonezilla Live es que ha añadido soporte para dracut para mejorar la restauración de sistemas CentOS Linux 6.x. Por otro lado, se han corregido varios bugs que estaban afectando a versiones anteriores, también hay actualizaciones para mejorar los scripts, se han actualizado también las traducciones de varios lenguajes en los que está disponible este sistema, etc.

Si te interesa, puedes descargarlo ahora de forma totalmente gratuita y quemarla ISO en un disco óptico o en una memoria USB:

Descargar Clonezilla Live – Sitio web oficial

from Linux Adictos https://ift.tt/3rBx7NF
via IFTTT

Un grupo de hackers están explotando las vulnerabilidades de Apache Log4j

log4j

Se dio a conocer la noticia de que hace poco detectaron a un grupo de hackers patrocinado por el estado iraní los cuales están explotando activamente las vulnerabilidades en Apache Log4j para distribuir un nuevo conjunto de herramientas modular de PowerShell.

Detallado por investigadores de Check Point Software Technologies, el grupo de hackers APT35, también conocido como Phosphorous and Charming Kitten, fue detectado por primera vez explotando Log4j solo cuatro días después de que se revelara la primera vulnerabilidad.

La configuración del ataque se describe como apresurada, ya que el grupo usó únicamente un kit básico de explotación JNDI de código abierto.

Habiendo obtenido acceso a un servicio vulnerable, los hackers iraníes incluyeron un nuevo marco modular basado en PowerShell que se denominó «CharmPower». El script se utiliza para establecer la persistencia, recopilar información y ejecutar comandos.

CharmPower tiene cuatro módulos iniciales principales:

  • El primero valida una conexión de red
  • El segundo recopila información básica del sistema, como la versión de Windows, el nombre de la computadora y el contenido de varios archivos del sistema.
  • El tercer módulo decodifica el dominio de comando y control recuperado de una URL codificada almacenada en un depósito S3 de Amazon Web Services Inc
  • Mientras que el módulo final recibe, descifra y ejecuta los módulos de seguimiento.

Según la información recopilada por la implementación inicial, APT35 luego implementa módulos personalizados adicionales para facilitar el robo de datos y ocultar su presencia en la máquina infectada.

APT35 es un conocido grupo de hackers que estuvo relacionado con ataques en 2020 contra la campaña de Trump, funcionarios actuales y anteriores del gobierno de EE. UU., periodistas que cubren la política mundial y destacados iraníes que viven fuera de Irán. El grupo también apuntó a la Conferencia de Seguridad de Munich ese mismo año.

“La investigación que relaciona la explotación de Log4Shell con el APT Charming Kitten iraní coincide, y de alguna manera entra en conflicto, con una declaración hecha por la Agencia de Seguridad e Infraestructura de Ciberseguridad de EE. UU. el 10 de enero que sugería que no había habido intrusiones significativas relacionadas con el error en ese momento”.

“Esto probablemente enfatiza los problemas actuales con la divulgación y transparencia de incidentes, y el retraso que puede existir entre la actividad del actor de amenazas y el descubrimiento.

John Bambenek, principal cazador de amenazas de la empresa de administración de servicios de tecnología de la información Netenrich Inc. , dijo que no es sorprendente que los actores de segundo nivel del estado-nación aprovechen la oportunidad presentada por la vulnerabilidad log4j de manera apresurada.

“Cualquier hazaña de esta gravedad sería aprovechada por cualquiera que busque un punto de apoyo rápido y, a veces, se abren ventanas tácticas como esta, lo que significa que hay que actuar con rapidez”, dijo Bambenek. “La pregunta más importante es qué agencia de inteligencia estaba usando esto antes de que se hiciera pública la vulnerabilidad”.

La falla de Log4j, que también se conoce como Log4Shell y se rastrea como CVE-2021-44228, es una amenaza importante debido al amplio uso empresarial de Log4j y la gran cantidad de servidores y servicios basados ​​en la nube que podrían estar expuestos vulnerabilidades del tipo zeroday. Log4j, una herramienta de código abierto gratuita y ampliamente distribuida de Apache Software Foundation, es una herramienta de registro y la falla afecta a la versión 2.0 a la 2.14.1.

Los profesionales de la seguridad han dicho que la amenaza que representa Log4Shell es tan alta no solo por el alcance del uso de la herramienta, sino también por la facilidad con la que se puede explotar la vulnerabilidad. Los actores de amenazas solo necesitan enviar una cadena que incluya el código malicioso, que Log4j analiza y registra y carga en un servidor. Luego, los piratas informáticos pueden obtener el control d

La noticia de que los hackers iraníes estaban explotando las vulnerabilidades de Log4j se produjo cuando la Fuerza de Misión Nacional Cibernética del Comando Cibernético de EE. UU. reveló que había identificado varias herramientas de código abierto que los agentes de inteligencia iraníes están utilizando en redes de todo el mundo.

La divulgación se relaciona con un grupo de hackers patrocinado por el estado iraní denominado “MuddyWater”.

El grupo ha estado vinculado al Ministerio de Inteligencia y Seguridad de Irán y se dirige principalmente a otras naciones en el Medio Oriente y, en ocasiones, a países de Europa y América del Norte.

Si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/3tr4THG
via IFTTT

Google solicito a EE. UU. que haga que de los proyectos open source criticos sean más seguros

Después de la «Summit on open-source security» organizada en la Casa Blanca, Google ha pedido una mayor participación del gobierno en la identificación y protección de proyectos críticos de software de código abierto.

Mediante una publicación Kent Walker, presidente de asuntos globales y director legal de Google, quien dijo en una publicación de blog que se necesita una colaboración más estrecha entre el sector privado y el gobierno para garantizar más financiamiento y liderazgo para la seguridad del software de código abierto.

“Necesitamos una asociación público-privada para identificar una lista de proyectos críticos de código abierto, con la criticidad determinada en función de la influencia y la importancia de un proyecto, para ayudar a priorizar y asignar recursos para las evaluaciones y mejoras de seguridad más esenciales”, escribió Walker.

A más largo plazo, esa asociación debe idear nuevas formas de identificar el software de código abierto que podría representar un riesgo sistémico, en función de cómo se integre con proyectos críticos, de modo que pueda anticipar el nivel de seguridad necesario para garantizar su seguridad. , agregó Walker.

Google también quiere que el gobierno y las industrias se unan para establecer estándares de referencia para la seguridad, el mantenimiento, la procedencia y las pruebas del software de código abierto.

Eso es para garantizar que la infraestructura nacional y otros sistemas importantes puedan confiar en dichos proyectos. Walker dijo que los estándares deben desarrollarse a través de un proceso colaborativo que enfatice actualizaciones frecuentes, pruebas continuas e integridad verificada.

Por último, Walker solicitó más fondos tanto del gobierno como del sector privado. Señaló que muchas empresas y organizaciones líderes ni siquiera saben cuánto de su infraestructura crítica se basa en proyectos de código abierto.

Para remediar eso, pidió una mayor conciencia, así como la creación de un mercado para el mantenimiento de código abierto que uniría a los voluntarios de empresas y organizaciones con proyectos críticos que necesitan apoyo. Walker prometió que Google está listo para apoyar tal iniciativa.

La falta de recursos para el mantenimiento y la seguridad del software de código abierto es un problema que se planteó en el pasado, pero resurgió este mes tras el descubrimiento de una falla grave en la biblioteca Java de Log4j, una de las mayores vulnerabilidades de ciberseguridad detectadas en años recientes. La biblioteca Log4j es de código abierto, en su mayoría desarrollada y mantenida por mano de obra no remunerada.

“El código de software de código abierto está disponible para el público, gratis para que cualquiera lo use, modifique o inspeccione”, escribió Walker. “Es por eso que muchos aspectos de la infraestructura crítica y los sistemas de seguridad nacional lo incorporan. Pero no hay asignación oficial de recursos y pocos requisitos o estándares formales para mantener la seguridad de ese código crítico. De hecho, la mayor parte del trabajo para mantener y mejorar la seguridad del código abierto, incluida la reparación de vulnerabilidades conocidas, se realiza de forma voluntaria ad hoc”.

La mayor parte de la financiación del software de código abierto suele provenir de donaciones individuales de simpatizantes o del patrocinio de empresas tecnológicas que dependen de él. Por ejemplo, Google comprometió recientemente $100 millones para el programa de recompensas Secure Open Source de la Fundación Linux, cuyo objetivo es proporcionar una compensación financiera a los desarrolladores que mejoran la seguridad de los proyectos clave.

Por su parte, la unidad Red Hat de IBM Corp., cuyos ejecutivos asistieron a la reunión del Consejo de Seguridad Nacional de la Casa Blanca, dijo que apoya los esfuerzos del gobierno para mejorar la seguridad de todo tipo de software.

“Un tema clave de la reunión fue el reconocimiento de que el software de código abierto ha acelerado el ritmo de la innovación tecnológica, brinda enormes beneficios sociales y económicos y puede contribuir en gran medida a mejorar la confianza y la ciberseguridad”, dijo Red Hat en un comunicado

“Esperamos trabajar con la Administración y un amplio conjunto de partes interesadas en los próximos pasos y continuaremos enfocándonos en apoyar a nuestros clientes y fortalecer el ecosistema de código abierto”.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/3noUOr3
via IFTTT

BumbleBee, un excelente proyecto para simplificar la creación y distribución de programas eBPF

Solo.io, la empresa de informática en la nube, microservicios, sandboxed y serverless, dio a conocer el proyecto de código abierto «BumbleBee». El nuevo proyecto simplifica la experiencia del desarrollador para construir, empaquetar y distribuir herramientas eBPF, según Solo.

BumbleBee genera automáticamente un código de espacio de usuario repetitivo para desarrollar herramientas eBPF, explicó la compañía. También brinda una experiencia similar a Docker para empaquetar un programa eBPF. Esto le permite conectarse a otros flujos de trabajo de imágenes OCI para su publicación y distribución.

Sobre BumbleBee

BumbleBee hace posible empaquetar un programa eBPF como una imagen de contenedor de Open Container Initiative (OCI) que se puede ejecutar en cualquier sistema sin volver a compilar o usar componentes adicionales en el espacio del usuario.

La interacción con el código eBPF en el kernel, incluido el procesamiento de datos provenientes del procesador eBPF, es manejada por BumbleBee, que exporta automáticamente estos datos en forma de métricas, histogramas o registros, a los que se puede acceder, por ejemplo, usando la utilidad curl. El enfoque propuesto permite al desarrollador concentrarse en escribir código eBPF y no distraerse con la organización de la interacción con este código desde el espacio del usuario, el ensamblaje y la carga en el kernel.

El CEO de Solo.io, Idit Levine, dice que:

La compañía desarrolló BumbleBee para generar automáticamente el código de espacio de usuario repetitivo que se requiere para acceder a las tecnologías eBPF que se ejecutan a nivel de kernel. BumbleBee incluye una interfaz de línea de comandos (CLI) que genera automáticamente el código de espacio de usuario para los programas eBPF mediante la exposición automática de mapas como registros, métricas e histogramas.

Para administrar los programas eBPF, se ofrece una utilidad estilo Docker «bee», con la que puede descargar inmediatamente el controlador eBPF de interés desde un repositorio externo y ejecutarlo en el sistema local.

El kit de herramientas le permite generar un marco de código C para los controladores eBPF de un tema seleccionado (actualmente solo se admiten los controladores de red y de archivos que interceptan llamadas a la pila de red y los sistemas de archivos). Basado en el marco generado, el desarrollador puede implementar rápidamente la funcionalidad que le interesa.

A diferencia de BCC (BPF Compiler Collection), BumbleBee no reconstruye completamente el código del controlador para cada versión del kernel de Linux (BCC usa la compilación sobre la marcha con Clang cada vez que se ejecuta el programa eBPF).

Para resolver los problemas de portabilidad, se están desarrollando los kits de herramientas CO-RE y libbpf, que le permiten compilar código una sola vez y usar un cargador universal especial que adapta el programa cargado al kernel actual y los tipos BTF (formato de tipo BPF).

BumbleBee es un complemento sobre libbpf y proporciona tipos adicionales para la interpretación automática y visualización de datos colocados en estructuras de mapas eBPF estándar RingBuffer y HashMap.

Para construir el programa eBPF final y guardarlo como una imagen OCI, simplemente se debe ejecutar el comando:

bee build file_with_code name:version

Y ejecutar el comando

bee run name:version

De forma predeterminada, los eventos recibidos del controlador se mostrarán en la ventana del terminal, pero si es necesario, puede obtener los datos llamando a las utilidades curl o wget en el puerto de red vinculado al controlador.

Los controladores se pueden distribuir a través de repositorios compatibles con OCI, por ejemplo, para ejecutar un controlador externo desde el repositorio ghcr.io (GitHub Container Registry), puede ejecutar el comando

bee run ghcr.io/solo-io/bumblebee/tcpconnect:$(bee version)

Para poner el controlador en el repositorio, se ofrece el comando

bee push

Y para vincular la versión

bee tag

El mayor beneficio de eBPF es simplemente la eficiencia. El costo total de procesamiento para plataformas de seguridad, redes y almacenamiento debería disminuir a medida que más proveedores aprovechen sus capacidades. 

Actualmente, eBPF es ampliamente utilizado por empresas de escala web, como proveedores de servicios en la nube. Facebook lo está utilizando como el principal equilibrador de carga definido por software en sus centros de datos, mientras que Google está utilizando el software de red Cilium de código abierto dentro de sus ofertas administradas de Kubernetes. 

Sin embargo, en el futuro, Levine dice que ahora es solo cuestión de tiempo antes de que eBPF se adopte mucho más ampliamente a medida que más sistemas operativos permiten la capacidad.

Finalmente si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/3I0GoFq
via IFTTT

Los mejores IDS para Linux

IDS intrusion detection system

La seguridad es un tema vital en cualquier sistema. Algunos creen que los sistemas *nix son invulnerables a cualquier ataque o que no pueden ser infectados con malware. Y eso es una idea errónea. Siempre hay que mantener la guardia, nada es 100% seguro. Por eso, deberías implementar sistemas que te ayuden a detectar, frenar, o minimizar los daños de un ciberataque. En este artículo verás qué es un IDS y algunos de los mejores para tu distro Linux.

¿Qué es un IDS?

Un IDS (Intrusion Detection System), o sistema de detección de intrusos, es un sistema de monitorización que detecta actividades sospechosas y genera una serie de alertas para informar de las violaciones (pueden ser detectadas por comparación de firmas de los archivos, escaneo de patrones o anomalías maliciosas, monitorizando comportamiento, configuraciones, tráfico de red …) que se hayan podido producir en el sistema.

Gracias a esas alertas, se puede investigar el origen del problema y tomar medidas adecuadas para remediar la amenaza. Aunque, no detecta todos los ataques, hay métodos de evasión, y tampoco los bloquea, solo informa de ello. Además, si se basa en firmas, las amenazas más recientes (0-day), también pueden escapar y no ser detectadas.

Tipos

Fundamentalmente, existen dos tipos de IDS:

  • HIDS (Host-Based IDS): se implementa en un endpoint o máquina en particular y está diseñado para detectar amenazas internas y externas. Ejemplos son OSSEC, Wazuh, y Samhain.
  • NIDS (Network-based IDS): para supervisar toda una red, pero carecen de visibilidad dentro de los endpoints conectados a dicha red. Ejemplos son Snort, Suricata, Bro, y Kismet.

Diferencias con un firewall, IPS y UTM, SIEM…

Existen varios términos que pueden llevar a confusión, pero que tienen diferencias con un IDS. Algunos de los términos relacionados con la seguridad que también deberías conocer son:

  • Firewall: se parece más a un IPS que a un IDS, ya que es un sistema de detección activo. Un cortafuegos está diseñado para bloquear o permitir ciertas comunicaciones, en función de las reglas que se hayan configurado. Se puede implementar tanto por software como por hardware.
  • IPS: son las siglas de Intrusion Prevention System, y es un complemento para un IDS. Es un sistema capaz de prevenir ciertos eventos, por tanto es un sistema activo. Dentro de los IPS se pueden distinguir 4 tipos fundamentales:
    • NIPS: basados en red y por tanto buscan tráfico de red sospechoso.
    • WIPS: como los NIPS, pero para redes inalámbricas.
    • NBA: se basa en el comportamiento de la red, examinando tráfico inusual.
    • HIPS: buscan actividades sospechosas en host únicos.
  • UTM: son las siglas de Unified Threat Managment, un sistema de gestión para ciberseguridad que proporciona múltiples funciones centralizadas. Por ejemplo, incluyen firewall, IDS, antimalware, antispam, filtrado de contenidos, algunos incluso VPN, etc.
  • Otros: también existen otros términos relacionados con la ciberseguridad que seguro has escuchado:
    • SIM: son las siglas de Security Information Manager, o gestión de información de seguridad. En este caso, es un registros central que agrupa todos los datos referentes a seguridad para generar informes, analizar, tomar decisiones, etc. Es decir, un conjunto de capacidades para almacenar a largo plazo dicha información.
    • SEM: una función Security Event Manager, o gestión de eventos de seguridad, se encarga de detectar patrones anormales en accesos, otorga la capacidad de monitorización en tiempo real, correlación de eventos, etc.
    • SIEM: es la combinación de SIM y SEM, y es una de las principales herramientas usadas en SOC o centros de operaciones de seguridad.

Los mejores IDS para Linux

IDS

En cuanto a los mejores sistemas IDS que puedes encontrar para GNU/Linux, tienes los siguientes:

  • Bro (Zeek): es de tipo NIDS y tiene funciones de registro de tráfico y análisis, monitor de tráfico SNMP, y actividad FTP, DNS, y  HTTP, etc.
  • OSSEC:  es de tipo HIDS, de código abierto y gratuito. Además, es multiplataforma, y sus registros incluyen también FTP, datos del servidor web y email.
  • Snort: es uno de los más famosos, de código abierto, y de tipo NIDS. Incluye sniffer para paquetes, registro para paquetes de red, threat intelligence, bloqueo de firmas, actualizaciones en tiempo real de las firmas de seguridad, habilidad para detectar eventos muy numerosos (OS, SMB, CGI, buffer overflow,  puertos ocultos,…).
  • Suricata: otro tipo NIDS, también de código abierto. Puede monitorizar actividad a bajo nivel, como TCP, IP, UDP, ICMP, y TLS, en tiempo real para aplicaciones como SMB, HTTP, y FTP. Permite la integración con herramientas de terceros como Anaval, Squil, BASE, Snorby, etc.
  • Security Onion: NIDS/HIDS, otro sistema IDS especialmente focalizado a las distros Linux, con capacidad para detectar intrusos, monitorización empresarial, sniffer de paquetes, incluye gráficos de lo que sucede, y se pueden usar herramientas como NetworkMiner, Snorby, Xplico, Sguil, ELSA, y Kibana.

from Linux Adictos https://ift.tt/3K5uAU9
via IFTTT

Nuevamente… encontraron otra vulnerabilidad en el subsistema eBPF

Recientemente se dio a conocer la noticia de que identificaron una nueva vulnerabilidad (ya catalogada bajo el CVE-2021-4204) en el subsistema eBPF (para variar)…

Y es que el subsistema eBPF no ha dejado de ser una gran problemática de seguridad para el Kernel pues fácilmente en lo que fue todo el 2021 se dieron a conocer dos vulnerabilidades por mes y de las cuales hablamos de algunas de ellas aquí en el blog.

En cuanto a los detalles del actual problema se menciona que la vulnerabilidad detectada permite que un controlador se ejecute dentro del kernel de Linux en una máquina virtual JIT especial y que este a su vez permite que un usuario local sin privilegios obtenga una escalada de privilegios y ejecutar su código a nivel del kernel.

En la descripción del problema, mencionan que la vulnerabilidad se debe a un escaneo incorrecto de los programas eBPF transmitidos para su ejecución, ya que el subsistema eBPF proporciona funciones auxiliares, cuya corrección es verificada por un verificador especial.

Esta vulnerabilidad permite a los atacantes locales aumentar los privilegios en
instalaciones afectadas de Linux Kernel. Un atacante primero debe obtener la
capacidad de ejecutar código con pocos privilegios en el sistema de destino para
explotar esta vulnerabilidad.

La falla específica existe en el manejo de los programas eBPF. La cuestión resulta de la falta de validación adecuada de los programas eBPF proporcionados por el usuario antes de ejecutarlos. 

Ademas de ello, algunas de las funciones requieren que el valor PTR_TO_MEM se pase como argumento y el verificador debe conocer el tamaño de la memoria asociada con el argumento para evitar posibles problemas de desbordamientos de búfer.

Mientras que para las funciones bpf_ringbuf_submit y bpf_ringbuf_discard, los datos sobre el tamaño de la memoria transferida no se informan al verificador (es aqui donde el problema comienza), lo que aprovecha el atacante para poder usar para sobrescribir áreas de memoria fuera del límite del búfer al ejecutar un código eBPF especialmente diseñado.

Un atacante puede aprovechar esta vulnerabilidad para escalar privilegios y ejecutar código en el contexto del kernel. TENGA EN CUENTA que bpf sin privilegios está deshabilitado de forma predeterminada en la mayoría de las distribuciones.

Se menciona que para que un usuario pueda llevar a cabo un ataque, el usuario debe poder cargar su programa BPF y muchas distribuciones recientes de Linux lo bloquean de forma predeterminada (incluido el acceso sin privilegios a eBPF ahora está prohibido de forma predeterminada en el propio kernel, a partir de la versión 5.16).

Por ejemplo, se menciona que la vulnerabilidad puede ser explotada en la configuración por defecto en una distribucion que aún es bastante utilizada y sobre todo muy popular como lo es Ubuntu 20.04 LTS, pero en los entornos como Ubuntu 22.04-dev, Debian 11, openSUSE 15.3, RHEL 8.5, SUSE 15-SP4 y Fedora 33, solo se manifiesta si el administrador ha establecido el parámetro kernel.unprivileged_bpf_disabled en 0.

Actualmente, como solución alternativa para bloquear la vulnerabilidad, se menciona que se puede evitar que los usuarios sin privilegios ejecuten programas BPF ejecutando en una terminal el comando:

sysctl -w kernel.unprivileged_bpf_disabled=1

Finalmente, cabe mencionar que el problema ha aparecido desde el kernel de Linux 5.8 y permanece sin parches (incluida la versión 5.16) y es por ello que el código de explotación se retrasará durante 7 días y se publicará a las 12:00 UTC, es decir el 18 de enero de 2022.

Con ello se pretende dar el tiempo suficiente para que los parches correctivos sean puestos a disposición de los usuarios de las diferentes distribuciones de linux dentro de los canales oficiales de cada una de estas y tanto desarrolladores como usuarios puedan corregir dicha vulnerabilidad.

Para quienes estén interesados en poder conocer sobre el estado de la formación de actualizaciones con la eliminación del problema en alguna de las principales distribuciones, deben saber que se pueden rastrear desde estas páginas:  Debian, RHEL, SUSE, Fedora, Ubuntu, Arch.

Si estás interesado en poder conocer más al respecto sobre la nota, puedes consultar el comunicado original en el siguiente enlace.

from Linux Adictos https://ift.tt/3GpD8mE
via IFTTT