Construir un proyecto con Kubernetes tiene varios desafíos ocultos. Hoy hablaremos de los componentes clave de Kubernetes y echaremos un vistazo al interior del marco. Este artículo será útil para los desarrolladores que planeen utilizar Kubernetes para desarrollar aplicaciones web.

¿Qué es Kubernetes?

Kubernetes es un marco de orquestación de contenedores para el despliegue, la gestión y el escalado automatizados de software. Fue creado originalmente por Google como un proyecto interno en 2014. Ahora, Kubernetes es un proyecto de código abierto mantenido por la Cloud Native Computing Foundation y distribuido bajo la licencia de Apache 2.0.

El marco permite gestionar los contenedores en máquinas separadas, asegurando así que un sistema mantenga el estado deseado, que se especifica con las declaraciones YAML. Todo lo que un desarrollador de sistemas necesita hacer es crear una declaración precisa del sistema y un grupo de Kubernetes siempre tratará de mantener el estado declarado.

Lee también:

Microservicio y seguridad de los contenedores: 10 mejores prácticas

Beneficios del uso de Kubernetes

Esta plataforma de contenedores está evolucionando rápidamente. Consideremos las principales ventajas de los Kubernetes:

1. Es cómodo de usar. Para hacer que su sitio web se mantenga mientras el grupo de Kubernetes esté operativo, sólo tiene que hacerlo:
   • declarar un sitio web que incluye un contenedor con una aplicación de servidor, base de datos y almacenamiento de archivos
   • aplicar esta declaración del sitio web a un sistema de Kubernetes
2. El propio hardware (nodos, bases de datos, sistemas de almacenamiento de archivos) puede estar ubicado en cualquier lugar . Por lo tanto, es posible reducir los costos alquilando varias piezas de hardware de diferentes proveedores y luego combinando el hardware en un clúster de Kubernetes.
3. Es un proyecto de código abierto , así que puedes usarlo gratis e incluso contribuir a él. Todo el código fuente está disponible en GitHub, y la mayor parte está escrito en Go. Puedes crear una parte autónoma de Kubernetes y compartirla con la comunidad.

Tanto la AWS como los Kubernetes son herramientas para la creación de aplicaciones en la nube, pero como marco de trabajo, los Kubernetes superan a la AWS. De hecho, puede utilizar los Kubernetes como un programa shell para unir recursos informáticos de diferentes proveedores para cualquier servicio.

Los kubernetes pueden ser usados como un shell de programa

Documentación y comunidad de Kubernetes

Kubernetes es un marco relativamente nuevo y de rápido desarrollo. Aunque es emocionante ver cómo crece, sus constantes cambios hacen que sea más difícil de aprender.

La documentación oficial se genera automáticamente a partir del código fuente, y la documentación de la herramienta es básicamente un conjunto de comandos soportados. La documentación no oficial, a su vez, es a menudo demasiado abstracta o dedicada a un tema técnico en particular.

Cada recurso de Kubernetes debe tener una versión especificada en su definición:

                apiVersión: v1

Tengan en cuenta que esta no es una versión de Kubernetes sino una versión de la definición de recursos. En el momento de escribir este artículo, la última versión de Kubernetes es la 1.14, pero contiene muchos componentes sin terminar con las versiones v1beta1 o incluso v1alpha1. Como resultado, la instalación de ciertos componentes y la garantía de su compatibilidad con las diferentes versiones de Kubernetes puede ser un problema. Afortunadamente, los miembros de la comunidad de Kubernetes han desarrollado soluciones provisionales para solucionar algunos de estos problemas.

Lee también:

3 pasos para desplegar su sitio web en la nube usando AWS

Esto hace que Kubernetes sea una buena opción para las soluciones multi-nube. Repasemos sus principios y componentes clave.

Trabajando con Kubernetes

Hay cuatro etapas principales de trabajo con los Kubernetes:

1. Creación de un cluster de Kubernetes
2. Declarar una infraestructura
3. Aplicación de la infraestructura
4. Administración del cúmulo

Un cluster es un conjunto de nodos que alberga su entorno. Hay dos tipos de nodos: el Maestro y el trabajadores . El nodo Master ejecuta toda la funcionalidad de administración del clúster. Los nodos trabajadores ejecutan contenedores de trabajo, que incluyen partes de su servicio web. Si tiene al menos un nodo trabajador, el entorno se puede llamar un clúster. Un nuevo nodo del clúster se configura con kubeadm. Esta herramienta convierte una máquina en un nodo maestro o de trabajo.

Puedes crear un nodo con los roles de maestro y trabajador simultáneamente. Esto puede lograrse asignando un nodo principal con derechos para ejecutar contenedores de trabajo. Una infraestructura tan pequeña es útil para el desarrollo y las pruebas. Pero nunca se despliega en producción.

Una vaina es un conjunto de contenedores que funcionan en el mismo nodo. Una vaina consiste en uno o varios contenedores que están estrechamente acoplados.

Una declaración de infraestructura se escribe en uno o varios archivos YAML. Describe cómo debe ser su clúster para funcionar correctamente:

• Número de contenedores
• Roles de ejecución de contenedores
• Mapas de configuración de contenedores
• Credenciales para acceder a bases de datos y archivos
• Y más

Echemos un vistazo a la descripción del entorno de Kubernetes-dashboard como ejemplo de un contenedor de apoyo para la gestión de un clúster con una interfaz web fácil de usar que muestra las estadísticas del clúster. La descripción declara:

• Secreto – una ubicación de datos sensibles del grupo
• ServiceAccount – una cuenta para ejecutar un servicio con un tablero de mandos
• Rol – una lista de acciones que el tablero puede realizar
• Despliegue – una entidad que controla el estado y la disponibilidad de los Pod
• Servicio – un punto de entrada a un contenedor

La aplicación de la infraestructura a un clúster es tarea de un administrador. Normalmente se ejecuta con kubectl. Esta utilidad se instala en el nodo maestro junto con otros componentes de Kubernetes. Es la fachada de un servidor REST API que se ejecuta en uno de los contenedores del nodo Master.

Generalmente, instalar un entorno bien configurado es una tarea sencilla. Puedes hacerlo con el siguiente comando:

                kubectl create -f infrastructure.yaml

Un archivo de descripción del entorno puede almacenarse fuera de la red. A continuación, te explicamos cómo puedes instalar un tablero de mandos para tu clúster:

                kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml

El Kubeadm y el kubectl también se utilizan para la administración de grupos. Kubeadm puede ser usado para cambiar, añadir y eliminar nodos. Kubectl se requiere para la administración del contenido de los nodos: cambiar, agregar y eliminar contenedores (o Pods) y sus componentes lógicos. Es importante recordar que kubectl separa el administrador del hardware. Con kubectl, un administrador trabaja con el entorno del contenedor, no con el hardware en el que está desplegado.

Puede encontrar una amplia introducción al marco de Kubernetes con casos de uso en la documentación oficial del proyecto.

Componentes clave de Kubernetes

Como hemos mencionado, cada grupo de Kubernetes contiene nodos maestros y trabajadores. Ambos tienen sus propios paquetes de componentes. Kubeadm ayuda a configurar un conjunto específico de componentes para un nodo objeto. Un agente demonio, kubelet, controla todos los componentes de cada nodo y registra su trabajo.

Para formar un clúster, necesita instalar los componentes de Kubernetes en el nodo Maestro usando kubeadm. Esta herramienta:

• crea claves y certificados RSA para el cluster
• descarga todos los contenedores necesarios de los depósitos
• configura kubelet para monitorear los contenedores del nodo maestro y reiniciarlos si es necesario.

Los principales componentes del programa del nodo maestro son el servidor de la API y la base de datos etcd . Ambos se lanzan en contenedores, utilizan WebSockets para comunicarse entre sí y son partes lógicas de un cluster de Kubernetes.

El servidor API y la base de datos etcd son Pods, pero no se muestran en la lista de Pods. Están listados en el espacio de nombres del sistema kube por defecto. Para verlos, ejecuta este comando:

                kubectl get pods -n kube-system

Estos son Pods estáticos con archivos de definición YAML almacenados en el demonio kubelet. Si un contenedor se bloquea, kubelet lo reinicia inmediatamente.

Cuando el nodo maestro está configurado, se genera un token de seguridad. Necesitará este token para autentificar una máquina (nodo) cuando la integre en un grupo de nodos trabajadores. Cuando configuras un nodo trabajador con kubeadm, también ejecuta kubelet. En este caso, kubelet controla la condición de los nodos trabajadores en lugar de controlar la condición de los Pods estáticos.

Puedes administrar el clúster utilizando la API del servidor REST. Puedes enviar comandos al servidor de la API utilizando kubectl. Kubectl transforma su comando en una cadena de petición y una petición POST en el formato de un documento JSON con el recurso solicitado. Luego envía la solicitud al servidor de la API y emite el resultado.

El flujo de trabajo del servidor de la API y otros componentes del clúster es más complejo. En la siguiente sección, explicamos algunos aspectos básicos de estos procesos complejos.

Servidor API y kubeconfig

El servidor de la API es el corazón de un clúster. Su dirección IP se especifica en el archivo de configuración del nodo maestro (/etc/kubernetes/admin.conf). Normalmente, este documento se copia a ~/.kube/config y se denomina kubeconfig. Este archivo también contiene la autoridad de certificación y una lista de usuarios con acceso a esta configuración. Por defecto, se crea un perfil de administrador de clúster y se llama cluster-admin . Kubeadm también crea un usuario kubernetes-admin con los siguientes parámetros:

                ...usuarios:- nombre: kubernetes-adminuser:cliente-certificado-datos:...

Usando el archivo kubeconfig, una aplicación puede ejecutar comandos como un administrador. Por eso las aplicaciones administrativas (por ejemplo, kubectl), que son necesarias para que el clúster funcione pero que se almacenan fuera de él, utilizan los datos del archivo kubeconfig para autenticarse en el servidor de la API.

Si una aplicación que gestiona un clúster está almacenada en su interior, el acceso a los recursos del clúster debe configurarse con funciones específicas. Utilizando un rol de administrador, un Pod puede lanzarse con variables de entorno predefinidas y archivos de configuración montados. Estos archivos permiten a un Pod ejecutar comandos para crear/eliminar un determinado tipo de recurso, solicitar un certificado, etc.

El paquete clientcmd proporciona acceso a los datos de autenticación en el servidor de la API. Usando este paquete, puede crear una estructura de configuración de cliente. Luego, usando esta estructura y el resto del paquete, puede crear un objeto cliente REST para el servidor de la API. Una vez creado el objeto cliente, puedes usarlo para gestionar el clúster desde tu aplicación.

La siguiente figura ilustra cómo una aplicación carga la configuración.

Adición de aplicaciones de terceros

La posibilidad de incluir aplicaciones de terceros utilizando enlaces a GitHub o a cualquier otro repositorio es una característica única de Go.

Por ejemplo, para crear un objeto Pod en el código de su aplicación, puede incluir su descripción desde el repositorio k8s.io:

                importar "k8s.io/api/core/v1 "Entonces, puedes añadir este trozo de código:pod := v1.Pod {/// Tu definición aquí}

Puede añadir cualquier paquete de repositorio público (o privado, si tiene acceso a él) a su entorno de Kubernetes. Como resultado, puede construir su aplicación a partir de los paquetes de diferentes proyectos externos. Para gestionar las dependencias externas (descargando los paquetes ), puede utilizar la utilidad Dep.

base de datos etcd

Etcd es una base de datos de velocidad optimizada que almacena información en pares clave-valor. El nodo Maestro utiliza una instancia de esta base de datos para almacenar todo tipo de datos, desde configuraciones de Pod hasta registros. Etcd tiene una interfaz de red protegida. La base de datos tiene una arquitectura relativamente simple que asegura un rendimiento rápido y fiable. Etcd es uno de los componentes más importantes de un cluster de Kubernetes.

Nuestra experiencia con los Kubernetes

Mientras trabajaba en nuestro proyecto Kubernetes, nuestro equipo de desarrollo de Apriorit creó un controlador para supervisar los recursos personalizados. En Kubernetes, dichos recursos se llaman políticas . Los controladores de políticas se llaman para asegurar que un clúster funciona correctamente. Veamos qué funciones desempeñan.

Controladores de Kubernetes

Los controladores se encargan de mantener el estado deseado del cúmulo. Supervisan todos los cambios en los recursos del cúmulo de su propio tipo y comparan constantemente el estado observado con el deseado. Los controladores son implementaciones de recursos.

Los controladores estándar no cumplen necesariamente con las entidades básicas. Algunos de ellos pueden gestionar sólo una parte de una entidad descrita en la configuración de grupos. Por ejemplo, el campo ReplicaSet en la Despliegue dicta cuántos Pods con ciertos recursos debe contener un cluster, y los campos específicos de definición de contenedor especifican qué discos deben ser montados en un contenedor. Un Controlador de Replicación dedicado supervisa el número de Pods en un cluster. Un Controlador de Volumen se encarga de asignar los volúmenes de los contenedores.

La versión 1.9 y superior de Kubernetes permite a un administrador crear sus propios recursos y controladores. Puede utilizar un nuevo recurso si:

• está registrado en un grupo
• se ejecuta un controlador para monitorear el estado del nuevo recurso.

Un controlador puede utilizar cualquier paquete k8s y obtener cualquier derecho. Esta flexibilidad le permite crear un controlador para cualquier propósito. Por ejemplo, hay un controlador que informa de los cambios en el Pod a Slack.

Políticas de Kubernetes

Una política determina la forma final del recurso creado en un grupo. En el momento de escribir este artículo, la versión actual de Kubernetes sólo admite la implementación de políticas de mutación. De acuerdo con esta política, un administrador o una aplicación crea un recurso, y el controlador lo ajusta a la política. El siguiente paso será la implementación de una política de validación para evitar la creación de recursos que violen las políticas de validación.

Crear un recurso en Kubernetes lleva tiempo. Hay varias etapas escribiendo un comando a kubectl y escribiendo un nuevo recurso a etcd. El proceso incluye la etapa de mutación y validación. En esta etapa, la definición de un recurso se transmite a un webhook registrado para su procesamiento y/o verificación. Un webhook utiliza peticiones POST en un documento JSON. Este archivo debe contener una descripción completa del recurso, incluyendo los metadatos del objeto y de la solicitud.

El proceso de verificación de recursos con ganchos se llama Control de Admisión Dinámico. El controlador de admisión que creamos para nuestro proyecto utiliza este proceso para identificar y cambiar los nuevos recursos en la etapa en que se crea.

Conclusión

Construir un proyecto con Kubernetes hace que el proceso de desarrollo sea más rápido, más escalable y más flexible. Una vez configurado el sistema, se gestiona automáticamente y se cura a sí mismo si alguna parte se cae.

La configuración de una red requiere un conocimiento básico de Docker y un profundo conocimiento de la infraestructura de Kubernetes. Kubernetes utiliza un conjunto de CLIs y APIs para ejecutar comandos. En este artículo, hemos tratado la creación de un clúster, la escritura de descripciones de la infraestructura y el entorno, y el trabajo con el servidor de la API y la base de datos etcd.

¿Tiene en mente un ambicioso proyecto de Kubernetes? No dude en contactar con los expertos en desarrollo de software en la nube de Apriorit para empezar a trabajar en él!

La entrada Investigando a los Kubernetes desde dentro se publicó primero en Descargar Driver.

En este artículo, discutimos los pros y los contras de usar DKMS y explicamos en qué casos no es la mejor solución para la instalación de controladores de Linux. Este artículo será útil para los desarrolladores de controladores que están debatiendo si usar DKMS para distribuir su software.

¿Qué es el DKMS?

¿Qué es el DKMS? Dynamic Kernel Module Support (DKMS) es un marco de trabajo desarrollado por Dell para distribuir automáticamente las actualizaciones de los módulos del núcleo a sus clientes. Simplifica tanto el desarrollo de controladores como la administración del sistema, aumentando la estabilidad general del sistema.

Este marco de trabajo permite a los desarrolladores proporcionar a los usuarios controladores que no están incluidos en el lanzamiento oficial del kernel. DKMS también aumenta significativamente la calidad del código fuente de los módulos, ya que los desarrolladores pueden probar sus drivers simultáneamente en numerosas máquinas.

El DKMS también tiene ventajas para los administradores de sistemas, ya que instala automáticamente las actualizaciones de los controladores de los dispositivos en la versión existente del kernel sin introducir ningún cambio en el mismo. Así que los administradores de sistemas ya no tienen que esperar a que se publique una nueva versión del kernel.

Tenga en cuenta que el DKMS no es la única solución para instalar módulos del núcleo. También hay alternativas de DKMS como:

• AKMOD, una solución de Fedora que se basa en herramientas como la Colección de Compiladores GNU y auto-make
• asistente de módulos (a menudo abreviado como m-a), una herramienta para compilar manualmente los módulos del núcleo

DKMS y AKMOD son similares, ya que ambos reconstruyen módulos para la instalación de un nuevo kernel, mientras que m-a requiere ejecución manual y puede construir módulos sólo para un kernel actualmente en funcionamiento. Pero esto puede ser un inconveniente, por ejemplo cuando se instala un controlador de gráficos.

Comprendiendo el ciclo de vida del DKMS

Veamos más de cerca cómo funciona el DKMS. El DKMS duplica el árbol de módulos fuera del árbol del núcleo. Este árbol de módulos incluye el código fuente del módulo y sus binarios compilados. Cuando un nuevo kernel de Linux o una nueva versión del controlador es liberada, DKMS usa un enfoque estandarizado para recolectar y construir su código fuente.

Específicamente, DKMS es una herramienta universal que puede construir código de controlador en archivos binarios de módulos compilados cargables, y luego instalar y desinstalar esos módulos en cualquier núcleo de Linux.

Además, el marco proporciona características especiales para la gestión y el mantenimiento de los módulos en múltiples sistemas, mostrando qué versión del módulo está instalada en qué versión del núcleo.

Cuando se considera si se usa el DKMS, es necesario entender el ciclo de vida de su módulo. Aquí está el flujo de DKMS y sus principales comandos para ejecutar y administrar un módulo del núcleo.

Como puedes ver, hay un conjunto especial de comandos para realizar las principales acciones con los controladores de Linux.

Puede ver el estado actual de los módulos ejecutándose:

                estado del dkms

Este comando muestra el nombre, la versión y el estado de cada módulo del núcleo. Usando este comando, puede entender rápidamente si un controlador de dispositivo ha sido actualizado.

Para añadir un módulo y su versión al árbol de DKMS existente, ejecute lo siguiente:

                dkms añadir [-m NOMBRE_MÓDULO] [-v VERSIÓN] [/camino/al/módulo-src/]

Si se omiten las opciones -m o -v, DKMS buscará /usr/src/módulo-módulo-versión en las fuentes así como en el archivo dkms.conf , o copiará el archivo pasado /path/to/module-src/ a /usr/src/módulo-módulo-versión .

Después de que el módulo se coloca en el árbol, puedes construir el módulo usando el comando de construcción:

                dkms build -m MÓDULO -v VERSIÓN -k $(uname -r)

Este comando permite a los desarrolladores y administradores del sistema compilar un módulo previamente agregado para el kernel actual. También permite a los desarrolladores comprobar si hay errores en un controlador durante el desarrollo. Después de esto, su módulo será compilado pero no instalado.

Si quieres copiar los módulos compilados al árbol del núcleo, usa el comando de instalación:

                dkms instalar -m MÓDULO -v VERSIÓN -k $(uname -r)

Si hay dos módulos con el mismo nombre, el módulo previamente instalado será respaldado en el directorio /var/dkms/MODULE/original-module . Se guardará como un módulo original para que pueda ser restaurado si se desinstala el módulo más reciente.

Hay dos comandos para borrar un módulo del árbol DKMS: desinstalar y eliminar .

El comando de desinstalación eliminará el módulo instalado y, si es posible, lo reemplazará con una copia de seguridad:

                dkms desinstalar -m MÓDULO -v VERSIÓN -k $(uname -r)

Para quitar el módulo del árbol del kernel para la versión y arquitectura del kernel pasado -k, ejecutar:

                dkms remover -m MÓDULO -v VERSIÓN -k $(uname -r)

Si quieres quitar un módulo de todos los kernels instalados, añade -all:

                dkms quitar -m MÓDULO -v VERSIÓN -todos

La diferencia entre los comandos remove y uninstall es que uninstall sólo borra un módulo del árbol del núcleo, dejando el módulo en el estado built , mientras que remove también comprueba si existen otras instancias del módulo para otros núcleos y, si no hay ninguna, limpia el árbol DKMS. Después de que el árbol se limpia, el usuario de Linux debe añadir el módulo de nuevo para usarlo con el SGDK.

Otros comandos dignos de mención son el match y el auto-instalador. La orden match es útil cuando se necesita usar un módulo para varios núcleos. En este caso, match utiliza la configuración del módulo instalado en un núcleo y la aplica a otro.

El autoinstalador comprueba si el archivo de configuración contiene el parámetro AUTOINSTALL y, si es así, DKMS reconstruirá e instalará el módulo para este kernel al arrancar en un nuevo kernel.

Para usar el DKMS, debe proporcionar un archivo dkms.conf como este:

                PACKAGE_NAME="MY_MODULE "PACKAGE_VERSION="1.0 "MAKE="make --uname_r=$kernelver "CLEAN="make clean "BUILT_MODULE_NAME="$PACKAGE_NAME "DEST_MODULE_LOCATION="/kernel/drivers/misc "REMAKE_INITRD="yes "AUTOINSTALL="yes

El uso de DKMS depende de la forma en que se proporciona un controlador de Linux a sus usuarios. A continuación, explicaremos por qué.

Principales formas de distribución de controladores de Linux

Los desarrolladores de controladores de Linux pueden distribuir su software de las siguientes formas:

• Como un módulo de kernel precompilado En este caso, los usuarios de Linux no tienen que preocuparse por los requisitos para construir el controlador. Los módulos precompilados se lanzan con el núcleo de Linux y requieren soporte para diferentes sabores de Linux y diferentes opciones de configuración. Sin embargo, puede pasar algún tiempo entre el lanzamiento de un nuevo núcleo y el lanzamiento de la versión necesaria de un módulo.
• Como código fuente de módulo completo Con el código fuente de módulo completo, un usuario puede construir un controlador por su cuenta. Pero este método se basa en un compilador instalado, herramientas de construcción adicionales, y los archivos de cabecera del kernel apropiados.
• Como un módulo del núcleo con partes binarias de código cerrado y código fuente para una capa de interfaz del núcleo
  Este tipo de módulo del núcleo se utiliza a menudo como solución alternativa para la infracción de licencias o distribuciones como Free/Net BSD (Berkeley Software Distribution) y algunas distribuciones de Linux en las que se acepta un firmware binario combinado junto con partes de interfaz de código abierto.

DKMS espera que los módulos del núcleo se suministren con código de código abierto, pero a veces los controladores vienen con partes binarias de código cerrado (como los controladores de vídeo de NVIDIA). En este caso, la parte principal del controlador incluye un objeto vinculado binario de código cerrado, también llamado blob binario, y el código fuente de la capa de interfaz del núcleo. La interfaz del kernel, compilada como un módulo general, debe estar enlazada con las partes de código cerrado y debe ser compilada específicamente para cada kernel.

La construcción de módulos a partir del código fuente suele requerir un paquete de cabeceras de núcleo , un compilador (como la colección de compiladores GNU) y un enlazador (normalmente /usr/bin/ld del paquete binutils ). Estos componentes son necesarios en caso de que se hagan cambios en la parte de código cerrado o sólo en el código fuente de un módulo. En caso de que se haga cualquier cambio en la interfaz binaria de la aplicación del núcleo (ABI), como cambios en las firmas de las funciones, en el número de parámetros o en sus tipos, se requiere la interfaz correcta del núcleo para soportar el código de la interfaz vinculado con la parte blob.

Beneficios y limitaciones del DKMS

Aunque DKMS es sin duda una herramienta útil para la distribución de controladores del núcleo de Linux, tiene limitaciones que pueden hacer que los desarrolladores de controladores se alejen de ella. Así que veamos más de cerca los pros y los contras de DKMS.

Ventajas de utilizar el DKMS:

• Es un marco conveniente para construir, instalar y eliminar varios módulos del núcleo de Linux.
• Asegura que un controlador de Linux será actualizado e instalado correctamente en el lugar correcto.
• Permite gestionar los módulos instalados y comprobar su estado.
• Le permite añadir un paso personalizado, como la adición de una firma digital de conductor del cliente a través de POST_BUILD y POST_INSTALL. Esto garantiza la seguridad de la instalación del módulo.
• Soporta la instalación de los paquetes deb y rpm fuera de la caja.
• Está disponible para muchas distribuciones de Linux.
• Los usuarios de Linux pueden actualizar sus controladores inmediatamente después de ser reparados. Por lo tanto, no necesitan esperar a que el proveedor les dé una nueva versión del núcleo.
• Con este marco de trabajo, es difícil olvidarse de instalar el módulo para un núcleo recién instalado porque todos los procesos están automatizados.

Contras de usar DKMS:

• Se requiere una manipulación adicional para los módulos residentes.
• El código fuente de los módulos tipo NVIDIA con partes blob no son convenientes para entregar con DKMS, ya que requieren código fuente para la interfaz del kernel compilado para cada versión del kernel.
• Existe el riesgo de que un módulo no sea construido por DKMS si sus nombres de función han cambiado o si hay cambios en la forma en que el núcleo interactúa con sus componentes.
• DKMS no garantiza una instalación adecuada en caso de cambios en la interfaz binaria de la aplicación del kernel, ya que la interfaz del kernel y el soporte de la fuente del módulo siguen siendo necesarios.

Distribución de conductores sin DKMS

En uno de nuestros proyectos de desarrollo de controladores para Linux, se nos encargó crear un controlador que estuviera protegido contra la descarga de módulos y los intentos de evitar su carga. Nuestro cliente quería estar seguro de la persistencia del módulo y la secuencia de arranque.

Para lograr este objetivo, decidimos distribuir el controlador con módulos precompilados. Como nuestro driver tenía partes binarias de código cerrado, el uso de DKMS no habría garantizado una instalación adecuada.

Sin embargo, el primer problema que enfrentamos fue una amplia gama de versiones del núcleo de Linux y distribuciones soportadas. Así que tuvimos que elegir a cuál añadir nuestro controlador.

Además, nos encontramos con algunos problemas al implementar nuestro propio sistema de construcción e instalación de módulos:

• Los usuarios de Linux pueden utilizar diferentes administradores de paquetes, y los nombres de las herramientas de construcción común y los paquetes de encabezamiento del núcleo pueden variar en las distintas distribuciones. Así que existe el riesgo de que nuestro controlador no se construya correctamente.
• Algunas versiones del núcleo no tienen paquetes disponibles para las cabeceras de los núcleos (por ejemplo, en Fedora), ya que fueron sacados del acceso público.
• Algunos núcleos de Linux no soportan el algoritmo de firma digital PKCS7, así que tuvimos que usar el mecanismo de firma por defecto en su lugar.
• Hay un enfoque ambiguo y dependiente de la distribución para obtener una lista de kernels instalados, que confirma la presencia del paquete de cabecera del kernel.
• Tuvimos problemas con la construcción de módulos en algunas distribuciones/configuraciones específicas. Estos problemas también pueden aparecer en el caso de una construcción automatizada con DKMS u otras herramientas similares.

A continuación, proporcionamos algunos consejos sobre cómo los desarrolladores pueden verificar la instalación de su módulo de Linux en el núcleo sin usar DKMS.

Al implementar un instalador personalizado, el desarrollador de un controlador tiene que elegir cuándo y cómo debe comenzar su módulo, cómo detectar los módulos ya instalados y cómo verificar si los módulos están firmados correctamente.

Estas decisiones deben tomarse incluso si decides usar el modprobe para añadir o quitar tu módulo del kernel de Linux.

Si está considerando usar insmod para insertar su módulo en el kernel, debe tener cuidado de protegerse contra las listas negras. Sin embargo, en este caso, necesitarás implementar el módulo de sistema init desde cero.

En los casos de carga ansiosa o de un módulo residente, los desarrolladores de controladores pueden elegir un guión de nivel de ejecución en lugar de los guiones de inicio automático definidos por el usuario, que suelen utilizarse para el software. Con toda la variedad de sistemas de arranque inicial de Linux (scripts INIT Sys-V, upstart, systemd y otros), la mejor opción es implementar un script personalizado init.d y confiar en las utilidades instaladas (como update-rc.d o chkconfing ) para manejar los enlaces por nivel de ejecución. Runlevel es el concepto para los sistemas operativos con inicialización de estilo Sys-V que describe qué procesos, demonios y controladores deben cargarse o iniciarse para cada modo.

Sin embargo, no hay ninguna norma que defina la ubicación del enlace, la estructura o incluso la lista completa de tales enlaces. Además, las utilidades mencionadas anteriormente tienen diferentes versiones de paquetes en las distribuciones con diferentes funcionalidades. Por ejemplo, una versión anterior de update-rc.d en la Casa de la Moneda 17 permite especificar la prioridad de arranque, pero la misma utilidad en la Casa de la Moneda 18 no tiene esta opción, basándose únicamente en las dependencias de carga de los módulos.

Conclusión

Gracias al continuo desarrollo de la comunidad Linux, aparecen grandes herramientas como DKMS. Con DKMS, los usuarios de Linux pueden construir y gestionar automáticamente los módulos del núcleo sin necesidad de esperar a la entrega de un nuevo paquete de controladores. Además, los desarrolladores de controladores pueden verificar la instalación de sus módulos en la etapa de desarrollo. También hay una amplia gama de herramientas útiles para los desarrolladores de controladores de Linux, por lo que seguiremos compartiendo nuestra experiencia en este tema. El desarrollo de controladores Linux requiere un enfoque integral, y nuestro equipo de desarrolladores de controladores está siempre a su disposición.

Servicios conexos

Desarrollo del núcleo y del controlador

La entrada Ventajas y desventajas de usar el DKMS se publicó primero en Descargar Driver.

Este artículo es la continuación de un conjunto de artículos sobre la ocultación y detección de archivos y procesos en el sistema operativo. Supongo que ya habrán leído los artículos Driver to Hide Processes and Files y Simple SST Unhooker.

El artículo Simple SST Unhooker representa el método para resolver el problema de la sustitución de la dirección de la función en la tabla SST. En este artículo, describiré los métodos de programa de enganche de funciones, lo que hará que la metodología descrita en el artículo Simple SST Unhooker no funcione.

Introducción a la base de empalme

En el artículo Driver to Hide Processes and Files , se escribe mucho sobre por qué necesitamos la interceptación de las funciones del sistema. En este artículo, quiero centrar su atención en la comparación de las tecnologías de interceptación, sus ventajas y desventajas.

Podemos dividir los métodos de interceptación en los siguientes grupos:

• Sustitución de la dirección de la función real (modificación de las tablas IAT, modificación de las tablas SSDT/IDT);
• Cambio directo de la función (empalme, interceptación en el modo de núcleo con la modificación del cuerpo de la función);
• Sustitución directa de todo el componente de la aplicación/sistema (por ejemplo, sustitución de la biblioteca por una función de destino).

También podemos dividirlos por el modo de ejecución de la siguiente manera:

• Usuario ( anillo3 ) métodos : modificación de tablas IAT, empalme. Su peculiaridad es que no se puede cambiar nada en el comportamiento del kernel del sistema operativo y sus extensiones;
• Modo kernel : modificación de las tablas SSDT/IDT, interceptación en el modo kernel con la modificación del cuerpo de la función. Con la ayuda de esto, se puede modificar la estructura de datos y el código de cualquier parte del sistema operativo y de las aplicaciones.

Empalme

El empalme es un método de interceptación de las funciones de la API mediante el cambio del código de la función objetivo. Normalmente, se cambian los primeros 5 bytes de la función. En lugar de ellos, se inserta un salto a la función especificada por el desarrollador. Para que la operación se realice correctamente, la aplicación que intercepta la función debe permitir la ejecución del código que se cambió durante el empalme. Para ello, la aplicación guarda la parte de memoria que se está sustituyendo y, una vez que la función de interceptación termina su trabajo, la aplicación restaura la parte de función guardada y permite la ejecución completa de la función real.

Especificaciones de la tecnología

Esta tecnología depende de la plataforma y por eso necesita un control y una comprobación minuciosos del sistema para la correspondencia de las versiones. También necesita el control de la función para la correspondencia con el objetivo. Las funciones del sistema pueden cambiar cuando aparecen nuevos parches y actualizaciones de Windows (especialmente, el Service Pack para Windows) y también como resultado de las modificaciones de otras aplicaciones. Los errores al trabajar con esta tecnología pueden causar BSOD. Al mismo tiempo, esta tecnología ayuda a realizar la interceptación global de las funciones de la API e influye de tal manera en todos los procesos del sistema. Al enganchar el SSDT, llegamos a la función redefinida sólo si se llama a través de la tabla de llamadas del sistema. Cuando se utiliza el empalme, la función será llamada en cada llamada a la función original.

Alcance del empalme y métodos de detección

El empalme se utiliza en el software que debe realizar lo siguiente:

• Funciones del sistema de vigilancia;
• Mecanismo de ganchos en Windows;
• Diferentes programas maliciosos. Esta es la principal tecnología de ocultación para los rootkits del nivel de usuario.

Estructura del proyecto

Para aclarar las ventajas y desventajas de esta tecnología, decidí no escribir el código desde el principio antes de la sustitución de la dirección en SST. Pero decidí hacer algunos cambios necesarios en el código del controlador fuente del artículo Driver to Hide Processes and Files para que funcionara evitando el SSTUnhooker y se basara en el método de empalme.

Los cambios se realizan sólo en el proyecto HideDriver y sólo en el PrcessHook . Esto permitirá comparar dos enfoques diferentes en un proyecto.

Lado técnico

Entonces, ¿cómo funciona el empalme desde el punto de vista del código? Para responder a esta pregunta, necesitamos refrescar nuestros conocimientos sobre los acuerdos de llamadas de subrutinas y sobre la pila.

Acuerdo de llamada y pila

El acuerdo de llamada define las siguientes peculiaridades del proceso de utilización de subrutinas:

• Ubicación de los parámetros de entrada de la subrutina y los valores devueltos por ella. Las variantes más extendidas son las siguientes:
  • En registros;
  • En la pila;
  • En la memoria asignada dinámicamente.
• Orden de transferencia de los parámetros. Cuando se utiliza la pila, define el orden en que los parámetros deben colocarse para apilarlos; cuando se utilizan registros, define el orden de comparación de los parámetros y los registros. Las variantes son las siguientes:
  • Los parámetros de orden directo se colocan en el mismo orden en que se enumeran en la descripción de la subrutina.
  • El orden inverso… los parámetros se pasan del final al principio. Simplifica la implementación de subrutinas con un número indefinido de parámetros de tipos aleatorios.
• Lo que devuelve el puntero de la pila a la posición inicial:
  • Subrutina llamada – esto corta el número de comandos que se requieren para la llamada de la subrutina ya que los comandos de la recuperación del puntero de la pila se escriben una sola vez al final de la subrutina;
  • Programa de llamada – en este caso, la llamada se hace más complicada pero el uso de las subrutinas con el número y tipo de parámetros variables se hace más fácil.
• ¿Qué comando usar para llamar la subrutina y qué comando usar para volver al programa principal? Por ejemplo, puede llamar a la subrutina mediante llamada cercana, llamada lejana y pushf/call lejana (para el retorno, use retn, retf, iret, correspondientemente) en el modo estándar x86.
• El contenido de los registros del procesador que la subrutina debe restaurar antes de la devolución.

Los acuerdos de llamada dependen de la arquitectura de la máquina objetivo y del compilador.

En nuestro caso, realizamos el empalme del API. Como se sabe, es del tipo __stdcall. Usando este tipo, los argumentos se pasan a través de la pila en orden de derecha a izquierda. La subrutina llamada realiza la limpieza de la pila.

La pila se parece a lo siguiente cuando estamos al principio de la función si tiene el tipo de llamada stdcall:

La pila se cambia por la instrucción de llamada del ensamblador. Transfiere el control a la subrutina y escribe la dirección de retorno a la pila. La instrucción ret devuelve el control al lado de la llamada y toma la dirección de retorno de la parte superior de la pila.

Revisión del código

Ahora, podemos preparar el modelo que funcionará de la siguiente manera.

Puede ver la aplicación de este esquema en el ejemplo de nuestro conductor.

Primero, tenemos que declarar a los propios manipuladores. Para ello, necesitamos usar las siguientes definiciones:

                #define DEFINE_POST_HANDLER(Name, ImplName,ParamsData) N - vacío estático __stdcall ImplName(unsigned long * pRetValue, ParamsData * pData, Nunknown long dwOldEax); vacío estático __declspec(naked) void __stdcall Name()  ~ -asm pushad  ~ -asm push eax  ~ -asm mov eax, [esp+0x28]  ~ -asm push eax  ~ -asm lea eax, [esp+0x28]  ~ -asm push eax  ~ -asm call ImplName  ~ -asm popad  ~ -asm ret 4 } //------------------------------------------------------------------------------------------------- #define DEFINE_FORE_HANDLER(Name, ImplName) N - vacío estático __stdcall ImplName(sin firmar largo * pFirstData); vacío estático __declspec(naked) void __stdcall Name()  ~ -asm pushad  ~ -asm lea eax, [esp+0x28]  ~ -asm push eax  ~ -asm call ImplName  ~ -asm popad  ~ -asm ret }

Como podemos ver, aquí se declaran los comprobantes de la llamada de los manejadores y, al mismo tiempo, todos los registros se guardan en el estado por defecto.

Ahora, veamos la función que toma el control al principio de la ejecución de la función original:

                vacío estático __stdcall NtQuerySystemInfo_HookHandlerImpl(sin signo largo * pContexto){sin signo largo * pRetPoint = GET_RET_POINT_PTR(pContexto);struct NtQuerySystemInfo_HookHandler_Data * pParamsData = 0;void * pStub = 0;if (AllocatePostParams(&g_kernelNonPagedAllocator, sizeof(struct NtQuerySystemInfo_HookHandler_Data),NtQuerySystemInfo_HookHandler_PostHandler,(void**)&pParamsData, &pParamsData- >SystemInformationLength = GET_PARAM(pContext, 2);pParamsData- ]ReturnLength = GET_PARAM_PTR(pContext, 3);// establecer nuevo punto de retorno*pRetPoint = (largo sin signo)pStub;}

Esta función asigna memoria para los parámetros y crea un talón para la llamada POST_HANDLER. A continuación, guardamos la dirección de retorno original de la pila, establecemos la nueva dirección de retorno apuntando a nuestro manejador post-función y saltamos de nuevo a la función original. Después de su ejecución, llama a la instrucción ret. La última toma la dirección de la pila y hay un valor guardado de antemano para nuestro POST_HANDLER. Luego, llegamos a él y tenemos la pila con los parámetros originales y las direcciones de los parámetros de salida.

                vacío estático __stdcall NtQuerySystemInfo_HookHandler_PostHandlerImpl(unsigned long * pRetValue, struct NtQuerySystemInfo_HookHandler_Data * pData, unsigned long dwOldEax){*pRetValue = pData-{[dwRealIP]};if ( (pData-{[SystemInformationClass])= SystemProcessesAndThreadsInformation) || (dwOldEax != 0) ){MemoriaLibre(&g_núcleoNoAsignadorDePáginas,pDatos);return;}OcultarAlgoritmo::NtQuerySysInfoParams params = {pData-{ClaseDeInformaciónDelSistema,pData-{{{[#]}]}SuprimirAlgoritmo::HideProcess(params,gProcessChecker);FreeMemory(&g_kernelNonPagedAllocator, pData);}

Como podemos ver, la restauración de la dirección de retorno y la limpieza de la memoria asignada por FORE_HANDLER son las tareas de esta función. Aquí se realiza toda la lógica sobre el corte de los procesos requeridos de la lista de procesos. Me gustaría llamar su atención sobre el hecho de que el corte se realiza por el mismo algoritmo que en el artículo original de procesos ocultos.

La ejecución de la función termina en ella.

Método de empalme

En esta parte del artículo, estudiaremos el método de empalme de la función original.

Primero, necesitamos asignar memoria y escribir el código en ella, que será llamado por nuestros manejadores. Se realiza de la siguiente manera:

                int __stdcall InitializeHookEx(MemoryRWManager * pRwManager, unsigned char * pHook, unsigned char * pHandler){int status = 0;char buffer[CALL_SIZE];// Escribir la instrucción CALL en el buffer[0] = 0xE8; // 1 byte para CALL opcode*(size_t*)(buffer + 1) = (unsigned char *)pHandler - (pHook + CALL_SIZE); // 4 bytes para la dirección relativa// Copiar la instrucción CALL desde el buffer a la memorystatus del gancho = WriteMemoryWithWriter(pRwManager->pWriter, (char*)pHook, buffer, CALL_SIZE, 0);if (status)return STATUS_UNSUCCESSFUL;return STATUS_SUCCESS;}

Por supuesto, al haber asignado mem

La entrada Driver para ocultar procesos y archivos se publicó primero en Descargar Driver.

Afortunadamente, hay herramientas que pueden hacer que el desarrollo de aplicaciones sea más fácil y más rápido: las plataformas de desarrollo de bajo código, o LCDP.

En este artículo, describimos algunas de las plataformas de desarrollo de código bajo más populares. Nuestra lista de las diez principales incluye plataformas que pueden ser usadas para construir aplicaciones web, móviles y de escritorio.

¿Qué son las plataformas de desarrollo de código bajo?

Las plataformas de desarrollo de código bajo tienen por objeto simplificar el proceso de construcción de una aplicación. Por esa razón, también se llaman plataformas de desarrollo rápido de aplicaciones.

Las LCDP se utilizan principalmente para construir aplicaciones de procesos simples. Permiten a las empresas automatizar procesos repetitivos, como los relacionados con la contratación, y construir aplicaciones sencillas sin la participación de los desarrolladores.

El desarrollo de aplicaciones tradicionales se basa en la codificación manual y en el cumplimiento de estrictos requisitos de sistema. Los LCDP, a su vez, son entornos de arrastrar y soltar donde se pueden reunir diferentes características y funcionalidades como los Legos: sólo tienes que elegir lo que necesitas y construir tu aplicación a partir de ello.

El principal beneficio de las herramientas de desarrollo de código bajo es que eliminan la necesidad de contratar a un desarrollador profesional.

El desarrollo de código bajo es la mejor opción para los no codificadores y los programadores junior que aún no están cualificados para crear software de alta calidad desde cero. Estas plataformas también son una combinación perfecta para las organizaciones que quieren crear aplicaciones de negocios sin gastar demasiado tiempo y esfuerzo en ello.

A continuación, le ofrecemos las principales plataformas de desarrollo de bajo código que pueden utilizarse para crear todo tipo de aplicaciones para móviles, web y de escritorio. Este artículo le ayudará a encontrar una LCDP que cumpla con sus requisitos.

Al compilar esta lista, intentamos crear una aplicación básica en cada una de las plataformas. Casi todas las plataformas que se enumeran a continuación están basadas en la nube, mientras que la mayoría de los líderes del mercado también tienen un entorno de desarrollo integrado (IDE) para el desarrollo basado en el escritorio. La mayoría de las plataformas también supervisan el rendimiento de las aplicaciones en tiempo real.

Estas plataformas despliegan su código por sí mismas y no lo ponen a disposición de los desarrolladores, por lo que todo el proceso es más como el desarrollo de aplicaciones web sin código. Básicamente, no codificas una aplicación sino que la configuras eligiendo entre un gran conjunto de plantillas y soluciones ya preparadas.

La información general sobre nuestras 10 principales plataformas se encuentra en la tabla siguiente.

Vamos.

1. OutSystems

OutSystems es un LCDP potente y profesional con un gran número de características, librerías de terceros y plantillas, además de su propio IDE con una gran funcionalidad.

Con OutSystems, varios usuarios pueden desarrollar un módulo simultáneamente. OutSystems facilita la gestión de los usuarios y los roles de la aplicación. También facilita el proceso de desarrollo al ocuparse de las partes estándar pero difíciles del desarrollo de un sitio web o una aplicación, permitiendo al equipo de desarrollo centrarse en la solución de problemas del mundo real.

OutSystems genera código en el lenguaje de la pila tecnológica y el servidor que estás usando. También te permite usar las APIs de REST en tus aplicaciones. Incluso puedes escribir tu propia funcionalidad con JavaScript para ciertos elementos.

Además, puedes escribir código JavaScript independiente de los elementos de la interfaz.

En cuanto a las bases de datos, los desarrolladores pueden utilizar bases de datos con soporte oficial o trabajar con cualquier otra base de datos utilizando código estándar, controladores de Conectividad de Bases de Datos Abiertas (ODBC) / Conectividad de Bases de Datos (DBC) o APIs patentadas. Se puede acceder a grandes depósitos de datos a través de las API de REST.

OutSystems también proporciona opciones para la personalización de la interfaz de usuario (UI): Puede crear elementos HTML y cambiar sus estilos con CSS. El backend también puede ser personalizado.

La plataforma OutSystems permite supervisar el rendimiento de las aplicaciones y facilita la identificación de los cuellos de botella en el rendimiento y la adopción de las medidas necesarias para solucionarlos. Además, la plataforma asegura un alto nivel de rendimiento optimizando el código generado automáticamente.

OutSystems controla su producto y ofrece campamentos de entrenamiento y una comunidad online para que todos puedan encontrar la información que necesitan.

OutSystems es una de las herramientas más caras de nuestra lista. La versión Enterprise comienza en 5.400 dólares al mes. Para las pequeñas empresas, hay una versión gratuita con funcionalidad limitada.

2. Appian

Appian, que viene con su propio IDE, es uno de los líderes en el mercado de software de plataforma de desarrollo de código bajo. Es una plataforma de gestión de procesos empresariales (BPM) que se utiliza para crear aplicaciones y desplegarlas como servicios para uso corporativo interno.

A diferencia de otras plataformas similares, a Appian sólo se puede acceder desde ciertos países. En Appian, se pueden vincular aplicaciones heredadas mediante API y crear cuadros de mando e informes. Appian también proporciona un conjunto de herramientas para la prueba de aplicaciones.

Lee también:

5 Metodologías de prueba de seguridad de aplicaciones web más populares

La personalización de la interfaz de usuario está limitada con Appian. No puedes implementar ningún elemento HTML o CSS directamente, y no puedes usar directamente JavaScript. Para hacerlo indirectamente, tendrás que usar los widgets gráficos especiales proporcionados por la plataforma.

Appian monitoriza el rendimiento de la aplicación tanto durante el desarrollo como después de su lanzamiento.

On>

3. Microsoft PowerApps

Microsoft PowerApps es fácil de usar y tiene un espacio de trabajo intuitivo que se asemeja a Microsoft Excel. Con PowerApps, puedes crear una aplicación:

• Usando modelos
• Basado en bases de datos
• Desde cero

La principal ventaja de PowerApp es que los desarrolladores pueden dar a los empleados acceso a las herramientas de desarrollo corporativo para que puedan crear de forma independiente los servicios y aplicaciones que necesitan. Los desarrolladores pueden entonces desarrollar aún más estas aplicaciones basadas en la web, aplicaciones para móviles y APIs usando los servicios de Azure.

La plataforma PowerApps proporciona un rico conjunto de plantillas gratuitas, por lo que es una buena elección para quienes no tienen experiencia en programación o tienen poca.

PowerApps no ofrece opciones de estilo directo con código CSS, aunque esta opción podría implementarse en el futuro. Hasta entonces, puede sortear esta restricción escribiendo estilos directamente en una función.

PowerApps también le permite crear sus propios elementos utilizando HTML. Además, puede utilizar las funciones incorporadas para la personalización de la interfaz.

PowerApps permite supervisar el rendimiento de las aplicaciones y proporciona información sobre las formas de mejorarlo manualmente. En la documentación oficial de PowerApps y en el blog de la comunidad se presentan recomendaciones adicionales para mejorar el rendimiento de las aplicaciones.

Puede obtener Microsoft PowerApps comprándolo directamente o como parte de su suscripción a Office 365 o Dynamics 365.

Lee también:

Microsoft Dynamics 365: Extensiones personalizadas e importación de datos

4. 4. Apéndice

El apéndice es una plataforma cómoda y fácil de usar que garantiza un alto nivel de tolerancia a las fallas y puede ser desplegada en un solo clic. Proporciona un gran conjunto de controles y es totalmente personalizable. Pero lo más importante, a diferencia de otras plataformas de nuestra lista, Mendix es una plataforma abierta y no está bloqueada por un fabricante.

Mendix está escrito usando CSS / Sass y soporta la integración con Bootstrap. Tiene una interfaz de usuario totalmente personalizable, y puedes personalizar todo el marco de trabajo usando sólo CSS.

También puedes crear widgets personalizados y temas completamente personalizados. Además, hay una herramienta de personalización de la interfaz de usuario visual incorporada que incluye una opción para crear estilos y esquemas de color personales.

El backend también puede ser personalizado de varias maneras, incluyendo el uso de las APIs de REST y con su propio código Java.

La compatibilidad con los sistemas existentes es fácil de configurar. También se da a los usuarios flexibilidad y control sobre el desarrollo del sistema.

Para controlar el rendimiento de la aplicación, se pueden utilizar tres herramientas de control del apéndice:

1. Monitor de calidad de la aplicación
2. Suite de pruebas automatizadas
3. Supervisión del rendimiento de las aplicaciones

Para quienes no tienen mucha experiencia en materia de desarrollo, Mendix ofrece una rica biblioteca de documentación técnica con ejemplos detallados.

El costo de la utilización de Mendix depende del número de usuarios de la aplicación y no del número de desarrolladores o la complejidad de la aplicación. Actualmente, la plataforma ofrece cuatro esquemas de precios: una versión gratuita, Single App, Pro y Enterprise.

5. Base rápida

Quick Base es una combinación perfecta para aquellos que quieren construir una aplicación para recolectar y almacenar información o automatizar procesos regulares. Con las herramientas de desarrollo de bajo código que proporciona esta plataforma, puede construir aplicaciones incluso si no sabe nada de programación basada en tablas.

Usando conectores de aplicación preconstruidos, Quick Base permite la integración con algunas soluciones populares basadas en la nube:

• Fuerza de ventas
• NetSuite
• Gmail
• Caja
• Y más

Las características de seguridad y gestión incluyen funciones y permisos granulares y gestión de usuarios corporativos. La interfaz de usuario sólo puede personalizarse con la ayuda de herramientas incorporadas que ofrecen un conjunto limitado de opciones de personalización.

Esto es lo que puedes hacer con la ayuda de la Base Rápida:

• Supervisar el rendimiento de la aplicación
• Mostrar información importante como la velocidad de arranque de la red y el tiempo de respuesta del servidor de la Base Rápida
• Analizar el rendimiento actual de la aplicación

Quick Base también puede proporcionarle recomendaciones sobre cómo mejorar el rendimiento de la aplicación manualmente.

En cuanto a los precios, Base Rápida ofrece actualmente dos planes: Quick Base Premier ($25 por usuario por mes) y Quick Base PLATAFORMA ($1,600 por mes).

Lee también:

Pruebas basadas en la nube: Beneficios, desafíos, tipos y consejos

6. Creador de Zoho

Zoho Creator es una plataforma fácil de usar y flexible con una interfaz intuitiva y atractiva. Usando Zoho Creator, puedes construir aplicaciones simples que cumplan con tus requerimientos.

El Creador de Zoho es una buena alternativa para construir una perfecta base de datos de seguimiento de clientes. La plataforma puede ser rápidamente adaptada a cualquier equipo.

Mientras que el Zoho Creator está escrito en Java, tendrás que usar Deluge, un lenguaje de programación desarrollado específicamente para esta plataforma, para escribir tu propio código en él.

Zoho Creator le permite importar datos de bases de datos, archivos almacenados en su ordenador y archivos del almacenamiento en la nube. Para integrar Zoho Creator con una base de datos existente, es posible que necesite instalar un software adicional.

Las herramientas incorporadas le permiten personalizar la interfaz de usuario según sus necesidades cambiando los diseños de página, los formularios, los temas y los iconos.

Para la personalización del backend, la plataforma soporta las APIs de REST y una herramienta de código especial llamada Deluge Script Builder. Esta herramienta permite añadir su propia lógica y cambiar la configuración del usuario.

Zoho>

El Creador de Zoho no es el más adecuado para escribir proyectos serios y complejos. Sin embargo, la plataforma ofrece uno de los más ricos conjuntos de plantillas para el desarrollo de aplicaciones. Hay muchas soluciones ya preparadas que puedes personalizar según tus necesidades.

También ofrece uno de los planes de precios más asequibles, a partir de 10 dólares por usuario y mes.

Servicios conexos

Servicios de desarrollo de aplicaciones web personalizadas & Soluciones

7. Google App Maker

Google App Maker puede ayudarte a crear una aplicación sencilla en menos de media hora. Con Google App Maker, puedes administrar los roles de acceso y crear secuencias de comandos de cliente y de servidor.

La plataforma proporciona un gran conjunto de plantillas para el desarrollo de aplicaciones. Sin embargo, es preferible tener al menos conocimientos básicos de programación, ya que puede ser necesario escribir algunas partes del código a mano.

El App Maker puede integrarse con algunas de las aplicaciones y servicios más populares de Google, incluyendo Google Drive y Google Analytics.

Google App Maker te permite escribir tu propio código CSS para personalizar la interfaz de usuario. El backend puede personalizarse con la ayuda de las API REST y de las solicitudes HTTP, así como escribiendo tu propio código en el editor JavaScript de App Maker.

Uno de los inconvenientes de esta plataforma es que el creador de aplicaciones de Google no ofrece herramientas de control y mejora del rendimiento, al menos por ahora.

En cuanto al precio, App Maker es parte del paquete G Suite Business, que tiene dos niveles de precios: Business (10 dólares por usuario y mes) y Enterprise (25 dólares por usuario y mes). Ambas versiones tienen una prueba de 14 días.

Nota: La información de la tarjeta de crédito es necesaria para acceder a la versión de prueba del servicio.

Lee también:

Cómo usar el Colaborador de Google para el procesamiento de video

8. Kissflow

Kissflow es una plataforma de servicios para automatizar los flujos de trabajo de los procesos empresariales. Está estrechamente integrada con Google Apps y proporciona una rica selección de tablas y formularios dinámicos para la recogida de datos.

Aunque Kissflow no tiene una herramienta incorporada para la integración de la base de datos, se puede añadir una base de datos existente con la ayuda de soluciones de terceros.

No hay un apoyo oficial de la comunidad de Kissflow, pero hay muchas guías e información técnica detallada en el sitio web del proyecto.

Uno de los principales inconvenientes de Kissflow es que no proporciona ninguna herramienta para la supervisión del rendimiento de las aplicaciones. Además, no pudimos encontrar ninguna recomendación útil para mejorar el rendimiento.

Kissflow es muy adecuado para las pequeñas empresas, ya que ofrece tanto una gran funcionalidad como un precio asequible. Hay una prueba estándar de 14 días, mientras que el servicio de pago comienza a partir de 9 dólares por usuario al mes para organizaciones con 10 a 100 usuarios.

9. Plataforma de fuerza de ventas

La plataforma Salesforce es una herramienta útil para el desarrollo de aplicaciones de bajo código. Es compatible con la base de datos del lenguaje de consulta de objetos de Salesforce (SOQL). Pero para integrar la Plataforma de Salesforce con otras bases de datos, también necesitará utilizar las API. Es compatible con el protocolo de acceso a objetos simples (SOAP) y con el protocolo de transferencia de estados de representación (REST).

La plataforma de Salesforce es una gran elección para automatizar procesos repetitivos en pequeñas y medianas empresas e integrar su aplicación con aplicaciones externas.

Desafortunadamente, hay un gran problema con esta plataforma: una interfaz de usuario sobrecargada con demasiadas opciones. La interfaz puede parecer demasiado complicada para los usuarios menos experimentados. Afortunadamente, si tiene suficientes conocimientos y experiencia, puede personalizar completamente la plataforma Salesforce a sus necesidades específicas con la ayuda de las API.

Trabajar con la plataforma Salesforce le costará 150 dólares al mes por cada usuario. Hay disponible una prueba gratuita.

10. Radzen

Aunque Radzen es más una aplicación de escritorio que una plataforma de desarrollo de código bajo, seguramente merece un lugar en nuestra lista.

Radzen genera aplicaciones angulares y permite obtener código generado que luego puede personalizar de la manera que desee. Sin embargo, tienes que entender qué es exactamente lo que la plataforma ha generado y cómo lo ha hecho, lo que hace que Radzen sea una herramienta más adecuada para desarrolladores experimentados y no para novatos.

Todos los archivos generados por Radzen pueden abrirse en el código de Visual Studio.

La plataforma Radzen tiene un rendimiento moderado, por lo que la IU puede retrasarse de vez en cuando. Toda la lógica se implementa en clases y métodos parciales de C#, lo que puede hacer que el desarrollo de la aplicación sea un poco más complicado. La buena noticia es que la plataforma está mejorando constantemente, por lo que los problemas de rendimiento actuales pueden resolverse en un futuro próximo.

Radzen tiene tres planes de precios:

1. Versión gratuita (con capacidades limitadas)
2. Profesional ($50 por mes)
3. Enterprise ($109 por mes)

Radzen es una buena opción para proyectos pequeños y aplicaciones que no necesitan ninguna funcionalidad compleja.

Servicios conexos

Subcontratar el desarrollo de software en C/C++

Conclusión

En este artículo, le hemos ofrecido nuestra propia selección de las mejores plataformas de desarrollo de código bajo para el 2019. Como pueden ver, cada una de estas plataformas tiene sus interesantes características y sus decepcionantes limitaciones.

Las LCDP serán útiles tanto para los desarrolladores como para los no programadores. Estas plataformas le ayudan a construir aplicaciones más rápidamente y a personalizarlas según sus necesidades específicas, incluso si no tiene grandes habilidades de desarrollo. Sin embargo, si desea construir una aplicación empresarial compleja desde cero y equiparla con una gran selección de características, es mejor que recurra a profesionales.

En Apriorit, tenemos un equipo de desarrolladores experimentados que dominan el arte de escribir código. Podemos ayudarle a crear una aplicación de cualquier nivel de complejidad para satisfacer perfectamente sus requerimientos. No dude en contactarnos.

La entrada Las 10 mejores plataformas de desarrollo de código bajo [Actualizado] se publicó primero en Descargar Driver.

Los problemas de seguridad se suelen tener en cuenta al desarrollar soluciones web y SaaS. Sin embargo, la seguridad es importante para todos y cada uno de los productos, sin importar los objetivos que sirvan y las tecnologías que utilicen. En Apriorit, siempre incluimos las pruebas de seguridad en nuestras estrategias de control de calidad.

En este artículo, nos centramos en algunos aspectos cruciales de las pruebas de seguridad de Linux. Al desarrollar un sistema para proteger las máquinas virtuales de Linux con la ayuda de un módulo del núcleo de Linux, prestamos atención a la seguridad del componente más esencial – el módulo del núcleo. Los problemas de seguridad cuando se carga y ejecuta un módulo del núcleo pueden hacer vulnerables a las máquinas virtuales y evitar que todo el sistema funcione correctamente.

A continuación, compartimos nuestra experiencia probando la seguridad de los módulos del núcleo de Linux. Este post será útil para los desarrolladores e ingenieros de control de calidad que están trabajando con el desarrollo del núcleo de Linux y se preocupan por las pruebas de los módulos del núcleo de Linux.

Probando un módulo antes de cargarlo en el kernel de Linux

Las pruebas de seguridad de un módulo del núcleo de Linux tienen que empezar en la etapa más temprana – el momento en que el núcleo se carga cuando el sistema arranca. La razón es que los hackers pueden encontrar vulnerabilidades en esta misma etapa y usarlas para alterar o comprometer el módulo.

Por eso es mejor comenzar las pruebas del módulo del núcleo de Linux con el examen del sistema de inicialización y la identificación de sus puntos débiles.

Cuando un sistema arranca, el propio núcleo carga la mayoría de los módulos del núcleo. Los módulos adicionales se cargan más tarde si se mencionan en etc/módulos. Los módulos se cargan junto con sus dependencias por el demonio modprobe. Además, los módulos del núcleo tienen opciones que pueden establecerse usando los archivos de configuración en /etc/modprobe.d/> o /lib/modprobe.d/.

Así, nuestra primera vulnerabilidad potencial se esconde en los archivos de configuración en modprobe.d. Usando los archivos de configuración, los ciberdelincuentes pueden impedir que un módulo se cargue cuando el sistema se inicia.

Hay varias maneras de evitar que un módulo se cargue. Exploremos en detalle los tres escenarios más comunes.

Servicios conexos

Pruebas de seguridad

Añadir un módulo a la lista negra

Una posible forma de detener la carga de un módulo del núcleo es ponerlo en una lista negra en un archivo de configuración. Hay dos maneras de hacerlo.

1. Crear un archivo *.conf.; en /etc/modprobe.d con el comando «blacklist <nombre del módulo

Aquí hay un ejemplo para Ubuntu y el módulo r8169 para un controlador de tarjeta de red:

                # echo "blacklist r8169"; /etc/modprobe.d/1.conf# update-initramfs -u# reboot

Cuando el sistema arranque, el módulo r8169 no se cargará.

Sin embargo, puedes cargarlo manualmente usando este comando:

                sudo modprobe r8169

Tenga en cuenta que puede agregar «lista negra <nombre del módulo»; a cualquier *.conf existente en la carpeta /etc/modprobe.d.

2. Crear un archivo *.conf en /lib/modprobe.d con «blacklist <nombre del módulo

Ejemplo para Ubuntu:

                # echo "blacklist r8169"; /lib/modprobe.d/1.conf# update-initramfs -u# reboot

El resultado es el mismo: el controlador de la tarjeta de red no se cargará cuando el sistema se inicie.

Desactivando un módulo del núcleo

Aparte de añadir módulos a una lista negra, hay otras formas de deshabilitarlos para que puedan&aposicionarlos.

Para desactivar un módulo, puede redirigirlo usando el comando de instalación. Si lo hace, modprobe intentará cargar el archivo conectado y definir el módulo de forma incorrecta (por ejemplo, como /bin/true o /bin/false), por lo que no se cargará.

Ejemplo:

1. Crear un archivo *.conf en /etc/modprobe.d con el comando "install <nombre del módulo> /bin/false" o "install <nombre del módulo> /bin/true":

…pre..;
# echo "install r8169 /bin/true" > /etc/modprobe.d/1.conf# update-initramfs -u# reboot
…y que no se puede hacer nada..;

Una vez más, el módulo r8169 no se cargará cuando el sistema arranque.

Tenga en cuenta que puede agregar "instalar <nombre de módulo> bin/true" a cualquier archivo *.conf existente en la carpeta /etc/modprobe.d.

2. 2. Crear un archivo *.conf en /lib/modprobe.d con "install <nombre del módulo> /bin/false" o "install <nombre del módulo> /bin/true", como se muestra en el ejemplo siguiente:

…pre..;
# echo "instalar r8169 /bin/true" > /lib/modprobe.d/1.conf# update-initramfs -u# reboot
…y que no se puede hacer nada..;

Cuando el sistema arranque, el módulo r8169 no se cargará.

Poner un módulo en la lista negra a través de los ajustes del cargador de arranque GRUB

Aparte de los archivos de configuración en /etc/modprobe.d/ y /lib/modprobe.d/, otra posible vulnerabilidad radica en la configuración del cargador de arranque GRUB, que también le permite poner en la lista negra los módulos del núcleo.

Por ejemplo, puedes añadir este código a /etc/default/grub:

…pre..;
GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=<nombre_de_módulo>"
…y la lista de los módulos..;

En este caso, el módulo especificado no se cargará cuando el sistema se inicie.

Al realizar las pruebas de seguridad de los módulos del núcleo de Linux, es fundamental comprobar las principales vulnerabilidades que pueden permitir evitar que se cargue un módulo específico del núcleo. El sistema bajo prueba tiene que comprobar el módulo del kernel y protegerlo para que no se cargue.

Comprobación de la inicialización del módulo en el sistema de inicio

Además de cargar un módulo del núcleo mediante el modprobe, también puedes intentar cargarlo automáticamente en el sistema de inicio. Aunque esta es una forma inusual de cargar un módulo del núcleo, puede ser usado en un sistema bajo prueba.

Exploremos cómo funciona la carga automática del núcleo en el sistema de inicio.

Cuando un módulo del núcleo se carga, el sistema de inicio monta un sistema de archivos raíz. Entonces el programa init se lanza e inicializa el sistema bajo prueba.

Los ajustes de inicialización se describen en el archivo de configuración de etc/inittab. Uno de los ajustes esenciales es el nivel de ejecución, un estado operativo preestablecido para un sistema operativo de tipo Unix.

Hay siete niveles de ejecución para los sistemas de inicialización de Linux:

• 0 – Parada del sistema
• 1 – Modo monousuario
• 2 – Modo multiusuario sin red
• 3 – Modo multiusuario con red
• 4 – No utilizado/definible por el usuario
• 5 – Modo multiusuario con red, administrador de pantalla y soporte X11
• 6 – Reinicio del sistema

Una vez que se determina el nivel de ejecución, el init ejecuta enlaces simbólicos del catálogo /etc/rc.d/rcN.d, donde N es el número de nivel de ejecución.

Los enlaces se nombran según el formato S<num><name>, de modo que se incluyen tanto el nombre como el número de orden del guión. Los guiones, a los que se hace referencia mediante los enlaces, se almacenan en la carpeta /etc/rc.d/init.d.

Si almacena un script de inicio del módulo del kernel en la carpeta /etc/rc.d/init.d y pone enlaces a este script en las carpetas etc/rc.d/rcN.d, el módulo del kernel se cargará después de que el sistema se inicie sin usar modprobe.

Esto significa que hay otras vulnerabilidades potenciales en el proceso de carga del módulo del núcleo. Si un módulo del núcleo se carga a través de un script en /etc/rc.d/init.d, los hackers pueden evitar que se cargue:

• Cambiar o eliminar el script de inicio en /etc/rc.d/init.d
• Cambiar o eliminar los enlaces simbólicos en las carpetas /etc/rc.d/rcN.d

Cuando se prueba un sistema, es crítico comprobar si puede detectar y reaccionar a cualquier cambio en la carga automática de scripts y en los enlaces simbólicos con los niveles de ejecución requeridos.

Servicios conexos

Desarrollo del núcleo y del controlador

Validar un módulo del núcleo antes de cargarlo en el núcleo de Linux

Los módulos del núcleo son responsables de varios procesos. Por lo tanto, tienes que asegurarte de que el módulo que vas a cargar en el núcleo de Linux es el que planeaste cargar.

Un error tan simple como cargar el módulo equivocado puede tener graves consecuencias:

• Fuga de datos
• Interrupción de datos
• Cifrado forzado de datos
• Corrupción de la funcionalidad del módulo del núcleo
• Pánico en el núcleo de Linux

El pánico del núcleo es una medida de seguridad adoptada por el núcleo de un sistema operativo al detectar un error interno fatal del que el núcleo no puede recuperarse con seguridad o tras el cual el sistema no puede seguir funcionando sin un elevado riesgo de pérdida de datos importante.

Para evitar consecuencias negativas, siempre valide un módulo del núcleo antes de cargarlo en el núcleo de Linux. Esto se puede hacer de varias maneras.

Veamos más de cerca los dos métodos más populares para validar un módulo del núcleo.

Validación del hash de un módulo del núcleo

Cualquier modificación de un módulo lleva a un cambio en su hachís. Para validar la corrección de una modificación, se puede usar el Algoritmo de Hash Seguro 1 (SHA-1).

La verificación de los archivos con SHA-1 se hace produciendo una suma de comprobación antes de que el archivo se haya transmitido, y luego otra vez una vez que llega a su destino. El archivo transmitido puede considerarse genuino sólo si las sumas de verificación son idénticas.

Si aparece alguna modificación no autorizada o el módulo malicioso se disfraza como el suyo, la suma de comprobación descubrirá el intento de comprometer su hachís. Las posibilidades de que los hackers consigan la suma de comprobación correcta son más que bajas.

Verificación de la firma de un módulo del núcleo

Cuando se compila un módulo, se firma con un certificado único de la compañía que no puede ser fabricado o emulado. Si el módulo está firmado con cualquier otro certificado, éste será identificado al validar la firma del módulo.

Esto significa que aunque los ciberdelincuentes consigan sustituir el módulo del núcleo y mantener la suma de comprobación de un archivo original, no hay posibilidad de que puedan firmar el módulo con un certificado único de la empresa.

Si no hay firma o el certificado es incorrecto, este problema se identificará durante la etapa de validación antes de cargar el módulo en el núcleo de Linux.

Lee también:

Usando Kali Linux para la prueba de penetración

Protección de los módulos inicializados

Una vez que hayas terminado las pruebas de seguridad del módulo del núcleo durante la carga, es hora de pasar al siguiente paso: proteger el módulo inicializado. Después de que un módulo es inicializado, los hackers todavía tienen la oportunidad de quitarlo o reemplazarlo.

En primer lugar, hay que asegurar el archivo del módulo y controlar las manipulaciones con modprobe que afectan a la carga del módulo.

Además, preste atención a cualquier dispositivo PCI conectado al módulo. Compruebe las posibles manipulaciones del dispositivo, ya que pueden llevar a la pérdida de eficiencia del módulo del núcleo.

Por último, si el módulo se carga automáticamente en el sistema de inicio, debería comprobar y gestionar las posibles manipulaciones con scripts para la carga automática o con enlaces simbólicos en los niveles de ejecución requeridos.

Exploremos en detalle cada una de las posibles vulnerabilidades mencionadas anteriormente.

Control de las operaciones con el archivo del módulo

Es crucial asegurarse de que el módulo del núcleo funcione correctamente y no se descargue, modifique o elimine.

Por lo tanto, tienes que comprobar las operaciones del archivo primario con el archivo del módulo:

• Renombrar
• Quitar
• Transferir a otra carpeta
• Modificar el módulo
• Modificar los atributos
• Reemplazar el archivo del módulo

Además, compruebe estas operaciones para la descarga del módulo:

• Rmmod
• Modprobe -r

Todas estas operaciones tienen que ser bloqueadas tanto para los usuarios habituales como para las cuentas de raíz.

Control de operaciones con un dispositivo PCI

Dado que gran parte del núcleo en funcionamiento son controladores, y los controladores se instalan en los dispositivos, también es importante comprobar las operaciones relacionadas con los dispositivos PCI.

Las operaciones que tienes que comprobar son:

• Desvincular el conductor del dispositivo
• Dispositivo de desactivación
• Quitar el dispositivo
• Dispositivo de apagado

Todas estas operaciones pueden impedir la interoperabilidad entre un módulo (conductor) y un dispositivo PCI, que puede detener el módulo. Para ser más específicos, estas operaciones pueden conducir a un acceso alterado, fuga de datos o pérdida de datos.

Control de operaciones con el sistema init

Como hemos mencionado, hay dos posibles vulnerabilidades en el sistema de inicio que deberían preocuparle:

• Guión de inicio en /etc/rc.d/init.d
• Enlaces simbólicos en las carpetas /etc/rc.d/rcN.d.

Después de la inicialización del módulo, hay que comprobar las operaciones esenciales de los archivos para esos scripts y enlaces. De esta manera, puedes asegurarte de que los ajustes del módulo no pueden ser modificados para evitar que el módulo del núcleo se cargue.

Compruebe las siguientes operaciones con los scripts de inicio y los enlaces simbólicos:

• Renombrar
• Quitar
• Modificar el contenido
• Transferir a otra carpeta
• Modificar los atributos

Todas estas operaciones deben bloquearse tanto para los usuarios habituales como para las cuentas de raíz.

Lee también:

Enganchando las funciones del kernel de Linux, Parte 1: Buscando la solución perfecta

Protegiendo la memoria del módulo del núcleo

Ya hemos demostrado lo importante que es el funcionamiento del módulo del núcleo y por qué hay que proteger su integridad. Ahora es el momento de pensar en la memoria del módulo del núcleo.

No basta con proteger el módulo validando su hachís y su firma. También hay que controlar la memoria del módulo.

El módulo del núcleo opera la sección de operaciones de lectura-escritura. Al crear un registro en esta sección, los hackers pueden causar problemas como:

• El módulo o el sistema se cae
• Código de ejecución grabado en la memoria del módulo del núcleo en el sistema protegido
• Desglose o modificación de la funcionalidad del módulo

El proceso de comprobación y aseguramiento de la memoria del módulo del núcleo puede dividirse en dos pasos.

Paso 1. Revisa la lista de funciones importadas en el módulo justo después de ser cargado en el kernel de Linux

Preste atención a las funciones que utiliza el módulo. La utilidad de lectura puede ayudarte mostrando una lista de todas las funciones que utiliza un módulo. Tenga en cuenta que esta lista será larga – no menos de 100 funciones con seguridad.

Tienes que confirmar que la lista de funciones y todos los atributos que la acompañan son los que esperabas. Sólo verificando esta lista es posible asegurar que el rendimiento del módulo del kernel no se verá comprometido.

Paso 2. Asegurar la memoria del módulo del núcleo cargada en el núcleo de Linux en tiempo real

Este paso es un poco más complicado que el anterior.

Para controlar la memoria del sistema virtual (incluida la memoria del módulo del núcleo), hay que asegurar la posibilidad de gestionar la memoria a nivel de hardware o de hipervisor. Puedes hacer esto usando el hipervisor de QEMU, por ejemplo.

Puedes asegurar la seguridad de la memoria de la siguiente manera:

• Establezca permisos de sólo lectura para todas las secciones de la memoria con permisos de lectura-escritura para que la memoria no pueda ser modificada.
• Limitar el acceso a las secciones de memoria que deben tener permisos de lectura-escritura para que sólo el código del módulo del núcleo y las funciones importadas puedan escribir en ellas.

Lee también:

Cómo depurar el núcleo de Linux con QEMU y Libvirt

Conclusión

Los módulos del kernel son vulnerables durante todas las etapas de su funcionamiento, desde el lanzamiento del sistema hasta la ejecución de los procesos en el kernel de Linux.

No se pueden ignorar los riesgos relacionados con los módulos del núcleo, ya que pueden causar graves daños a cualquier proyecto y provocar pérdidas importantes.

Para garantizar la seguridad de los datos de los usuarios y la fiabilidad de su sistema, es necesario adoptar un enfoque complejo y coherente de la seguridad del módulo del núcleo.

En este artículo, describimos varios puntos débiles en la seguridad de los módulos del núcleo de Linux y sugerimos formas de abordar estos puntos débiles al ejecutar pruebas de seguridad.

En Apriorit, aprovechamos la experiencia de nuestro equipo profesional de control de calidad que nunca deja de explorar nuevas amenazas potenciales y formas de prevenirlas. Contáctenos si está buscando servicios de pruebas de seguridad robustos. Siempre estamos dispuestos a ayudar!

La entrada Cómo realizar una prueba completa de seguridad del módulo del kernel de Linux se publicó primero en Descargar Driver.

Es un buen ejemplo de una solución de desarrollo que puede utilizarse para construir un sistema de protección de datos. Puede aprender más sobre las tecnologías de seguridad que Apriorit desarrolla para varios proyectos. También eche un vistazo a nuestras competencias de desarrollo de drivers.

Windows incrustó mecanismos de encriptación

Ventajas del sistema sugerido, en comparación con las soluciones estándar

EFS (Sistema de cifrado de archivos) y Bitlocker son soluciones de cifrado estándar para Windows.

BitLocker proporciona una encriptación completa de la partición a nivel de sector. El controlador de BitLocker (fvevol.sys) se encuentra debajo del controlador ntfs.sys en la pila del sistema de archivos. Cifra y descifra automáticamente los bloques de datos escritos y leídos de la unidad física por NTFS. Por lo tanto, la unidad física NTFS parece no estar cifrada, pero si se intenta leer los datos en bruto desde ella pasando por encima de NTFS, se recibirá un dato cifrado [ Win Internals 6th. Parte2, Gestión de almacenamiento, página 173 ].

Cabe señalar que la aplicación más segura de BitLocker proporciona cifrado de la manera más eficaz: utiliza el coprocesador criptográfico del Módulo de Plataforma de Confianza 1.2, que existe en muchos ordenadores personales modernos. BitLocker todavía puede funcionar en PCs sin TMP, pero requiere la conexión de una memoria flash USB para cargar el PC, o salir del modo de hibernación (en este caso la implementación no proporciona protección contra la desconexión y el reinicio) [ Win Internals 6th. Part2, Storage Management, page 164] .

Obviamente, esta solución no permite asegurar los datos del usuario de aplicaciones maliciosas, que se ejecutan en el entorno de Windows, y tampoco evita la fuga de datos al transferir entre aplicaciones y subirlos a Internet.

El Sistema de Cifrado de Archivos (EFS) es un mecanismo estándar de NTFS que proporciona cifrado para partes separadas de la unidad lógica. El EFS funciona de forma transparente para las aplicaciones. El cifrado del EFS se basa en la contraseña específica de la cuenta. Los datos se cifran y descifran automáticamente cuando se accede a ellos por las aplicaciones que se ejecutan en la sesión del usuario que tiene permiso para descifrarlos.

Por lo tanto, el EFS tampoco permite asegurar los datos del usuario de aplicaciones maliciosas, que se ejecutan en la sesión del usuario que tiene el permiso para descifrar los datos. Y este mecanismo no permite prevenir la fuga de datos mientras se suben a Internet. Para resolver este problema, es necesario desarrollar un controlador de kernel personalizado. Esto resultará en una solución que proporcione un cifrado transparente de los objetos selectivos del sistema de archivos.

De manera similar a la EFS, la solución propuesta cifrará/descifrará los datos de acceso automáticamente. Sin embargo, la ventaja de este enfoque radica en el hecho de que la protección de los datos se lleva a un nivel de sesión de usuario. Se proporciona mediante el sistema de normas que dividen los procesos en permitidos y prohibidos. Así, mientras se leen los datos en la misma sesión de usuario, algunas aplicaciones recibirán datos desencriptados y otras, encriptados.

Uso de controladores de minifiltros para el cifrado de archivos

Principio general de los conductores de los minifiltros y su conexión con las unidades

El principio operativo del sistema de cifrado de archivos basado en el controlador del minifiltro radica en el hecho de que el controlador se conecta a las particiones de sistema seleccionadas, incluidas las unidades de sistema extraíbles, y filtra/visualiza todas las operaciones en los objetos del sistema de archivos, que se encuentran en esas particiones.

Así, no importa qué operación de archivo realice una aplicación, el controlador del minifiltro la verá y podrá cambiar sus parámetros. Por ejemplo, puede bloquear la apertura de archivos o el inicio de aplicaciones; redirigir la apertura a otro archivo; cifrar/descifrar o simplemente comprobar los datos mientras los lee/escribe en el archivo.

El controlador puede guardar información específica para cada partición, y luego usarla para cada operación. Por ejemplo, esta característica puede utilizarse para establecer diferentes parámetros de cifrado para cada partición. El controlador puede utilizar una lógica diferente para cada partición del sistema.

La información específica de una partición u otro objeto del sistema de archivos se encuentra en el objeto llamado contexto .

El principio de la conexión del controlador a una partición y la arquitectura del controlador del minifiltro son funciones estándar del marco del minifiltro de Windows. Por lo tanto, estos tipos de controladores son utilizados por otro software, por ejemplo, los antivirus.

Variando los parámetros de la conexión del controlador a una partición, podemos hacer que los controladores antivirus, que también están conectados a la partición, puedan recibir datos encriptados.

Para filtrar las operaciones de los archivos, el controlador del minifiltro registra las llamadas para cada operación del sistema de archivos. Estas llamadas son llamadas por el sistema cuando se ejecuta la operación específica.

Esquema general de cifrado en minifiltros

Sin restricción de acceso por proceso

Para iniciar el desarrollo del controlador del minifiltro de cifrado, necesitamos entender el esquema general de cifrado, empleado en la solución y cómo funciona la conexión a los manejadores de lectura/escritura.

Para cifrar los datos del usuario, el conductor del minifiltro tiene que registrar los manejadores de lectura/escritura – IRP_MJ_READ y IRP_MJ_WRITE, respectivamente. Puede realizarse mediante los métodos estándar proporcionados por el marco.

Hay varios tipos de operaciones de lectura y escritura en los sistemas de archivos:

• Lectura en caché desde un archivo – el controlador del sistema de archivos lee los datos desde la caché. Si la caché no tiene datos, el administrador de la caché lee los datos del archivo a la caché y luego devuelve los datos leídos al sistema de archivos.
• El controlador del sistema de archivos lee los datos directamente de la unidad. Si esta operación es iniciada por el Administrador de Caché, entonces los datos se mueven a сache para el archivo, y si es iniciada por la aplicación, entonces los datos no se mueven al caché para el archivo.
• Lectura rápida de IO – los datos se leen directamente de la caché, y no se crea IRP.
• Los datos se escriben en la memoria intermedia en сache. El gestor de caché no garantiza que los datos se escriban en un archivo en el disco a la vez.
• La escritura de IO de paginación – los datos se escriben directamente en el archivo de una unidad. Si esta operación es iniciada por el Administrador de la Caché, entonces la descarga tiene lugar, y si es iniciada por una aplicación, entonces los datos se escriben en el archivo y no se mueven a la caché.
• Escritura IO rápida – los datos se escriben directamente en la caché, evitando el sistema de archivos.

El administrador de caché suele utilizar operaciones de lectura/escritura de IO de paginación para leer los datos al caché o descargar los datos del caché al archivo. Así, después de la lectura de IO de paginación, los datos se mueven al caché, y después de la escritura de IO de paginación, los datos se escriben directamente en el archivo de la unidad.

NOTA: Según la experiencia de trabajo con el minifiltro, y el controlador de filtro del sistema de archivos para el cifrado, siempre debe haber datos descifrados en la caché. De lo contrario, hay casos de uso en que la aplicación puede recibir datos cifrados y descifrados al mismo tiempo.

Por ejemplo, si hay datos cifrados en el caché y la aplicación ha realizado la asignación de archivos, entonces la aplicación se referirá directamente a la región del caché, donde se encuentran los datos del archivo. Por lo tanto, el minifiltro no recibirá y descifrará las operaciones de lectura. Para manejar este caso, se utilizan ganchos en las funciones Nt* en los controladores de filtro del sistema de archivos para la arquitectura x86. Pero este enfoque está prohibido para los sistemas Windows x64.

Después de conectarse a una partición y registrar los handlers (IRP_MJ_READ y IRP_MJ_WRITE), el driver del minifiltro ve todos los tipos de operaciones anteriores (excepto FastIO). Pero el cifrado de datos del minifiltro para cada IO de buscapersonas que se escribe desde el Administrador de caché y el descifrado para cada IO de buscapersonas que se lee desde el Administrador de caché es suficiente para implementar el cifrado de archivos transparentes comunes sin restricción de acceso por proceso.

Por lo tanto, siempre habrá datos desencriptados en todas las aplicaciones y en la caché, y siempre habrá un dato encriptado en el archivo de una unidad.

Complicación del esquema en caso de restricción de acceso por proceso

La restricción del acceso a los procesos hace más complicado el desarrollo del controlador de cifrado de archivos sobre la marcha. La seguridad de los datos de la sesión de usuario significa que sólo una gama limitada de aplicaciones tiene acceso a los datos desencriptados. Otras aplicaciones deberían recibir datos encriptados mientras intentan leerlos desde un archivo.

Así, la lógica de la encriptación/desencriptación de datos por el minifiltro se hace más complicada.

El esquema simplificado de las acciones que deben ser realizadas por el minifiltro:

1. Lectura en caché solicitada por la aplicación bloqueada.

2. Lectura en caché solicitada por solicitud permitida.

3. Lectura no almacenada en caché por aplicación bloqueada.

4. No se lee en caché por aplicación permitida.

Durante la manipulación de las operaciones en el minifiltro se determina si el proceso está permitido o bloqueado. Para ello, se puede utilizar el contexto vinculado a cada FileObject. Este contexto se crea en un manejador en la operación de abrir/crear archivo. En este momento se conoce claramente el proceso que abre el archivo de destino. La información sobre el proceso puede almacenarse en este contexto. El contexto puede ser eliminado durante la operación de cierre del FileObject.

NOTA: Hay una característica muy importante en el trabajo de Cache Manager. Es el hecho de que las operaciones de paginación IO de un archivo pueden realizarse en el contexto de cualquier proceso del sistema, incluidos los procesos que no están relacionados con el archivo. Estas operaciones suelen ser realizadas por el proceso de servicio SISTEMA. El Administrador de caché utiliza uno de los FileObjects abiertos a un archivo y todas las operaciones de Paging IO se realizan a este FileObject. En este caso, el contexto del FileObject sirve para recibir información sobre el proceso que abrió el archivo y por lo tanto trabajó con él.

Además, será importante utilizar contextos por archivo.

NOTA: Para la arquitectura de minifiltros para sistemas operativos más antiguos que Windows Vita, estos contextos se implementan mediante contextos Per-Stream.

Como se desprende del nombre, este contexto está directamente vinculado al archivo de una unidad, independientemente de la cantidad de FileObjects abiertos. Para todos los FileObjects, abiertos para el archivo específico, este contexto es el único, y puede ser recibido a través de cualquier FileObject. Este contexto será eliminado por el sistema cuando se cierre el último FileObject.

NOTA: El contexto por archivo está relacionado con la estructura FCB en el controlador de cifrado del sistema de archivos, y como esta estructura existe hasta que cualquier FileObject abierto existe, entonces el contexto también lo hace.

En este contexto se almacenará información como, por ejemplo, si el archivo está cifrado, su tamaño descifrado, el indicador de modificación del archivo y otros datos que se utilizan para la aplicación del cifrado.

Problemas con esta arquitectura de solución

El desarrollo de controladores de cifrado de archivos mediante el enfoque de minifiltros tiene una gran desventaja, que el desarrollador inexperto puede no ser consciente de ello.

Mientras se utiliza el mapeo de archivos, los procesos a los que se les prohíbe descifrar el archivo siguen teniendo acceso a los datos descifrados de este archivo. Esto sucede porque en caso de mapeo de archivos la aplicación obtiene acceso directamente a la sección del caché, donde está la vista del archivo. Así pues, el minifiltro no puede detectar las operaciones de mapeo de archivos. Sin hacer cambios en la arquitectura de la solución de cifrado, este problema puede resolverse utilizando los ganchos de las funciones de mapeo de archivos. En el SO x64, sólo pueden ser ganchos en modo de usuario. Este enfoque implica procesos, y no es nativo y conduce a un gran número de posibles problemas de aplicación, que son muy difíciles de prever. Se está complicando por la imperfección de los motores de gancho disponibles por ahora y la necesidad de considerar una enorme cantidad de matices con la implementación de ganchos.

La solución más nativa para un sistema operativo (en términos de diseño) utiliza un controlador de minifiltro personalizado junto con un controlador de sistema de archivos personalizado.

Concepto: dos vistas del archivo encriptado, caches de encriptación y desencriptación para el mismo

Principio general de participación de la caché en la labor de una aplicación

Cuando la aplicación lee los datos del archivo, en el caso de la lectura regular en caché, estos datos son tomados de un caché por el sistema de archivos. Si no hay datos de destino en el caché, entonces al principio estos datos se colocan en el caché, y luego el sistema de archivos los devuelve a la aplicación. En el caso de la escritura normal en caché, los datos son escritos en el caché por el sistema de archivos, y luego en algún momento el Administrador de Caché envía estos datos a la unidad.

Cuando una aplicación utiliza el mapeo de archivos para trabajar con el archivo, obtiene acceso directamente a las secciones de la caché, donde se encuentra la vista de este archivo. Otra aplicación puede abrir este archivo en el mismo momento y realizar operaciones de caché con él. En este caso, ambas aplicaciones tienen acceso a la misma vista del archivo en la caché. Así pues, si una aplicación está permitida y otra no, la prohibida también tendrá acceso a los datos desencriptados. Puede evitar la fuga de datos utilizando los ganchos de modo de usuario, como se ha mencionado anteriormente. En los ganchos es necesario implementar una lógica particular para las aplicaciones prohibidas que trabajan con el mapeo de archivos. Esta lógica asignará su sección de memoria y colocará allí los datos cifrados, y luego devolverá esta sección a la aplicación.

División de caché para aplicaciones permitidas y prohibidas

Es posible otra arquitectura, en la que la vista de los archivos de las aplicaciones permitidas y prohibidas se divide en dos vistas separadas para cada uno de los tipos de aplicaciones. Sólo es posible si una vista coincide con un archivo de la unidad y otra con otro archivo. Por lo tanto, deben existir dos archivos diferentes, pero todas las aplicaciones deben ver sólo un archivo en su ubicación original. En el caso de las aplicaciones permitidas, todas las solicitudes deben redirigirse a otro archivo (desencriptado), que se encuentra en otra parte de la unidad.

Diagrama. No hay redireccionamiento al archivo desencriptado para aplicación prohibida

Diagrama. Redirección de operaciones a un archivo desencriptado para la aplicación permitida

En la arquitectura del sistema operativo Windows, la redirección «invisible» de las solicitudes de un archivo a otro se implementa mediante controladores de minifiltros. En este enfoque, el controlador del minifiltro intercepta una operación específica y la redirige «invisiblemente» a otro archivo. Sin embargo, por motivos de seguridad de los datos, es inaceptable almacenar un archivo desencriptado en una unidad. Por ello, este archivo puede almacenarse en la unidad de forma cifrada y ser descifrado durante las operaciones de lectura/escritura.

Almacenar dos archivos idénticos es extremadamente inconveniente, porque estos dos archivos deben sincronizarse constantemente, y el usuario puede simplemente eliminar el archivo confundiéndolo con un duplicado del archivo original, o simplemente con un archivo desconocido.

Es posible eliminar la necesidad de utilizar el segundo archivo de la unidad añadiendo un controlador especial de sistema de archivos a la arquitectura de la solución. Este controlador se monta como una unidad local separada ordinaria y se comporta en consecuencia: muestra los archivos y permite acceder a ellos. Pero es una unidad lógica virtual, por lo que lee archivos de cualquier otro catálogo en otra unidad local. En esta arquitectura de la solución, este controlador accede al archivo de usuario original encriptado de la unidad. La palabra «acceso» significa que el controlador muestra este archivo en su unidad local, y para cada operación de archivo realiza la misma al archivo original. Pero en este caso, el controlador descifrará y cifrará las operaciones de lectura/escritura al archivo original. Por lo tanto, si una aplicación fuera redirigida a este controlador, recibiría datos descifrados de los archivos que muestra este controlador.

Diagrama. Redirección del acceso al archivo original al controlador del sistema de archivos

Implementación de la idea: controlador de redireccionamiento + controlador de sistema de archivos virtual

Como se muestra en el diagrama, el controlador del minifiltro, que redirige accesos específicos a los archivos, y el controlador del sistema de archivos, que recibe las redirecciones, deberían utilizarse para poner en práctica la idea. Resulta que, cuando la aplicación accede a cualquier archivo, esta operación puede ser redirigida «implícitamente» a otro archivo.

Qué es la redirección y cómo funciona

Antes de realizar las operaciones de lectura/escritura, es necesario abrir primero el archivo. La redirección del acceso al archivo consiste en lo siguiente: el controlador del minifiltro visualiza las operaciones de apertura del archivo y las redirecciona a otro archivo mediante mecanismos estándar para los filtros del sistema de archivos. A continuación, todas las demás operaciones de la sesión de apertura y cierre de archivos se realizan automáticamente con el archivo al que se ha redirigido y, por lo tanto, se realizan a través del controlador del sistema de archivos al que se ha redirigido.

Tareas de redireccionamiento

El redactor debe interceptar las operaciones de archivos abiertos y detectar si este archivo está cifrado y si la aplicación puede descifrarlo.

Si el archivo está cifrado y se permite que una aplicación lo descifre, el controlador de redireccionamiento redirige el archivo que se abre al controlador del sistema de archivos.

Tareas del conductor del FS

El controlador de FS proporciona características estándar del sistema de archivos, aunque no trabaja directamente con los datos de una unidad física, sino que lee y escribe datos en otro archivo de cualquier otra partición. Esto significa que, a través de la API estándar para trabajar con archivos en modo de kernel, el controlador de FS realiza operaciones de archivo recibidas de la aplicación con ese archivo. Este controlador es un dispositivo de volumen virtual, por lo que debe montarse como un dispositivo de volumen. Sin embargo, el controlador no debería asignar una letra de unidad al dispositivo de volumen, por lo que el usuario no podría tener un acceso directo a este volumen desde las aplicaciones.

El controlador debería mostrar el archivo desencriptado a la aplicación, por lo tanto, se debería implementar en él una lógica que desencripte/encripte los datos durante la lectura/escritura a archivo y permita mostrar el archivo de tamaño correcto a la aplicación.

Mostrar un tamaño de archivo correcto es una característica importante de este controlador, porque el tamaño del archivo cifrado puede diferir del tamaño del descifrado.

NOTA: Para un manejo más fácil del archivo cifrado, se suele añadir un encabezado. Esto resulta en la necesidad de control de sesgo durante operaciones de lectura/escritura al archivo cifrado en el controlador.

Algunas ideas sobre una implementación del controlador del sistema de archivos.

Construir un conductor en base a FASTFAT

WDK proporciona ejemplos de desarrollo de controladores de sistemas de archivos de encriptación utilizando FASTFAT. Este controlador puede convertirse en la base del controlador de la arquitectura de la solución del sistema de archivos descrito anteriormente.

Es necesario dejar en el controlador la capa de gestión de los objetos lógicos de FS (estructuras FCB, CCB), así como la caché, el acceso compartido al archivo y la gestión de OpLocks. Se debe eliminar la capa que gestiona los archivos y directorios de datos directamente en la unidad física, todo lo relativo al dirent, y todas las operaciones del driver enviadas a los dispositivos que se encuentran debajo de ella en la pila del sistema de archivos.

Dado que el controlador recopila datos de otro archivo de la unidad lógica, debe incluir una lógica que abra este archivo cuando la solicitud de apertura provenga de la aplicación y lo mantenga abierto hasta que la solicitud de cierre llegue al controlador.

Según la regla «el controlador debe mostrar el archivo desencriptado», se debe agregar la siguiente lógica al controlador:

• cifrado/descifrado de datos durante operaciones de lectura/escritura no almacenadas en caché;
• durante las operaciones de especificación y obtención del tamaño del archivo, corrigiendo el tamaño para que el controlador especifique el tamaño de los datos cifrados como el tamaño del archivo, y devuelva el tamaño de los datos descifrados.

Para que esta unidad lógica sea inaccesible para otras aplicaciones, no debe informar al Mount Manager sobre el dispositivo durante su montaje.

El controlador de redireccionamiento necesita conocer la ruta nativa оf del dispositivo de volumen para poder redirigir las operaciones a la unidad lógica virtual. Por eso el controlador del sistema de archivos debe informar al controlador del redirector sobre esta ruta. Para ello, es necesario crear un dispositivo de control en el controlador del sistema de archivos, a través del cual sería posible solicitar el nombre.

Mejora: sistema de archivos en modo de usuario

El controlador del sistema de archivos puede mejorarse para que el procesamiento de cada operación solicitada se realice en el servicio de modo de usuario. Para ello, los comandos que contienen parámetros y resultados de retorno deben ser enviados entre el servicio y el controlador.

NOTA: este intercambio de datos puede organizarse mediante el mecanismo del Modelo de Llamada Invertida que está bien descrito por la OSR. Mediante este mecanismo, en cada operación del sistema de archivos, que proviene de una aplicación, el conductor envía al servicio un comando específico correspondiente a esta operación. Junto con este comando, el controlador enviará todos estos parámetros de operación y esperará a que el servicio devuelva los resultados. Entonces el controlador enviará este resultado como resultado del procesamiento de la operación solicitada por una aplicación. Utilizando todos los parámetros de la operación, que fueron enviados por el conductor, el servicio realiza las acciones necesarias y devuelve el resultado al conductor. Esta arquitectura es análoga a FUSE, que se utiliza en sistemas de tipo Unix.

Esa mejora permite pasar todas las operaciones de procesamiento al modo de usuario y evitar el desarrollo del código del núcleo. Esto hace que el cambio de la lógica de procesamiento de operaciones sea más flexible y rápido.

La mejora también permite:

• utilizando las bibliotecas de cifrado liberadas;
• almacenando las claves en servidores protegidos;
• validación de firmas digitales;
• usando la interfaz gráfica;
• usando diferentes lenguajes de programación;
• trayendo la lógica a la dll y actualizándola sin reiniciar el sistema;
• almacenando archivos en almacenes de nubes.

Por lo tanto, todas las oportunidades posibles que tienen las aplicaciones en modo de usuario se dejan abiertas.

Echa un vistazo a un tutorial sobre los controladores del filtro del sistema de archivos en nuestro blog.

Lea un tutorial sobre el Disco Virtual para Windows y obtenga las fuentes del código.

Aprenda sobre las tecnologías Apriorit listas para integrar: SDK de encriptación de archivos sobre la marcha

La entrada Desarrollo del controlador de cifrado de archivos con restricción de acceso por proceso se publicó primero en Descargar Driver.

Es una tarea bastante común controlar un driver de modo de núcleo desde una aplicación o servicio de modo de usuario. Pero cualquiera que haya escrito controladores sabe que es imposible ejecutar simplemente algún trozo de código de controlador directamente desde el modo de usuario. Para hacer posible el envío de comandos de control a un controlador, el sistema operativo proporciona un mecanismo de códigos de control IO (IOCTL$0027s). La biblioteca descrita en este artículo utiliza IOCTL como transporte subyacente.

¿Por qué RPC?

«¿No estáis complicando las cosas, chicos?» – el lector puede preguntarse, – «¿Por qué el DeviceIoControl no es lo suficientemente bueno para ti?». A primera vista, RPC puede parecer un enfoque demasiado complicado. Pero puedes tener ciertas dificultades para usar el DeviceIoControl y las IOCTL desnudas.

La forma convencional de enviar comandos de control a un conductor es declarar un IOCTL para cada comando. Puedes ver el artículo Driver to Hide Processes and Files (Controlador para ocultar procesos y archivos) de Ivan Romanenko y Sergey Popenko o el artículo How to develop a virtual disk for Windows (Cómo desarrollar un disco virtual para Windows) de Gena Mairanichenko. Estos artículos son los ejemplos de este enfoque.

El problema es que un conductor del mundo real puede tener docenas de códigos de control. Significa que la rutina de despacho que procesa los IOCTL puede ser tan larga que puede perderse allí.

Otra cosa es la transferencia de datos. Si necesitas enviar algunos datos complejos entre un controlador y una aplicación, empaquetarlos en un búfer y desempaquetarlos de nuevo puede ser una especie de tarea difícil y molesta. RPC tiene un mecanismo de serialización que hace el trabajo sucio por ti.

Así que la RPC hace que las cosas complicadas sean un poco menos complicadas.

¿Por qué C++ en Controlador?

RpcLib fue diseñado para ser usado en el código C++ y se basa en gran medida en las características de C++ como plantillas y excepciones. Actualmente no soporta los controladores escritos en C plano (porque nunca lo hemos necesitado). El uso de C++ en los controladores del modo kernel tiene sus pros y sus contras, pero no son el tema de este artículo.

Para hacer posible escribir los drivers del modo kernel en C++ utilizamos las versiones modificadas de CppLib y STLPort.

Parte del cliente

Usar RpcLib es realmente simple. Veamos cómo se ve desde el modo de usuario. Cuando necesitas llamar una función RPC desde el kernel, creas el objeto rpc::RpcCall en el lado del modo de usuario. Luego lo inicializas con el nombre del objeto registrado en el servidor y con el nombre del método que debe ser llamado.

                rpc::RpcCall cl("Muestra", "TraducirDirecciónVirtual");cl.Pack(DirecciónVirtual);cl.Call(transport_);cl.Unpack(&DirecciónFísica);

Luego pasas los argumentos de entrada, ejecutas la llamada y obtienes los argumentos de salida. Es bastante similar a la forma en que ocurre una llamada de función normal.

La clase rpc::RpcCall incapsula la llamada RPC. Así es como se ve:

                class RpcCall{public:RpcCall(const std::cadena& objName, const std::cadena& fncName, size_t bufferSize = 16*1024);{rpc::Archivo fuenteArchivo(&datos_[0], datos_.size());rpc::Pack(sourceArchive, objName);rpc::Pack(sourceArchive, fncName);curPackSize_ = sourceArchive.GetUsedSize();}template <class P>void Pack(const P& p){rpc::Archivo sourceArchive(&data_[0], data_.size(), curPackSize_, 0);rpc::Pack(sourceArchive, p);curPackSize_ = sourceArchive.GetUsedSize();}template <class senderType>void Call(senderType* sender){sender->Send(&data_[0], curPackSize_, data_.size(), &answerSize_);}template <class P;};void Desempaquetar(P* p){rpc::Archive sourceArchive(&data_[0], answerSize_, answerSize_, curUnpackSize_);rpc::Desempaquetar(sourceArchive, p);curUnpackSize_ = sourceArchive.GetCurRange();}};

Tiene un búfer del tamaño especificado (16Kb por defecto) para los parámetros de entrada y salida. El objeto rpc::RpcCall serializa el nombre del objeto RPC y el nombre de la función y los parámetros de entrada en este búfer (la serialización se describe en la sección Serialización). El método Call envía los datos desde el buffer a través del transporte dado por el llamador. Después de la ejecución de la llamada, la memoria intermedia contiene los datos de salida a deserializar.

Transporte

El propósito del transporte es enviar los datos de entrada de la llamada RPC al servidor y devolver los datos de salida. Normalmente, para enviar los datos de una aplicación en modo usuario a un conductor, se utiliza rpc::IoctlTransport. Es simplemente un envoltorio sobre el DeviceIoControl.

                Plantilla de la plantilla de la RPC_IOCTL, clase IoctlTransport{public:IoctlTransport(HANDLE device){}: device_(device){}evitar Enviar(char* buf, size_t inBufSize, size_t maxBufSize, size_t* BytesCount){if (!DeviceIoControl(device_,RPC_IOCTL, (void*)buf, (DWORD)inBufSize, (void*)buf, (DWORD)maxBufSize, (DWORD*)BytesCount,NULL)){throw std::runtime_error("Device IO control failed");}}private:HANDLE device_;};

Parte del servidor

Veamos ahora, cómo escribir el código para procesar las llamadas desde el modo de usuario. Aquí hay un ejemplo del típico objeto RPC con un método RPC:

                class Sample: public rpc::RpcSkelBase{public:Sample(rpc::IRpcServer* rpcServer){RPC_FUNCTION(Sample, TranslateVirtualAddress);rpcServer->RegisterObject("Sample", this);}void TranslateVirtualAddress(rpc::Archive& inBuf, rpc::Archive& outBuf){// ...}};

Cada función RPC es un método de objeto que toma dos argumentos: el búfer de entrada y el búfer de salida. Cada búfer está representado por un objeto de la clase rpc::Archivo. Normalmente, es necesario deserializar los argumentos del archivo de entrada con la función rpc::Unpack. Una vez finalizado el trabajo, se puede serializar el resultado en el archivo de salida con la función rpc::Pack (la serialización se describe a continuación). Si hay un error, el método debe lanzar una excepción. Será recogida por la biblioteca, serializada al modo de usuario y relanzada allí. Así, el que llama sabrá que algo ha salido mal.

Para hacer accesible una función RPC, es necesario registrarla con la macro RPC_FUNCTION en el constructor.

También, necesitas registrar el objeto mismo en el servidor RPC. Es un objeto que envía llamadas entre el objeto RPC. En el código anterior, el objeto está siendo registrado en el constructor, pero en realidad, puedes hacerlo donde quieras.

Para despachar las llamadas RPC, necesitas escribir algo como esto en la función donde procesas tus solicitudes de IOCTL:

                g_RpcServer-;process(buf, inSize, outSize, &outSize);

Así es como se usa la biblioteca desde el modo kernel. Como puedes ver, todo es bastante simple. Ahora, echemos un vistazo dentro de la parte del servidor de la biblioteca.

Objetos RPC

Todos los objetos RPC deben implementar la interfaz rpc::IRpcSkel:

                estructura IRpcSkel{virtual ~IRpcSkel(){ } vacío virtual Call(const std::string& fncName, rpc::Archive& inBuf, rpc::Archive&amp outBuf) = 0;};

Esta interfaz tiene la llamada de método, que obtiene el nombre de la función (como una cadena) y los archivos de los parámetros de entrada y salida. Debe utilizar el nombre de la función para enviar la llamada a la función correcta. Es una tarea rutinaria, así que escribimos la clase rpc::RpcSkelBase para hacer esto. Se implementa de la siguiente manera:

                class RpcSkelBase : public rpc::IRpcSkel{typedef boost::function<void(rpc::Archive&, rpc::Archive&)> RpcImplMethodType;typedef std::map<std::string, RpcImplMethodType;RpcMethodMap;public:void Call(const std::string& fncName, rpc::Archive& inBuf, rpc::Archive& outBuf){RpcMethodMap::iterator it = rpcMethods_.find(fncName);RpcImplMethodType pMethod = it->second;pMethod(inBuf, outBuf);}void RegisterRpcFunction(const std::string& funcName, RpcImplMethodType pFunc){if (rpcMethods_.find(funcName) != rpcMethods_.end())throw std::runtime_error(std::string(__FUNCTION__) + " - method " + funcName + " already registered");rpcMethods_.insert(std::make_pair(funcName, pFunc));}private:RpcMethodMap rpcMethods_;};

Todo lo que el usuario tiene que hacer es heredar su objeto de rpc::RpcSkelBase y registrar la función RPC usando la macro RPC_FUNCTION que has visto arriba.

Servidor RPC

Como mencionamos, el servidor RPC es el objeto que mantiene la lista de los objetos RPC y envía llamadas entre ellos. Implementa la interfaz rpc::IRpcServer. Funciona de la siguiente manera:

                struct IRpcServer{virtual ~IRpcServer(){} vacío virtual RegisterObject(const std::cadena& objName, IRpcSkel* pObject) = 0;vacío virtual Process(char* buf, size_t inBufSize, size_t maxBufSize, size_t * outBufSize) = 0;};

Hay una implementación por defecto de esta interfaz en RpcLib.

                class RpcServer: public RpcServerImpl{public:void RegisterObject(const std::string&amp; objName, IRpcSkel* pObject){if (!objects_.insert(std::make_pair(objName, pObject)).second){throw std::runtime_error(std::string(__FUNCTION__) + <cod

La entrada RPC ligero para llamar a un driver desde el modo de usuario … se publicó primero en Descargar Driver.

Pero, ¿qué pasa si la configuración de sincronización está desactivada y no se puede activar? No te preocupes! Sigue los siguientes métodos, sabrás cómo arreglarlo en un segundo.

Los Distintos Métodos Para Resolver los Ajustes de Sincronización

Nota: Aunque la configuración de sincronización sólo está disponible si utilizas una cuenta de Microsoft, antes de irnos, asegúrate de que el problema existe cuando iniciaste sesión en una de las cuentas.

Método 1. Inicie sesión con una cuenta de Microsoft diferente

La configuración de sincronización estaba desactivada, podría deberse a su cuenta de Microsoft. Tal vez su cuenta de Microsoft esté dañada. En este caso, puede iniciar sesión con una cuenta de Microsoft diferente para comprobar si puede activar la configuración de sincronización.

Método 2. Cambiar los ajustes de realimentación y diagnóstico

Los ajustes de Diagnóstico y Retroalimentación erróneos también pueden hacer que los ajustes de sincronización se oscurezcan. Siga los pasos que se indican a continuación para cambiar los ajustes de realimentación y diagnóstico.

1) Pulse sobre el botón Inicio y seleccione Configuración .
>.

2) Desplácese hacia abajo en la página Configuración y haga clic en Privacidad .
.

3) Desplácese hacia abajo en el panel izquierdo y haga clic en Feedback &Diagnostics .
.

4) Localice Datos de diagnóstico y uso en el panel derecho, configúrelo para que sea Mejorado o Completo (Recomendado) .
.

¡Eso es todo! Si tienes alguna pregunta, deja tu comentario a continuación.

La entrada Windows 10 Sync Settings (Ajustes de sincronización) Gris [Resuelto] se publicó primero en Descargar Driver.

Pero a veces puede ser un dolor tan grande que quieres apagarlo.

Aquí hay 3 métodos fáciles de seguir que puede intentar detener la actualización de Windows en Windows 10.

Pruebe estos métodos

Es posible que no tenga que probar todos los métodos (métodos 1-3) para deshabilitar Windows Update en su Windows 10 sólo tiene que recorrer la lista hasta que encuentre el que más le convenga.

1. Desactivar el Servicio de Windows Update
2. Medir su red Wifi
3. Cambiar la configuración de la directiva de grupo
4. Consejo adicional: Actualice los controladores de dispositivo mediante Driver Easy

Método 1: Desactivar el Servicio de Windows Update

El método 2 es bastante autoexplicativo. Al desactivar el Servicio de Windows Update , Windows dejará de buscar actualizaciones, con lo que se ahorrará las actualizaciones de Windows deseadas. Para hacerlo:

1) En el teclado, presione la tecla del logotipo de Windows y R at>services.msc en el cuadro y haga clic en OK .

2) Desplácese hacia abajo, localice y haga doble clic en Windows Update .

3) En Tipo de inicio, seleccione Desactivado , y luego haga clic en> Detener (asegúrese de que la palabra Detener esté en gris)> Aplicar> OK .

4) Reinicie su ordenador para que los cambios surtan efecto.

Método 2: Medir su red Wifi

Si estás usando una red Wifi, entonces el método 2 te servirá. Al medir su red Wi-fi , Windows tomará automáticamente que está en un plan de datos limitado (incluso si no lo está) y dejará de forzar las actualizaciones de Windows en su equipo. Aquí está el cómo:

1) En el teclado, pulse la tecla del logotipo de Windows , escriba wifi y haga clic en Cambiar la configuración de Wi-Fi .

2) Haga clic en en el nombre de su conexión Wifi .

3) Conmutar el interruptor Set as metered connection On .

4) Esperamos que resuelva tus problemas y que no veas otra actualización de Windows’no solicitada’ en tu ordenador.

Método 3: Cambiar la configuración de la directiva de grupo

Tenga en cuenta que el Método 3 funciona en Windows Pro , Enterprise , y Professional EXCEPT Windows Home ya que no tiene directiva de grupo.

1) En el teclado, presione la tecla del logotipo de Windows y R al mismo tiempo, luego escriba gpedit.msc en el cuadro y haga clic en OK .

3) Haga doble clic en Configuración del ordenador> Plantillas administrativas> Componentes de Windows .

4) Haga doble clic en Windows Update> Configure Automatic Updates .

5) Seleccione Desactivado , y luego haga clic en Aplicar> Aceptar .

Es recomendable seleccionar Activado y Notificar para descargas y autoinstalación (ver abajo) para que siempre pueda obtener un mensaje de confirmación en lugar de una actualización automática (mientras tanto, siga atento a una actualización importante de Windows) Además, es posible que tenga que seleccionar Activado si desea actualizar su Windows a una versión superior.

6) Reinicie el equipo para que los cambios surtan efecto.

Consejo adicional: Actualice sus controladores de dispositivo a través de Driver Easy

A pesar de las molestias que nos trae Windows Update (como actualizaciones de buggies, acaparamiento de datos de Internet, apagones inoportunos para una actualización, etc.), Windows tiene su punto de vista: para mantener sus controladores actualizados para obtener el mejor rendimiento del equipo . Si no tiene el tiempo, la paciencia o las habilidades informáticas para actualizar sus controladores manualmente, puede hacerlo automáticamente con Driver Easy .

Driver Easy reconocerá automáticamente su sistema y encontrará los controladores correctos para él. No necesita saber exactamente qué sistema está ejecutándose en su ordenador, no necesita arriesgarse a descargar e instalar el controlador incorrecto, y no necesita preocuparse por cometer un error durante la instalación.

Puede actualizar sus controladores automáticamente con la versión gratuita o la versión Pro de Driver Easy. Pero con la versión Pro sólo se necesitan 2 clics:

1) Descargar e instalar Driver Easy.

2) Ejecute Driver Easy y haga clic en el botón Examinar ahora . Driver Easy escaneará su ordenador y detectará cualquier problema con los controladores.

3) Puede actualizar a la versión Pro y hacer clic en Actualizar todo para descargar e instalar automáticamente la versión correcta de TODOS los controladores que faltan o están desactualizados en su sistema.

4) Reinicie el equipo para finalizar la actualización.

Eso es todo – 3 métodos fáciles para que usted apague Windows Update en su computadora. Espero que esto ayude y siéntase libre de comentar a continuación si tiene más preguntas. ?

La entrada Cómo desactivar Windows Update en Windows 10 [FÁCIL] se publicó primero en Descargar Driver.

1. Desde un reinicio duro
2. Desde ajustes
3. Desde la pantalla de inicio de sesión

Las Distintas Opciones Avanzadas de Inicio en Windows 10

1: Desde un reinicio duro

Si no puede arrancar en Windows, elija esta opción.
No le recomendamos que preceda esta opción de reinicio duro porque reiniciar un equipo sin el soporte del sistema operativo podría resultar en pérdida de datos, instalaciones incompletas y suspensión y corrupción de cualquier proceso que se estuviera ejecutando antes del reinicio. Por favor, no intente esto cuando su ordenador se encuentre en buen estado.

1) Mantenga pulsado el botón de encendido de su ordenador hasta que se apague.

2) Presione el botón de encendido de su ordenador para encenderlo.

3) Repita los pasos 1) y 2) hasta que vea Por favor espere durante el arranque. Normalmente se necesitan tres repeticiones (más de tres repeticiones si no es la primera vez que haces esto) para que aparezca. Necesitas intentarlo hasta que puedas ver la Por favor espera a que salga .

4)>Ver opciones avanzadas de reparación .

5) Haga clic en Troubleshoot .

6)>Opciones avanzadas .

7) Haga clic en Configuración de inicio .

8) Haga clic en Reiniciar .

9) Pulse F4 , F5 , o F6 según sus propias necesidades.

2: Desde Configuración

1) Escriba settings en la barra de búsqueda, y haga clic en Settings .
.

2)>Actualización y seguridad.

3)>Recuperación y Reiniciar ahora .

4)>

5)El paso 5) a 9) en la primera opción.

3: Desde la pantalla de inicio de sesión

1) Abra el menú Inicio y haga clic en el botón Encendido . Mientras presiona la tecla Shift en su teclado, haga clic en Reiniciar.

2) El resto del procedimiento es el mismo con el paso 5) a 9) en la primera opción.

La entrada ¿Cómo arrancar en Opciones avanzadas de inicio en Windows 10 fácilmente? se publicó primero en Descargar Driver.