¿Puede ocultar la existencia de un servidor en Internet?

55

¿Podría aparecer como si un servidor no existiera? ¿Es posible que todas las solicitudes crean que el nombre de host no se pudo resolver a menos que se proporcionara una frase específica en la solicitud? ¿Hay alguna evidencia de la existencia de un servidor que el propietario del servidor no pueda ocultar? ¿Habría alguna seguridad adicional práctica?

    
pregunta Goose 30.12.2016 - 23:08
fuente

7 respuestas

79

Puede configurar su servidor para que descarte normalmente todos los paquetes entrantes y solo abra un puerto después de que reciba / vea un conjunto de paquetes que especifican una secuencia específica de puertos (esto se denomina detonación de puertos). Yo uso esta técnica con mi servidor; Normalmente no puede ver el servidor porque descarta todos los paquetes entrantes. Una vez que los paquetes de detonación de puertos llegan al servidor, el servidor aceptará los paquetes de la dirección de "detonación" pero continuará eliminando los paquetes de otras direcciones.

La seguridad es mejor con este método porque las exploraciones de IP y los intentos brutos no serán un gran problema para usted. Para piratear un servidor, debe haber reconocimiento, para saber qué servicios se están ejecutando, qué tipo de sistema operativo tiene, etc. Al negarle a un atacante esta información, es más difícil para él diseñar su ataque para su dispositivo. La debilidad de esta defensa es que si un atacante puede ver los paquetes de detonación entrantes, también puede abrir ese puerto.

    
respondido por el JShade01 30.12.2016 - 23:16
fuente
16
  

¿Podría aparecer como si no existiera un servidor ... a menos que se proporcionara una frase específica en la solicitud?

Supongo que estás hablando de HTTP (es decir, "web") y una solicitud HTTP aquí, aunque no especifiques qué tipo de solicitud realmente quieres decir. En el caso de una solicitud HTTP, tal ocultamiento no es posible porque HTTP es un protocolo de aplicación sobre TCP. Esto significa que el cliente primero debe establecer una conexión TCP que implique una respuesta del servidor antes de que el cliente incluso envíe los datos de la aplicación (es decir, la solicitud HTTP) y, por lo tanto, la existencia del servidor HTTP se revela independientemente de la solicitud.

Esto puede ser diferente con otros protocolos. Por ejemplo, el DNS (resolver nombres de host a direcciones IP) generalmente se maneja en UDP, que es sin conexión, a diferencia de TCP. Esto significa que la solicitud con la carga útil es el primer paquete enviado por el cliente. Por lo tanto, se podría crear un servidor con UDP que solo responde si la solicitud de DNS es para un dominio específico y elimina cualquier otra solicitud. De esta manera, el servidor revelaría su existencia solo si se enviaba la solicitud adecuada. Se pueden hacer cosas similares con SIP (telefonía a través de Internet), que generalmente también se realiza a través de UDP.

  

¿Es posible que todas las solicitudes crean que el nombre de host no se pudo resolver ...?

La resolución de un nombre de host a una dirección IP se realiza incluso antes de enviar la solicitud al servidor en esta dirección IP y, por lo general, el propio servidor ni siquiera está involucrado en este proceso de resolución de DNS. Esto significa que, incluso con los protocolos sin conexión, el cliente no obtiene la información de que el nombre no se puede resolver si la solicitud era incorrecta. Lo máximo que obtendrá el cliente es la información de que el destino no responde, lo que podría interpretarse de que no hay ningún servidor configurado en esta dirección IP o que el servidor está inactivo, protegido por un firewall o simplemente eliminando paquetes inesperados.

    
respondido por el Steffen Ullrich 30.12.2016 - 23:30
fuente
4
  

¿Podría aparecer como si un servidor no existiera?

Sí, aunque esto no es trivial. Depende del comportamiento de su ISP cuando no existe un servidor. Algunos ISP configuran sus enrutadores para eliminar paquetes cuando la IP a la que intenta llegar un paquete no existe, otros envían un mensaje de rechazo de paquetes al remitente. Además, algunos enrutadores tienen un comportamiento de adaptación y cambian su comportamiento si cree que puede estar bajo ataque. Algunos ISP pueden discriminar según el lugar de origen de los paquetes de sondeo (por ejemplo, los paquetes provenientes de países / ISP que suelen alojar a clientes malintencionados pueden recibir un trato más hostil que aquellos con buenas prácticas de red).

Si configura su servidor para que simplemente descarte todos los paquetes no reconocidos, eso puede ser una prueba de la existencia del servidor si su ISP normalmente envía un mensaje de rechazo. Si el enrutador de su ISP cambia su comportamiento de manera adaptativa durante un período de ataque activo, y su servidor no se mantiene al tanto de lo que está haciendo el ISP, entonces eso puede convertirse en una evidencia del servidor. Además, su ISP puede tener su propio ISP de backhaul, que puede tener su propio conjunto de comportamiento.

  

¿Es posible que todas las solicitudes crean que no se pudo resolver el nombre de host?

Sí, simplemente no registre sus nombres de host en el sistema DNS público. Los nombres de host en el sistema DNS público son registros públicos intencionalmente. Si está registrado en el DNS público, cualquier persona puede consultar los registros de DNS para buscar la dirección IP relacionada con el nombre de host. Sin embargo, puede definir nombres de host que solo sean reconocidos por sus máquinas (es decir, usar el archivo de hosts) o ejecutar su propio servidor DNS privado.

  

¿Existe alguna evidencia de la existencia de un servidor que el propietario del servidor no pueda ocultar?

Cualquier dirección IP que se pueda enrutar públicamente tiene un registro de propiedad pública que se puede consultar mediante la herramienta whois para averiguar quién es su proveedor de servicios de Internet. Su ISP (o un adversario que comprometa o trabaje con su ISP) puede monitorear cualquier paquete que pase por su red y puede ver esos paquetes entrantes sin un paquete saliente anterior como evidencia de un servidor.

  

¿Habría alguna seguridad adicional práctica?

Si tiene malas prácticas de seguridad en primer lugar, ser invisible puede rechazar de manera efectiva a muchos robots simples y atacantes poco sofisticados. Los atacantes más sofisticados pueden encontrar formas de evitar la invisibilidad. Si tiene buenas prácticas de seguridad, utilizando autenticación y cifrado sólidos, entonces estar oculto no importa mucho en términos de seguridad.

Probablemente el mejor lugar para ocultar una hoja es ocultarla en un árbol / bosque. Si ejecuta un servidor conocido públicamente y encripta todo el tráfico al servidor (solo HTTPS), es muy poco lo que pueden hacer los forasteros para distinguir entre el tráfico al sitio frontal y el tráfico al sitio oculto. Lo único que debe tener en cuenta es que TLS pierde el nombre de host de destino en el encabezado de SNI. Siempre que falsifique el encabezado de su SNI o use el nombre de host del servidor frontal, su servidor oculto permanecerá oculto.

    
respondido por el Lie Ryan 31.12.2016 - 17:07
fuente
3

Yo uso fwknop (" F ire W todos KN ock OP erator ") a los puertos ocultos:

  

Con fwknop implementado, cualquiera que use nmap para buscar SSHD ni siquiera puede   Dile que está escuchando, no importa si quieren correr.   un cracker de contraseñas contra SSHD o incluso si tienen un exploit de 0 días.

Incluso funciona para sigilo ssh ports detrás de nat .

Si desea restringir el acceso a un solo ip , puede lograr el mismo efecto ejecutando iptables con una política de denegación predeterminada ( iptables -P INPUT DROP ) & agregando reglas de permiso para direcciones src ip específicas:

iptables -A INPUT -i eth0 -p tcp -s 1.2.3.4 --dport 80 -j ACCEPT

    
respondido por el Stuart Cardall 31.12.2016 - 21:34
fuente
2
  • primera pregunta: algo pero no realmente. Puede rechazar todos los paquetes entrantes, pero los que le gustan pero la conexión exitosa son 'visibles' (vea el tercer punto)
  • segunda pregunta: de ninguna manera. La resolución de DNS no controla la cadena de consulta de la solicitud, por lo que no puede usarla como filtro
  • tercera pregunta: sí, el tráfico desde y hacia el servidor no se puede ocultar a los enrutadores y / o los servidores proxy entre el origen y el destino, por lo que se conoce la existencia de ese servidor y no se puede ocultar (si no está en una red oscura)
  • Cuarta pregunta: tal vez se pueda usar como una capa adicional, pero de todos modos se deben aplicar la sabiduría y las medidas convencionales.
respondido por el Paolo 31.12.2016 - 19:27
fuente
2

Hay otra forma de tener un servidor oculto de Internet, y esta es el uso de un sitio oculto de TOR. Estos servidores están diseñados solo para estar disponibles a través de la red TOR, y solo se pueden direccionar con una dirección TOR .onion.

En el pasado, este tipo de servidores ocultos se han utilizado por diversos motivos, como sitios de anti-censura, correo electrónico anónimo y, en algunos casos (como The Silk Road), los sitios ocultos se utilizan para vender / comprar artículos ilegales.

Si está interesado, consulte aquí: enlace

    
respondido por el Nik Roby 01.01.2017 - 06:43
fuente
1

Como han señalado otros, esta técnica se llama "detonación de puertos".

Moxie Marlinspike ha creado una herramienta llamada "knockknock" que hace precisamente esto.

Creo que la explicación sobre cómo funciona la herramienta es bastante buena para entender el concepto. Citando desde su página:

  
  • Los servidores ejecutan la aplicación de python 'knockknock-daemon', y los clientes abren puertos en esos servidores ejecutando la aplicación de python 'knockknock'
  •   
  • 'knockknock-daemon' simplemente sigue kern.log. No se enlaza a ningún socket, carga libpcap e inspecciona cada paquete, ni envía nada a   la red en absoluto.

  •   
  • Cuando desea abrir un puerto desde un cliente, ejecuta 'knockknock', que envía un único paquete SYN al servidor. La IP y TCP del paquete.   los encabezados están codificados para representar una solicitud cifrada segura IND-CCA   para abrir un puerto especificado desde la dirección IP de origen.

  •   
  • Los campos de este paquete se registran en kern.log y son procesados por 'knockknock-daemon', que los valida.
  •   
  • Se conecta desde el cliente al puerto ahora abierto en el servidor.
  •   
  • El puerto se cierra detrás de usted y no permite nuevas conexiones.
  •   
    
respondido por el Acapulco 31.12.2016 - 21:47
fuente

Lea otras preguntas en las etiquetas