servidor SFTP dmz vs confiável

Question

Estamos tentando descartar nossa solução existente e usar um servidor SFTP mais simples (muito mais barato) para permitir trocas de arquivos com os clientes. Nossa rede consiste em redes confiáveis e DMZ. O produto atual tem essa cobertura, hospedando um servidor em ambos os lados e cuidando da própria ponte. Estamos procurando mudar para o WinSSHD, mas não temos certeza sobre o posicionamento do servidor, DMZ vs. Trusted. Estamos no espaço financeiro e procurando orientação sobre as melhores práticas, ou talvez boas alternativas para atender às nossas necessidades.

Parece que devemos colocá-lo na DMZ, mas precisamos descobrir como mover os arquivos para o Trusted.

    

Answer 1

Se for um servidor publicamente acessível, você deve colocá-lo na DMZ - é sobre isso que trata o zoneamento. Configurar um servidor com duas interfaces - uma na DMZ, uma na rede confiável - apenas contorna a própria ideia de uma DMZ separada, tornando-a totalmente supérflua.

Com o servidor na DMZ, em geral você deve

1. decida se os dados inseridos nele geralmente são seguros para serem copiados e usados na rede "Confiável"
2. se assim for, permitir um mecanismo de transferência de dados entre o servidor e a rede confiável

Você pode implementar facilmente 2. usando apenas o mesmo protocolo de seus clientes - conecte-se via SFTP e retire os dados. Dessa forma, você pouparia as dores de cabeça de uma avaliação de risco para um conjunto de protocolos adicionais.

Editar: vou tentar usar o estilo wiki e incorporar suas objeções a essa resposta e comentá-las:

The data now lives in the DMZ, I would have to seek an answer for this internally to see if it's permissible. The current solution doesn't physically store the data in the DMZ, it just has a DMZ interface.

É claro que cabe a qualquer um projetar sua política de segurança para equilibrar o risco de roubo de dados para dados "residentes" na DMZ contra um serviço acessível ao público virtualmente hospedado em sua rede confiável. Na maioria dos casos, você iria com o anterior, minimizando o risco de roubo de dados, mantendo os dados no DMZ por um tempo limitado.

Outra opção seria implementar uma solução de proxy para SFTP na sua DMZ e encaminhar as conexões para a sua "confiança "servidor - mas isso teria uma superfície de ataque ainda diferente, então, novamente, acaba equilibrando os riscos.

how is that more secure than simply hosting the SFTP in the trusted and allowing for direct connections?

Normalmente, um proxy é configurado para ter uma troca de protocolo "bem-comportada". Isso atenua uma classe inteira de vetores de ataque com base na exploração de pontos fracos na implementação do protocolo no lado do servidor (por exemplo, estouro de buffer). Algumas configurações de proxy podem permitir que você especifique restrições sobre o que um usuário pode ou não fazer - um recurso usado para reduzir a superfície de ataque, permitindo apenas operações necessárias.

Mas um proxy é apenas um pedaço de código propenso a erros, assim como qualquer outro código - ele terá seus próprios vetores de ataque. A modelagem de ameaças e a avaliação de risco para uma configuração de "porta de água" com dois servidores e pesquisas é mais fácil de avaliar.

I need the process to be automated, so I would have to use a file watching service of sorts to watch for incoming files in the DMZ, then forwarding to yet another SFTP server in the Trusted.

Sim, isso seria razoável.

Now I really have to administer 2 SFTP servers on each side of the fence.

Correto, mas cada um deles pode ser um limite de segurança em si mesmo - isso é provavelmente o que será necessário se você estiver muito preocupado com a segurança dos dados armazenados lá de qualquer maneira.

    

Answer 2

Um par de pensamentos aqui para ir junto com o que syneticon-dj está dizendo:

EDIT: adicionado ponto de Nate: curva de aprendizado do Linux / troca do Windows.

• Se você está confortável com o Linux e / ou está disposto a investir algum tempo em aprendê-lo para este aplicativo, eu desestimulo o uso do Windows para algo que seja inteiramente adequado para sistemas operacionais * NIX como o Linux. ou FreeBSD. Eu não estou derrubando o WinSSHD (recentemente tomei conhecimento disso e acho que é um ótimo produto para encapsulamento de RDP sobre SSH, entre outras coisas), mas é só que * NIX e OpenSSH funcionam tão bem , por que se preocupar com o Windows e o custo do licenciamento? * O NIX é indiscutivelmente mais seguro, especialmente com algo como uma instalação mínima Debian, que é um bom equilíbrio de facilidade de uso (gerenciamento de pacotes apt) e pequeno espaço ocupado.

• Mantenha seu servidor na DMZ. Você não precisa de dois servidores SFTP, você precisa de um servidor SFTP e um cliente SFTP em sua rede confiável que possa extrair seus arquivos do seu servidor DMZ SFTP, conforme exigido pelos requisitos de negócios.

  Isso poderia ser simplesmente um cronjob do rsync que periodicamente faz uma sincronização "pull" a cada 15 minutos com o argumento --delete-after , de modo que nenhum dado seja deixado no servidor DMZ, uma vez baixado para o seu host confiável. Ajustado ao seu gosto, isso pode ser tão robusto quanto necessário, e é um padrão bastante comum (funciona para 99% das implementações POP3 existentes). Você pode adicionar algumas verificações de integridade e lógica comercial (validar os dados antes de excluí-los) e pode ser otimizado com um padrão orientado a eventos (somente buscar quando houver novos dados), mas o rsync é muito eficiente por si próprio. fuja com um método simples de força bruta como este, especialmente se este for um processo manual para começar.

  O bom é que além de algumas regras de saída (saída) para permitir que seu host cliente SFTP confiável se conecte à sua rede DMZ, se o seu servidor DMZ SFTP estiver comprometido, não terá acesso direto a nada em sua rede confiável.