Protegemos o servidor remoto no Windows, como podemos


O tópico de segurança do servidor Windows foi levantado mais de uma vez, inclusive neste blog. No entanto, gostaria mais uma vez de refrescar a memória dos antigos métodos de defesa e falar de novos pouco conhecidos. Obviamente, usaremos as ferramentas internas ao máximo.


Portanto, suponha que tenhamos uma pequena empresa que aluga um servidor de terminal em um data center remoto.


Ao projetar qualquer proteção, você deve começar com um modelo de ameaça - de quem ou o que, de fato, defenderemos. Em nossa configuração típica, construirei uma defesa contra hackers externos, contra usuários incompetentes (e talvez um pouco maliciosos). Vamos começar com o perímetro externo da defesa - o firewall.


Atrás de você como uma parede de fogo


Nos dias do Windows 2003, o firewall interno era uma visão miserável e, se era impossível usar ferramentas de terceiros, era necessário usar o IPSec. Um exemplo dessa configuração é discutido, por exemplo, no material Secure Windows Servers usando o IPSec Firewall .


Agora, com o advento do WFP ( Windows Filtering Platform ), as coisas se tornaram melhores. Em princípio, provavelmente todo administrador de sistema do Windows encontrou esse firewall de qualquer maneira, portanto, não deve ser difícil configurar o acesso remoto ao servidor apenas a partir de determinados IPs. Vou prestar atenção a alguns "chips", que raramente são usados.


Por padrão, o firewall bloqueia todas as conexões de entrada, exceto as explicitamente permitidas, mas a saída permite todas as conexões, exceto as explicitamente proibidas. Esta política pode ser alterada abrindo o gerenciamento de firewall através do wf.msc e selecionando "Propriedades".



Configurações de firewall.


Agora, se queremos impedir que os usuários do servidor de terminal acessem a Internet a partir desse servidor, teremos sucesso.


Vale ressaltar que, ao configurar regras de acesso ao servidor (conexões de entrada), a criação explícita de regras para o tráfego de saída não é necessária. Em termos de iptables, estabelecidos e relacionados são sempre permitidos.

Para conhecedores da linha de comando, você pode configurar o firewall no contexto do netsh advfirewall. Você pode ler sobre os comandos no artigo " Firewall do Windows 7 com segurança avançada " , acrescentarei que o bloqueio de conexões de entrada e saída é ativado pelo comando:


netsh advfirewall set currentprofile firewallpolicy blockinbound,blockoutbound 

Outra característica do firewall do Windows é que qualquer programa ou configuração altera suas regras sem notificação. Por exemplo, você desativou todas as regras do nosso avô, uma segunda apareceu nas proximidades, você criou uma rede local entre eles, configurou o acesso compartilhado e ... de repente, o smb foi ativado para todos e tudo, com todas as conseqüências resultantes.


Existem basicamente duas saídas e meia (lembre-se, estamos falando apenas de ferramentas internas): verifique regularmente se as regras foram alteradas e use o bom IPSec antigo ou, quanto a mim, a opção mais razoável é configurar o firewall com a Diretiva de Grupo. As configurações são feitas em Configuração do computador - Configuração do Windows - Configurações de segurança - Monitor do Windows Defender Firewall em Segurança avançada.



Configurando uma política de grupo de firewall.


Além disso, usando o firewall do Windows, você pode implementar um fail2ban simples. É o suficiente para habilitar a auditoria de tentativas de logon com falha e, se várias falhas consecutivas, bloquear o IP de origem. Você pode usar scripts auto-escritos ou ferramentas prontas, sobre as quais escrevi no artigo " Como fornecer criptografadores para afundar uma empresa ".


Se o firewall interno não for suficiente e você desejar usar algo mais sério, poderá instalar software de terceiros. É uma pena que a maioria das soluções conhecidas para o Windows Server seja paga. Outra opção seria colocar um roteador na frente do servidor. É claro que essa instalação é adequada se usarmos o colocation, e não alugarmos um servidor em algum lugar distante, distante do exterior. Se o data center estrangeiro for a nossa escolha, você poderá usar a virtualização - por exemplo, o Hyper-V embutido - e instalar o familiar GNU \ Linux ou FreeBSD na máquina virtual.


Surge a pergunta: como fazer com que a máquina virtual tenha acesso direto à Internet, mas o servidor não? Além disso, o endereço MAC do servidor não brilha no hoster e, portanto, não requer a compra de outro endereço IP.


Cuidado É melhor executar outras ações através do IP-KVM!

Para isso, a máquina virtual deve estar equipada com dois adaptadores de rede. Uma é a conexão direta à Internet, pois faremos um comutador virtual do tipo “externo” e desmarcaremos a caixa que permite ao sistema operacional interagir com esse comutador. Com essa marca de seleção, privamos o servidor de acesso direto à Internet (é melhor configurar o firewall virtual antecipadamente) e seu MAC não acenderá o host.



Configure um comutador virtual externo.


Outra opção virtual deve ser feita do tipo "interno" para interação entre a máquina virtual e o servidor. Ele já precisa configurar o endereçamento local. Isso criará um roteador virtual que fica na frente do servidor e o protege.


Ao mesmo tempo, você pode configurar sua VPN favorita para o escritório ou funcionários remotos nesta máquina virtual sem se preocupar com a função de "Roteamento e acesso remoto" ou com o IPSec interno, conforme descrito no artigo " Como ocultei a base 1C na Alemanha ". O principal é não se esqueça de verificar a inicialização desta máquina virtual na inicialização do sistema.


Você pode conectar-se a esse servidor usando o RDP comum ou usar clientes HTML5 com autenticação de dois fatores. Vale a pena, em caso de força bruta, cuidar das soluções fail2ban e bloquear a conta por algum tempo com várias tentativas malsucedidas de autorizar em sequência.


Lá fora, protegemos mais ou menos o servidor, vamos para a proteção interna.


Proteção interna: pare e não solte


É claro que, para proteger o servidor por dentro, eu realmente quero colocar algum tipo de antivírus - você nunca sabe o que os usuários do servidor acumularão ou bombearão da Internet. Mas, na prática, o antivírus no servidor pode fazer mais mal do que bem. Portanto, eu normalmente uso mecanismos de bloqueio de lançamento de software não incluídos na lista de permissões - em particular, o mecanismo SRP (políticas de restrição de software), que também mencionei no artigo “ Como habilitar os criptografadores para inundar uma empresa ”.


Vou me debruçar com mais detalhes sobre uma armadilha, que geralmente esquecemos quando você ativa o SRP com configurações padrão, quando tudo está bloqueado, exceto as pastas Windows e Arquivos de Programas. Na verdade, isso filtra quase todos os malwares. Mas isso realmente não funciona com a maldade dos funcionários, porque nas pastas do sistema existem subpastas com o direito de criar objetos pelos usuários. Por exemplo, você pode olhar para a pasta C: \ Windows \ Temp.



Permissões para a pasta que está na lista de permissões.


E essa pasta não está sozinha. Obviamente, você pode auditar as pastas do sistema ou confiar nas pessoas que já fizeram isso. Por exemplo, um especialista em Stefan Kanthak em seu blog (existe um vírus de teste EICAR por referência, um antivírus pode funcionar) caminha de maneira bastante agressiva pelos métodos de proteção antivírus e Windows e, ao mesmo tempo, oferece um pacote de configurações SRP já montado que também bloqueia essas pastas suspeitas. Mediante solicitação, o autor fornece um programa para converter essas configurações do registro em arquivos de políticas locais.


Se você preferir usar o mecanismo AppLocker com configurações mais flexíveis, a solução AaronLocker poderá ajudá- lo .


Os editores não recomendam o uso e a instalação de scripts e outros programas da Internet sem antes estudá-los.

Se o AppLocker apareceu por um longo tempo e a idade do SRP excedeu 15 anos, uma alternativa relativamente nova é o WDAC (Windows Defender Application Control). De fato, desde o Security Essentials, o “antivírus” incorporado adquiriu muitos recursos interessantes. Por exemplo, o WDAC é o módulo responsável pelas políticas de acesso para aplicativos e bibliotecas. Anteriormente, fazia parte do Device Guard (protegendo um computador, incluindo o uso de tecnologias de virtualização), e um pouco sobre sua configuração foi descrito no artigo " O princípio do Modo S no Windows 10 e a configuração do Device Guard com suas próprias mãos ". Mais detalhes sobre todas as sutilezas podem ser encontrados na documentação oficial, mas posso adicionar alguns inconvenientes que o distinguem das soluções clássicas como SRP e AppLocker:


  • Não há configuração gráfica, em todos os cmdlets do PowerShell.
  • Não há configurações na fatia do usuário, apenas para o computador.
  • A configuração é feita de maneira incomum - um arquivo xml é preparado, que é convertido em binário e distribuído para os computadores.

Mas é possível configurar o aplicativo em uma fatia: por exemplo, se você deseja conceder ao cmd.exe acesso ao seu script e não a um vírus de terceiros, isso pode ser implementado. Além disso, a política pode ser aplicada antes de inicializar o sistema usando UEFI.



Bloqueio do Chrome via WDAC.


Em geral, devido à configuração dolorosa, a impressão era que o WDAC não estava mais posicionado sozinho para gerenciar computadores, mas como uma ferramenta que permite a integração com sistemas MDM centralizados como o Microsoft Intune . Mas, ao mesmo tempo, o desenvolvimento do bom e velho SRP foi descontinuado no Windows 10 1803.


Se falamos sobre o Windows Defender, você não pode deixar de mencionar o Credential Guard e o Remote Credential Guard.


A primeira ferramenta novamente usa a virtualização, iniciando o componente LSA (Autoridade de Segurança Local) em um processo isolado do sistema operacional, o que complica bastante o processo de roubo de hashes de senhas e tíquetes Kerberos. Leia mais sobre a tecnologia na documentação oficial. Para que o processador funcione, ele deve oferecer suporte à virtualização e o sistema deve ter a Inicialização Segura ativada e o módulo TPM para vincular credenciais ao equipamento. Você pode habilitar o Credential Guard por meio da política de grupo Configuração do Computador - Modelos Administrativos - Sistema - Device Guard - Habilitar segurança baseada em virtualização.



Ativando o Credential Guard.


A segunda ferramenta serve para proteger as credenciais transmitidas (especialmente admin!) Para conexão remota, por exemplo, através do mesmo RDP. Anteriormente, o mecanismo do Modo de Administração Restrito era proposto para esses fins, mas limitava a conexão a apenas um servidor. Após conectar-se ao servidor, era impossível usar apenas os recursos de rede, os direitos de administrador eram aplicados a apenas um servidor na conta Sistema Local.


O Remote Credential Guard permite transferir credenciais da máquina local para um servidor remoto sem inserir uma senha explícita, que, além da segurança avançada, também fornecerá a conveniência de se conectar aos servidores (SSO). Você pode ler mais na documentação , mas acrescentarei que, para que o mecanismo funcione, basta ativar o suporte no servidor - por exemplo, através do registro com o comando:


 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 

E conecte-se ao servidor com o comando:


 mstsc.exe /remoteGuard 

Agora as credenciais estão seguras e o servidor está bastante seguro. É verdade que no material eu não toquei conscientemente em questões de proteção contra um host malicioso, mas aqui tudo se resume a uma coisa em geral - à criptografia de disco.

Source: https://habr.com/ru/post/pt474088/


All Articles