Limitación de los privilegios de FTP en Windows Server

3

Actualmente tengo un servidor de Windows 2012 que actúa como un servidor web que ejecuta IIS. Estoy usando Filezilla para alojar un servidor FTP para permitir que algunos clientes tengan acceso FTP a sus propios sitios web.

He configurado la cuenta de FTP con facilidad y pueden acceder a la carpeta de su sitio web. Sin embargo, realmente deseo explorar esto más a fondo y hacerlo realmente seguro. Por el momento no hay nada que les impida cargar el archivo .exe y ejecutarlo en el sitio web para piratear mi servidor.

¿Cómo puedo limitar los archivos que cargan a solo unas pocas extensiones deseadas como PHP, JS y desactivar el cambio de nombre de las entidades (para evitar que cambien la extensión a .exe como ejemplo)? Además, ¿hay otras medidas de seguridad que pueda tomar?

Por favor, dime si me he perdido alguna información. No responda con comentarios como "Si no confía en ellos, no permita el acceso", ya que está fuera de tema

    
pregunta Jimmy Jane 17.02.2016 - 20:20
fuente

3 respuestas

1

Lo primero es lo primero: FTP es un protocolo obsoleto según IETF. Ha sido desaprobado en favor de protocolos seguros como SFTP. Recomiendo usar solo SFTP y no usar FTP, ya que los comandos FTP y los nombres de usuario / contraseñas se envían en texto sin formato. Cualquier persona que supervise la red del usuario (por ejemplo, una cafetería wifi) podría obtener su contraseña y acceder fácilmente a su cuenta.

Dicho esto, el servidor FileZilla tiene una función llamada "Filename Filters" pero esto no se aplica en el servidor y solo se puede usar desde el cliente. Por lo tanto, no hay forma en el servidor de FileZilla de acuerdo con la documentación que veo para hacer esto. Dicho esto, los archivos maliciosos pueden ser fácilmente archivos javascript, o simplemente no tienen una extensión o enmascaramiento como una extensión legítima como .html. Si se ejecuta un exploit para invocar de alguna manera el código en esos archivos (por ejemplo, ejecutarse a través de otro ejecutable, como un error en el servidor de filezilla, por lo que ostensiblemente filezilla.exe está ejecutando este código), no importa cuál sea la extensión del archivo. fue, ya que ese código será ejecutado. Por lo tanto, la falta de soporte del servidor para este filtrado no es una gran pérdida de seguridad.

Por lo tanto, la limitación de las extensiones de nombre de archivo puede proporcionar un aumento menor en la seguridad; pero definitivamente no es una solución para todos, ni evitaría que un atacante experto explote su sistema, por lo tanto, probablemente la razón por la que el soporte no está implementado en el servidor FileZilla. En su lugar, piense en esto como una pequeña parte de un programa integral de "mejores prácticas" para limitar el acceso, incluido el uso de protocolos seguros como SFTP, el refuerzo de la seguridad del servidor (por ejemplo, estándares de fortalecimiento de la CEI), la instalación de actualizaciones periódicas, la protección antivirus, los cortafuegos y / o detección de intrusos, actualizando regularmente el servidor FileZilla, etcétera.

    
respondido por el Herringbone Cat 17.02.2016 - 20:38
fuente
1

En primer lugar, recomendaría encarecidamente bloquear FTP y solo permitir FTPS / FTPES (FTP sobre SSL / TLS implícito / explícito). SFTP sería aún mejor, más amigable con el cortafuegos, secreto directo inherente ... pero FileZilla Server no es compatible con SFTP.

Dicho esto, recomendaría usar un software de servidor que te permita hacer dos cosas esenciales:

  1. Impedir cambio de nombre de archivo
  2. Ejecute su propio script al ocurrir ciertos eventos (como la carga de archivos)

Mira el siguiente script, por ejemplo:

var
  FirstBytes, PEBytes : string;
begin
  FirstBytes := FileReadAsHex(ObjectName, 0, 2);
  PEBytes := FileReadAsHex(ObjectName, 256, 4);
  if ((FirstBytes = '4D5A') and (PEBytes = '50450000')) then
  begin
    // It's an EXE, delete it!
    FileDelete(ObjectName);
  end;
end.

El script simple anterior puede identificar un Windows EXE leyendo dos ubicaciones particulares de 2 bytes en su encabezado. Si su servidor FTP (S) puede ejecutar ese script cada vez que se carga un archivo, su servidor identificará todos los EXE, incluidos los cargados con una extensión falsa , y los eliminará de inmediato cuando se carguen. .

Lamentablemente, el servidor FileZilla no tiene la capacidad de ejecutar scripts automáticamente al cargar el archivo (o en caso de que ocurra cualquier evento, básicamente no tiene esa funcionalidad) pero hay otros servidores que pueden hacerlo. Descargo de responsabilidad: soy el autor de uno de estos servidores.

Referencias: enlace

    
respondido por el FjodrSo 20.05.2016 - 18:37
fuente
1

En mi humilde opinión estás manejando el lado equivocado de la palanca. Es un problema de seguridad, por lo que la primera pregunta es "¿cuál es la amenaza aquí?" . Si lo he entendido correctamente, desea proteger su sistema de una carga ofensiva.

Debes configurar diferentes líneas de defensa aquí:

  • asegure el protocolo de autenticación para evitar que los piratas informáticos abusen fácilmente de cuentas legítimas. Otras respuestas explicaron que el FTPS (FTP sobre SSL o TLS) es más seguro porque las credenciales nunca se envían en texto sin formato. IPSEC (sobre IPv6) es otra opción equivalente en un punto de vista de seguridad
  • intente limitar las posibilidades del servidor para aceptar solo las extensiones conocidas. Bueno, debes hacerlo si tu servidor lo permite, pero desafortunadamente FileZilla no tiene muchas funciones en ese punto. Tal vez podría echar un vistazo a ProFTPD , que es mucho más rico pero requiere Cygwin. De todos modos, los archivos PHP pueden dañar a un servidor porque se ejecutan bajo la cuenta del servidor con todos los privilegios del servidor. Ok, el interpretador de PHP puede configurarse para limitar los riesgos, pero las fallas solían ser comunes en esa parte, Así que en mi humilde opinión esta parte no es la más robusta
  • limita las posibilidades del propio servidor. No sé específicamente IIS, pero las buenas prácticas recomiendan que un servidor HTTP se ejecute bajo una cuenta dedicada no administrativa. Por lo tanto, debe asegurarse de que incluso si el servidor ejecutara un comando arbitrario, el daño debería limitarse a la zona del servidor. Una vez más, no uso Windows para alojar servidores HTTP, así que no puedo decir mucho más.

En mi humilde opinión, las líneas más importantes aquí son 1 y 3. 3 protegen el sistema host y 1 permite saber quién es responsable de qué. Junto con los procedimientos de copia de seguridad y el análisis de registro correctos, deberían ser más eficientes que 2.

Dicho esto, mi consejo es que sería mucho más sencillo construir un servidor HTTP que permita el acceso FTPS o SFTP bajo un sistema tipo Unix como Linux o xxxBSD. Encontrará servidores mucho más configurables allí, y probablemente más referencias en la WEB (o aquí ...) sobre cómo configurarlos de forma segura. Por supuesto, si se requiere IIS, esto ya no es una opción, al menos para la parte HTTP.

    
respondido por el Serge Ballesta 17.03.2017 - 10:15
fuente

Lea otras preguntas en las etiquetas