Monthly Archives: June 2023

Debido a las restricciones de RHEL AlmaLinux y Rocky Linux reconstruirán sus procesos

Posted on by
AlmaLinux y Rocky Linux

AlmaLinux y Rocky Linux responden a la reciente restricción de Red Hat

Hace poco, compartimos aquí en el blog la noticia de los cambios realizados por parte de Red Hat con relación al acceso al código (puedes consultar los detalles en la publicación aquí), en el cual básicamente restringe el acceso a codigo de RHEL afectando a terceros. Entre los principales problemas de la transición de AlmaLinux y Rocky Linux a CentOS Stream está la desincronización de la publicación de paquetes para RHEL y CentOS Stream.

Y es que como se menciono, el código del paquete RHEL ahora estará disponible públicamente solo a través del repositorio CentOS Stream, que sirve como base para futuras versiones de RHEL.

Sobre el caso, los proyectos AlmaLinux y Rocky Linux, que publican compilaciones compatibles con binarios de Red Hat Enterprise Linux, ya se han pronunciado al respecto y han emitido sus declaraciones con una hoja de ruta siguiendo la restricción de Red Hat del acceso público al código fuente de los paquetes RHEL.

En particular, no todas las fuentes de paquetes presentes en RHEL se migran a CentOS Stream al mismo tiempo, en el mismo orden y de la misma forma (es posible que a los paquetes publicados en CentOS Stream les falten algunos parches).

Las soluciones a corto y largo plazo para este cambio son algo que discutiremos en las próximas semanas. Dedicamos gran parte de nuestro tiempo hoy a profundizar para asegurarnos de que comprendimos la profundidad del problema y discutimos nuestras posibles opciones.

A corto plazo, trabajaremos con otros miembros del ecosistema RHEL para garantizar que continuamos brindando actualizaciones de seguridad con la velocidad y la estabilidad que nos caracterizan.

A largo plazo, trabajaremos con esos mismos socios y con nuestra comunidad para identificar el mejor camino a seguir para AlmaLinux como parte del ecosistema empresarial de Linux. Comparte Benny Vasquez, Presidente, Junta Directiva de la Fundación AlmaLinux OS

Por ejemplo, las actualizaciones relacionadas con la reparación de vulnerabilidades en paquetes con el kernel de Linux pueden publicarse en CentOS Stream con cierto retraso. Tampoco hay garantía de que los paquetes aparezcan en el repositorio de CentOS Stream en el momento del lanzamiento de RHEL o después.

Además, los números de versión de los paquetes en CentOS Stream y RHEL no siempre coinciden. El problema también surge con los términos de soporte: CentOS Stream se actualiza dentro de los 5 años posteriores al lanzamiento, y la vida útil completa de la distribución RHEL es de 10 años, es decir, CentOS Stream no puede ser una fuente de actualización para los últimos 5 años del ciclo de vida de una distribución.

Para los clientes, Red Hat ha dejado la posibilidad de descargar el código srpm de RHEL a través de una sección cerrada del sitio, que tiene un acuerdo de usuario adicional (EULA) que prohíbe la redistribución de RHEL. AlmaLinux y Rocky Linux usan paquetes srpm descargados del Portal de clientes de Red Hat con riesgos legales.

Si bien esta decisión cambia la automatización que usamos para construir Rocky Linux, ya hemos creado una mitigación a corto plazo y estamos desarrollando una estrategia a largo plazo. No habrá interrupciones ni cambios para ningún usuario, colaborador o socio de Rocky Linux.

AlmaLinux y Rocky Linux tienen la intención de continuar creando compilaciones que reproduzcan paquetes de Red Hat Enterprise Linux, sean totalmente compatibles con binarios, tengan un comportamiento idéntico (a nivel de errores) y se puedan usar como reemplazo de RHEL.

Las distribuciones tendrán que volver a trabajar en los procesos internos de generación de lanzamientos, pero nada cambiará para los usuarios y socios, los proyectos continuarán generando compilaciones rápidamente como antes. Para evitar la interrupción en la entrega de actualizaciones, ambos proyectos utilizarán primero una solución temporal, después de lo cual planean determinar una estrategia a largo plazo e implementar una solución a largo plazo más reflexiva, cuyas opciones aún se están discutiendo.

Como solución temporal, el proyecto AlmaLinux tiene la intención de cambiar al seguimiento de cambios desde el repositorio de CentOS Stream y también usar los repositorios de Oracle Linux para continuar generando actualizaciones de paquetes para corregir vulnerabilidades. Las actualizaciones generadas se revisarán y ajustarán más para garantizar la total compatibilidad con las actualizaciones de RHEL sin infringir los términos de la licencia de Red Hat.

Una solución alternativa para Rocky Linux es crear un repositorio adicional para controlar las actualizaciones no sincronizadas, obtener los paquetes srpm asociados con las actualizaciones faltantes mediante una solución alternativa y manualmente cárguelos en el repositorio de ensayo. Al principio, planean recibir paquetes a través de una suscripción a RHEL. En el camino, planean realizar un análisis legal del modelo propuesto y la posibilidad de colocar paquetes srpm en su repositorio sin cambiar la marca.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en los siguientes enlaces.

Anuncio de AlmaLinux: https://almalinux.org

Anuncio de Rocky Linux: https://rockylinux.org

from Linux Adictos https://ift.tt/ATkFabU
via IFTTT

Russian Cybersecurity Executive Arrested for Alleged Role in 2012 Megahacks

Posted on by

Nikita Kislitsin, formerly the head of network security for one of Russia’s top cybersecurity firms, was arrested last week in Kazakhstan in response to 10-year-old hacking charges from the U.S. Department of Justice. Experts say Kislitsin’s prosecution could soon put the Kazakhstan government in a sticky diplomatic position, as the Kremlin is already signaling that it intends to block his extradition to the United States.

Nikita Kislitsin, at a security conference in Russia.

Kislitsin is accused of hacking into the now-defunct social networking site Formspring in 2012, and conspiring with another Russian man convicted of stealing tens of millions of usernames and passwords from LinkedIn and Dropbox that same year.

In March 2020, the DOJ unsealed two criminal hacking indictments against Kislitsin, who was then head of security at Group-IB, a cybersecurity company that was founded in Russia in 2003 and operated there for more than a decade before relocating to Singapore.

Prosecutors in Northern California indicted Kislitsin in 2014 for his alleged role in stealing account data from Formspring. Kislitsin also was indicted in Nevada in 2013, but the Nevada indictment does not name his alleged victim(s) in that case.

However, documents unsealed in the California case indicate Kislitsin allegedly conspired with Yevgeniy Nikulin, a Russian man convicted in 2020 of stealing 117 million usernames and passwords from Dropbox, Formspring and LinkedIn in 2012. Nikulin is currently serving a seven-year sentence in the U.S. prison system.

As first reported by Cyberscoop in 2020, a trial brief in the California investigation identified Nikulin, Kislitsin and two alleged cybercriminals — Oleg Tolstikh and Oleksandr Vitalyevich Ieremenko — as being present during a 2012 meeting at a Moscow hotel, where participants allegedly discussed starting an internet café business.

A 2010 indictment out of New Jersey accuses Ieremenko and six others with siphoning nonpublic information from the U.S. Securities & Exchange Commission (SEC) and public relations firms, and making $30 million in illegal stock trades based on the proprietary information they stole.

[The U.S. Secret Service has an outstanding $1 million reward for information leading to the arrest of Ieremenko (Александр Витальевич Еременко), who allegedly went by the hacker handles “Zl0m” and “Lamarez.”]

Kislitsin was hired by Group-IB in January 2013, nearly six months after the Formspring hack, and he was still director of security at the company when the DOJ unsealed indictments against him in 2020. Group-IB has since moved its headquarters to Singapore, and in April 2023 the company announced it had fully exited the Russian market.

In a statement provided to KrebsOnSecurity, Group-IB said Mr. Kislitsin is no longer an employee, and that he now works for a Russian organization called FACCT, which stands for “Fight Against Cybercrime Technologies.”

“Dmitry Volkov, co-founder and CEO, sold his stake in Group-IB’s Russia-based business to the company’s local management,” the statement reads. “The stand-alone business in Russia has been operating under the new brand FACCT ever since and will continue to operate as a separate company with no connection to Group-IB.”

FACCT says on its website that it is a “Russian developer of technologies for combating cybercrime,” and that it works with clients to fight targeted attacks, data leaks, fraud, phishing and brand abuse. In a statement published online, FACCT said Kislitsin is responsible for developing its network security business, and that he remains under temporary detention in Kazakhstan “to study the basis for extradition arrest at the request of the United States.”

“According to the information we have, the claims against Kislitsin are not related to his work at FACCT, but are related to a case more than 10 years ago when Nikita worked as a journalist and independent researcher,” FACCT wrote.

From 2006 to 2012, Kislitsin was editor-in-chief of “Hacker,” a popular Russian-language monthly magazine that includes articles on information and network security, programming, and frequently features interviews with or articles penned by notable (and/or wanted) Russian hackers.

“We are convinced that there are no legal grounds for detention on the territory of Kazakhstan,” the FACCT statement continued. “The company has hired lawyers who have been providing Nikita with all the necessary assistance since last week, and we have also sent an appeal to the Consulate General of the Russian Federation in Kazakhstan to assist in protecting our employee.”

FACCT indicated that the Kremlin has already intervened in the case, and the Russian government claims Kislitsin is wanted on criminal charges in Russia and must instead be repatriated to his homeland.

“The FACCT emphasizes that the announcement of Nikita Kislitsin on the wanted list in the territory of the Russian Federation became known only today, June 28, 6 days after the arrest in Kazakhstan,” FACCT wrote. “The company is monitoring developments.”

The Kremlin followed a similar playbook in the case of Aleksei Burkov, a cybercriminal who long operated two of Russia’s most exclusive underground hacking forums. Burkov was arrested in 2015 by Israeli authorities, and the Russian government fought Burkov’s extradition to the U.S. for four years — even arresting and jailing an Israeli woman on phony drug charges to force a prisoner swap.

That effort ultimately failed: Burkov was sent to America, pleaded guilty, and was sentenced to nine years in prison.

Alexei Burkov, seated second from right, attends a hearing in Jerusalem in 2015. Image: Andrei Shirokov / Tass via Getty Images.

Arkady Bukh is a U.S. attorney who has represented dozens of accused hackers from Russia and Eastern Europe who were extradited to the United States over the years. Bukh said Moscow is likely to turn the Kislitsin case into a diplomatic time bomb for Kazakhstan, which shares an enormous border and a great deal of cultural ties with Russia. A 2009 census found that Russians make up about 24 percent of the population of Kazakhstan.

“That would put Kazakhstan at a crossroads to choose between unity with Russia or going with the West,” Bukh said. “If that happens, Kazakhstan may have to make some very unpleasant decisions.”

Group-IB’s exodus from Russia comes as its former founder and CEO Ilya Sachkov remains languishing in a Russian prison, awaiting a farcical trial and an inevitable conviction on charges of treason. In September 2021, the Kremlin issued treason charges against Sachkov, although it has so far refused to disclose any details about the allegations.

Sachkov’s pending treason trial has been the subject of much speculation among denizens of Russian cybercrime forums, and the consensus seems to be that Sachkov and Group-IB were seen as a little too helpful to the DOJ in its various investigations involving top Russian hackers.

Indeed, since its inception in 2003, researchers at Group-IB have helped to identify, disrupt and even catch a number of high-profile Russian hackers, most of whom got busted after years of stealing because they made the unforgivable mistake of stealing from their own citizens.

When the indictments against Kislitsin were unsealed in 2020, Group-IB issued a lengthy statement attesting to his character and saying they would help him with his legal defense. As part of that statement, Group-IB noted that “representatives of the Group-IB company and, in particular, Kislitsin, in 2013, on their own initiative, met with employees of the US Department of Justice to inform them about the research work related to the underground, which was carried out by Kislitsin in 2012.”

from Krebs on Security https://ift.tt/NPrhip2
via IFTTT

A partir de ahora CentOS Stream ahora será la única fuente de RHEL

Posted on by
red-hat

Red Hat Enterprise Linux es una distribucion de Linux que dirige sus productos principalmente para empresas

Hace poco Red Hat dio a conocer mediante una publicación de blog un cambio en el enfoque de la publicación de las fuentes de los paquetes para su distribución «Red Hat Enterprise Linux», con lo cual básicamente da a conocer que a partir de ahora ya no publicará el código del paquete en el repositorio Git de git.centos.org.

Mediante este anunció, Red Hat informa a la comunidad que la única fuente pública para los paquetes RHEL ahora será el repositorio CentOS Stream, con lo cual desde la publicación del anuncio, los clientes y socios de Red Hat aún podrán descargar el código de los paquetes correspondientes a las versiones de RHEL a través del portal de clientes de la empresa, cuyo acceso requiere una cuenta.

Hay que recordar que hace dos años, Red Hat decidió redirigir sus inversiones en CentOS a otra versión llamada CentOS Stream. Este último existe desde septiembre de 2019 y sirve como «una muestra de lo que vendrá en Red Hat Enterprise Linux», como una versión de prueba previa para probar las funciones que estarán presentes en RHEL dentro de un año.

Red Hat menciona que el motivo de dicho cambio es con la finalidad de «promover la evolución de CentOS Stream», pero sin tomar en cuenta las afectaciones que esto conlleva a los diversos proyectos que dependen de la base de estos paquetes.

En su publicación de blog Mike McGrath, vicepresidente de ingeniería de plataformas centrales en Red Hat, comparte lo siguiente:

A medida que crece la comunidad de CentOS Stream y el mundo del software empresarial aborda nuevas dinámicas, queremos afinar nuestro enfoque en CentOS Stream como la columna vertebral de la innovación empresarial de Linux. Seguimos invirtiendo y aumentando nuestro compromiso con CentOS Stream. CentOS Stream ahora será el único repositorio para los lanzamientos públicos de código fuente relacionados con RHEL. Para los clientes y socios de Red Hat, el código fuente permanecerá disponible a través del Portal de clientes de Red Hat.

Para ser claros, este cambio no significa ningún cambio en CentOS Project, CentOS Stream o la disponibilidad de fuente para CentOS Stream o CentOS SIG.

Se menciona que para los proyectos CentOS y CentOS Stream, el nuevo modelo de distribución de fuente no generará cambios notables, pero las distribuciones de terceros como AlmaLinux, Rocky Linux, Oracle Linux y EuroLinux, creadas mediante la reconstrucción de paquetes RHEL, tendrán que repensar significativamente sus procesos de desarrollo u obtener acceso mediante soluciones alternativas para empaquetar el código de las versiones de RHEL.

La esencia de los cambios es que el codigo fuente de los paquetes para las versiones ya publicadas se publicaron en git.centos.org, y el código del paquete para las versiones que aún no se han publicado se está desarrollando en el repositorio de CentOS Stream, es decir CentOS Stream actúa como una base continuamente actualizada para el desarrollo de RHEL, que no es totalmente compatible con RHEL en binario (CentOS Stream se puede considerar como compilaciones nocturnas de prueba de RHEL).

¿Por qué hacer este cambio?

Antes de CentOS Stream, Red Hat envió fuentes públicas de RHEL a git.centos.org. Cuando CentOS Project cambió para centrarse en CentOS Stream, mantuvimos estos repositorios a pesar de que CentOS Linux ya no se construía aguas abajo de RHEL. El compromiso en torno a CentOS Stream, los niveles de ingeniería de inversión y las nuevas prioridades que estamos abordando para clientes y socios ahora hacen que el mantenimiento de repositorios separados y redundantes sea ineficiente. El código fuente más reciente seguirá estando disponible a través de CentOS Stream.

El cese de la publicación de paquetes en git.centos.org se debe al hecho de que la distribución CentOS se ha transformado en CentOS Stream y ya no se crea a partir de la fuente de los paquetes RHEL. CentOS Stream se presenta como un proyecto recomendado y prioritario, y mantener repositorios separados se considera ineficiente.

Cabe mencionar que esta última decisión de Red Hat ha provocado reacciones en los foros con respecto a las diversas bifurcaciones de CentOS. Como hace dos años, la gente habla de traición y violación de los términos de la licencia GPL, algo de lo que ya se ha promovido la SFC (puedes consultar la publicación de ello en este enlace).

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/x5ABL1Z
via IFTTT

Wasmer 4.0 llega con la integración de Wasmer Edge nueva arquitectura de ejecución y mas

Posted on by
wasmer-sh

Wasmer es un tiempo de ejecución de WebAssembly rápido y seguro que permite que los contenedores súper livianos se ejecuten en cualquier lugar

Hace pocos días se dio a conocer el lanzamiento de la nueva versión del proyecto Wasmer 4.0, en la cual se han añadido diversos cambios de los cuales se destaca por ejemplo la nueva arquitectura que permite conectar corredores personalizados, la estabilización de WASI, unificación de WAPM en Wasmer e integración de Wasmer Edge.

Para quienes desconocen de Wasmer, deben saber que es un runtime para ejecutar módulos WebAssembly que se pueden usar para crear aplicaciones universales que se pueden ejecutar en diferentes sistemas operativos, así como para la ejecución aislada de código no confiable.

La capacidad de ejecutar la misma aplicación en diferentes plataformas se proporciona al compilar el código en un código intermedio WebAssembly de bajo nivel que puede ejecutarse en cualquier sistema operativo o integrarse en programas en otros lenguajes de programación. Los programas son contenedores livianos que ejecutan pseudocódigo WebAssembly. Estos contenedores no están vinculados al sistema operativo y pueden incluir código escrito originalmente en cualquier lenguaje de programación.

Principales novedades de Wasmer 4.0

En esta nueva versión que se presenta de Wasmer 4.0, se destaca el soporte integrado para la plataforma de computación en la nube Wasmer Edge, que permite interactuar con Wasmer Edge directamente a través de la CLI de wasmer. Wasmer Edge es una plataforma descentralizada sin servidor que permite ejecutar aplicaciones en otros hosts en la red Edge.

La nueva plataforma combina la asequibilidad de Cloudflare Workers, la simplicidad de Heroku y la funcionalidad de AWS Lambda. La plataforma puede escalar desde un solo servidor hasta grandes clústeres distribuidos. En comparación con Cloudflare Workers y AWS Lambda, las aplicaciones que se ejecutan en Wasmer Edge pueden procesar solicitudes de servicios TCP arbitrarios, ejecutar cualquier aplicación HTTP, ejecutar aplicaciones en el navegador y en un teléfono inteligente.

En este momento, se pueden ejecutar sitios web estáticos, cualquier servidor Rust usando tokio (como Axum), aunque a futuro se planea soportar Flask, Django, WordPress, Ruby on Rails, Node, entre otros.

Otro de los cambios que se destaca de esta nueva versión de Wasmer 4.0, es que se agregó el soporte para la API de WASIX. WASIX es la estabilización a largo plazo y el soporte de WASI ABI existente, además de extensiones de llamada al sistema no invasivas adicionales que completan las brechas que faltan lo suficiente como para permitir que se compilen y utilicen aplicaciones reales, prácticas y útiles ahora. WASI amplía las características para una compatibilidad total con POSIX. Con WASIX, Wasmer puede ejecutar aplicaciones que utilizan subprocesos múltiples, sockets de red, procesos secundarios de bifurcación y otras funciones avanzadas.

Ademas de ello en Wasmer 4.0, tambien podremos encontrar que se ha implementado una nueva arquitectura de ejecución que permite ejecutar cualquier tipo de aplicación en WebAssembly y ampliar la ABI sin lanzar nuevas versiones de tiempo de ejecución. Actualmente, se admiten tres ejecutores: WASIX (compatibilidad con ABI WASIX), Emscripten (ejecutar programas compilados en Emscripten) y WCGI (permite crear scripts CGI en WebAssembly).

Por otra parte, tambien se destaca que la funcionalidad del administrador de paquetes WAPM se ha integrado, con lo cual ahora todos los comandos de la utilidad wapm para publicar y mantener paquetes están integrados en la CLI de wasmer. La finalidad de la integración es disminuir la carga significativa para el desarrollo y tambien que WAPM solo ha sido adoptado por Wasmer.

Finalmente, cabe mencionar que los programas se distribuyen en forma de módulos WebAssembly ordinarios, que se pueden administrar mediante el administrador de paquetes WAPM. Wasmer también está disponible como una biblioteca que se puede usar para incrustar código WebAssembly en programas Rust, C/C++, C#, D, Python, JavaScript, Go, PHP, Ruby, Elixir y Java.

El código del proyecto está escrito en Rust y se distribuye bajo la licencia MIT y puedes consultar más al respecto, en el siguiente enlace.

¿Como instalar Wasmer?

Para los interesados en poder instalar la nueva versión, solo deben de abrir una terminal y en ella deben teclear el siguiente comando:

curl https://get.wasmer.io -sSfL | sh

from Linux Adictos https://ift.tt/Fg5haQv
via IFTTT