Servidores UNIX: posibles intrusiones o ataques que no utilizan ninguno de los sockets de escucha abierta

Independientemente de si esto debería aplicarse específicamente a Unix, yo diría que es no seguro asumir que no hay acceso solo porque no hay puertos abiertos.

Para más información, se escucha ICMP , incluso si no hay puertos TCP o UDP disponibles.
Y antes de decir, "¡Pero ICMP es solo un simple Ping ! ¡Es irrelevante atacar con eso!" mira esto:

• Ping of Death
• Ataque de los pitufos
• y, por supuesto, Ping flood

Y si bien todos estos son bastante históricos (con la excepción del último), no descartaría futuros ataques adicionales.

Además, existen los ataques indirectos, como los que atacan la infraestructura a la que el sistema cerrado podría acceder, por ejemplo. Envenenamiento de DNS ...

  

¿Qué tipo de ataques existen que no usan TCP abierto o puertos UDP abiertos?

Esto es una pregunta demasiado general. Estoy respondiendo esto muy literalmente, no para ser un imbécil, pero porque en seguridad es mejor no asumir nada. Aquí hay algunas clases de ataques que no usan puertos TCP o UDP abiertos:

• Ingeniería social: haga que alguien se conecte desde la máquina a un sitio de ataque (o adjunte una unidad de disco USB o medios incorrectos)
• Acceso físico, keyloggers, etc.
• Un ataque a nivel de IP (vulnerabilidades de pila de IP)
• NTP: normalmente está activado de forma predeterminada y es posible que no esté libre de errores
• DHCP: ¿dhcp está desactivado? un atacante en la red local podría enviar una imagen de arranque PXE a su tarjeta Ethernet y cargar su sistema operativo.

  

¿Es seguro asumir que no hay puertos abiertos significa que no hay acceso remoto?

• Las descargas no autorizadas que se ejecutan podrían ser de gran utilidad (incluido el envío de ping y la obtención de datos de control mediante la respuesta de ping)
• Los administradores de paquetes podrían eliminar el software troyano que configura el malware de llamada de salida
• acceso Bluetooth

Creo que su verdadera pregunta debería ser: "¿Qué tipo de explotaciones remotas se pueden usar para rootear mi máquina si no tiene puertos TCP o UDP abiertos?"

Ataques puede significar muchas cosas para las personas, incluido Van Eck Phreaking.

El problema fundamental de estas clases de ataques no se encuentra en los protocolos TCP o UDP, sino en el requisito de que las aplicaciones procesen datos de una fuente no confiable (o de menos confianza) y un diseño y / o control de calidad defectuosos dentro de dichas aplicaciones. .

Si su servidor está ejecutando aplicaciones que procesan la entrada de una fuente que no tiene el mismo nivel de confianza que su servidor y usted no tiene un proceso de control de calidad establecido para dichas aplicaciones, es vulnerable.

Por ejemplo, aunque se han presentado varios desbordamientos de búfer a través de comunicaciones de autenticación previa con aplicaciones que escuchan en los puertos TCP y UDP, se pueden presentar con la misma facilidad en rutinas que leen datos de un recurso de red que no implica una conexión de escucha, o incluso en funciones que leen desde recursos locales como archivos y bases de datos, en muchos de estos casos el programador no tiene una mentalidad hostil a los datos que tienen con la programación de socket. Según mi experiencia, aquí es donde se encuentra la fruta de baja altura.

En mi opinión, está buscando un unicornio, y la única manera de obtener el resultado deseado actual es dejar su servidor en una habitación limpia y cerrada sin ninguna conexión de red. El objetivo principal de un servidor es la funcionalidad, no la seguridad, y los compromisos deben hacerse con respecto a la entrada no confiable. La forma de mitigar este riesgo, al tiempo que ofrece funcionalidad, es habilitar solo la funcionalidad necesaria y compensar los servicios requeridos por los procesos de control de calidad / auditoría, como la revisión de códigos y las pruebas de penetración, los procesos operativos como el monitoreo y la respuesta a incidentes, y la infraestructura para evitar o detectar entradas y conectividad no deseadas.

Incluso si su sistema operativo es completamente seguro, su hardware puede ser vulnerable. Muchas tarjetas de red responden a varios protocolos de administración remota ( Wake-on-LAN , Alert-on-LAN , ASF ,…).

En la práctica, una vulnerabilidad real tiene muchos requisitos:

• al menos una de estas funciones debe ser compatible;
• la función debe estar habilitada al menos en algún nivel (por lo general, está desactivada como se envió);
• el sistema operativo no debe haber desactivado la función en el momento del inicio (este es un caso en el que una computadora es más vulnerable cuando está apagada);
• el atacante debe estar en el lado derecho de cualquier firewall que se respete a sí mismo (la mayoría de estas funciones usan UDP);
• y, por supuesto, el firmware debe ser vulnerable (ejemplo: CVE , Preguntas frecuentes ).

Si uno permite DNS, uno permite IP sobre DNS .

Si puede asegurarse de que el hardware de su red no tenga puertos abiertos para ningún protocolo, entonces no podrá recibir paquetes. Esto hará que sea muy poco probable que sea atacado a través de la red. Sin embargo, si desea cerrar todos los puertos, Recomendaría desconectar el cable de red porque puedo pensar en un problema potencial:

• puede tener un rootkit que informa sobre puertos cerrados cuando en la actualidad hay uno abierto

No es absolutamente seguro. Este es un ejemplo simple: un usuario de la máquina navega por la web, visita sitios web incompletos y hace clic en varios enlaces. Esto puede hacer que la seguridad de la máquina se vea comprometida fácilmente (por ejemplo, mediante descargas no autorizadas o por ingeniería social para engañar al usuario para que instale malware). Esto es cierto incluso si el sistema operativo no tiene ningún puerto abierto en el que esté escuchando.