Como parar ataques de força bruta no Terminal Server (Win2008R2)?

23

Estou mais familiarizado com as ferramentas do Linux para interromper ataques de força bruta, por isso estou tendo problemas para encontrar ferramentas adequadas para o Windows. Estou executando um Windows Server 2008 R2 com o Terminal Server e gostaria de bloquear um IP após repetidas tentativas de login via RDP. Alguma dica?

windows-server-2008  terminal-server  brute-force-attacks 
— onik
fonte
3
Você realmente precisa lidar com isso no seu servidor Windows? Você já pensou em limitar a taxa no seu dispositivo de borda (firewall / roteador)?
— Zoredache
2
A caixa do Windows é um VPS executado por uma empresa de hospedagem, portanto, não tenho acesso aos dispositivos de rede.
— onik 02/02
Você pode configurar um evento de agendamento de tarefas em logons com falha para disparar um script PS; o PS Svript precisaria contar o número de vezes que um IP tentou e bloqueá-lo com uma regra de firewall. Eu não tenho esse script, mas seria possível criar.
— Chris S
@ Chris S: Isso é mais ou menos o que meu script ts_block faz, exceto que ele é executado como um "coletor" de log de eventos e recebe um retorno de chamada cada vez que novos eventos são registrados. Como tal, ele roda mais ou menos em tempo real.
— Evan Anderson
Use VPN - instale, por exemplo. OpenVPN no roteador. Nunca coloque o windows box diretamente na internet - é perigoso.
— integratorIT

Respostas:

5

Para interromper as tentativas de login do RDP, como já foi dito, você precisa do controle do seu firewall para isolar um determinado IP. Você pode fazer algumas configurações em Ferramentas administrativas -> Gerenciador de serviços de terminal, mas não pode fazer nada para parar um ip dessa maneira. Talvez você deva considerar um script em lote para escutar a porta rdp e controlar as falhas de logon; portanto, se houver tentativas de tot (você escolhe o número ...) pelo mesmo IP, nenhuma outra tentativa por um período de tempo conhecido poderá estar. Não tenho certeza se é possível, mas poderia ser uma maneira ...

— Nicola Boccardi
fonte
1
Ok, é como eu pensava. Eu tenho que estudar o Visualizador de Eventos para ver se consigo exportar os endereços IP para um arquivo para processamento em lote. Por enquanto tem que grep-los a partir gerados manualmente .csv lixeiras
— Onik
5
Altere a porta na qual o RDP responde.
— JohnThePro
O engraçado é que eu quero para restringir IPs, mas a falha de logon não informa o endereço IP
— Csaba Toth
Alterar a porta apenas obscurece. Eles encontrarão a nova porta com o software inteligente de digitalização de portas.
— TheLegendaryCopyCoder
@CsabaToth O log de eventos não registra informações úteis por padrão. Você pode habilitar o log detalhado no serviço logon de rede a partir de um controlador de domínio ou computador que recebe as solicitações RDP para obter informações adicionais. Você pode habilitar o log de firewall do Windows para determinar o endereço IP.
— Michael Steele
25

Você realmente deve bloquear essas tentativas no seu firewall de borda, mesmo que limitando a taxa. Se você não tem a capacidade de fazer isso, continue lendo.

Se você não conseguir bloquear no firewall de borda e precisar que o RDP seja aberto apenas para um subconjunto da Internet, use os recursos internos do Firewall do Windows para bloquear as conexões de entrada.

Por fim, se você realmente precisa ter o RDP aberto para todo o Intenet, pode dar uma olhada na versão modificada do meu programa bloqueador de força bruta SSH para Windows que eu tenho em um repositório do github . Esse script, ts_block, bloqueia tentativas de logon dos Serviços de Terminal de força bruta no Windows Server 2003, 2008 e 2008 R2. Infelizmente, devido a alterações nos eventos registrados pelo Windows ao usar a camada de segurança TLS / SSL para RDP, esse script está se tornando cada vez mais ineficaz . (Por que a Microsoft optou por omitir o endereço IP do host que está tentando se autenticar está além de mim. Parece que isso seria uma coisa muito importante para registrar, não é?)

— Evan Anderson
fonte
1
Eu uso a página ts_block aqui e é incrível! Meu servidor Windows (2008 R2) costumava desacelerar sob vários ataques de força bruta, mas não mais! TS_BLOCK Está escrito em vbscript - e pode / deve ser instalado como um serviço do Windows - mas não use a versão MSI, apenas edite o código .vbs e instale-se com o utilitário nssm. Você não precisa das entradas do registro, pois o código .vbs possui os padrões codificados. <p> Editei o código e ele bloqueia TODOS os logins com falha imediatamente - como sendo meu próprio servidor da Web, NÃO deve haver tentativas falhas de logon. Então o script
Isso é muito fofo, Evan. Eu tenho meia mente para reimplementá-lo em C # para que você possa executá-lo como um serviço nativo do Windows, em vez de usar o srvany e coisas do tipo. Se eu fizer isso, vou vomitar no Github ou algo assim.
— precisa
1
@RyanBolger: Eu tenho uma queda por VBScript e linguagens interpretadas em geral. Acho que o uso do "Non-Sucking Service Manager" cria uma experiência bastante simples na execução de programas VBScript como serviços.
— Evan Anderson
O ts_block é incrível, é exatamente o que eu estava procurando "Obrigado Evan Anderson". Quando coloquei meu primeiro servidor virtual do Terminal ativo diretamente na Web em um dia, eu tinha mais de 10.000 logins com falha. Quando tiver tempo, posso modificá-lo e adicionar bloqueio permanente com base no número de blocos anteriores. por exemplo: IP é banido 4 vezes em um dia. (A menos que já tenha sido criado)
Com base no ts_blockscript, aqui está uma solução que usa fail2banno gateway para bloquear invasores: wqweto.wordpress.com/2013/12/10/…
— wqw 13/12/13
3

Eu tenho um programa c # que faz exatamente isso. Eu tive um problema no Server 2008 R2 em que o log de eventos nem sempre listava os endereços IP do usuário (se eles se conectassem a partir dos clientes mais recentes da Área de Trabalho Remota). Alguns serviços implementam seu próprio provedor de verificação de credenciais que não fornece todas as informações que você deseja.

http://cyberarms.net/security-insights/security-lab/remote-desktop-logging-of-ip-address-%28security-event-log-4625%29.aspx

Para a Área de Trabalho Remota, no entanto, descobri que entrar em "Configuração do host da sessão da área de trabalho remota" e alterar a conexão RDP-TCP para que a camada de segurança de "Camada de segurança RDP" em vez de "Negociar" ou "SSL (TLS 1.0)" retorne o Endereços IP.

Se você realmente deseja fazer isso, é outra pergunta para você: "Se você selecionar Camada de segurança RDP, não poderá usar a autenticação no nível da rede".

Eu achei http://www.windowsecurity.com/articles/logon-types.html útil. Eu usei EventLogWatcher e vinculei a "* [System / EventID = 4625 ou System / EventID = 4624]" para que eu pudesse redefinir uma contagem incorreta de êxito se o usuário realmente tivesse errado sua senha. Também incluí na lista branca :: 1, 0.0.0.0, 127.0.0.1 e "-". Você pode ou não querer adicionar os IPs de LAN / gerenciamento à lista de permissões.

Como uso o Forefront TMG, usei a API para adicionar endereços IP inválidos a um grupo de IPs dessa maneira e pedi à Cisco para adicionar acesso à API a um de seus roteadores SMB (o que eles me garantiram que poderiam fazer!)

Se você deseja usar o Firewall do Windows nativo para bloqueá-los, consulte a API para isso ("netsh advfirewall").

Eu permito x número de tentativas antes de banir e um sucesso redefinirá a contagem.

— Matthew1471
fonte
2

Você está tentando impedir invasões ou logs desordenados? Se você está tentando impedir invasões, o Windows possui uma maneira integrada de bloquear tentativas de logon. Há uma configuração de Diretiva de Grupo de Limite de Bloqueio de Conta em Configuração do Computador -> Diretivas -> Configurações do Windows -> Configurações de Segurança -> Política de Conta -> Política de Bloqueio de Conta.

Os invasores usarão nomes de usuário comuns, como Administrador, e certamente os bloquearão. Você precisaria de uma conta separada para administração real, o que provavelmente é aconselhável.

O bloqueio automático no nível do firewall exigirá alguma leitura de log com script com atualização automática das regras do firewall. Você deve poder adicionar regras com base no endereço IP dessa maneira. Isso é basicamente o que o iptables faz em um sistema Linux.

Pode ser um pouco óbvio, mas você também considerou executar os Serviços de Área de Trabalho Remota em uma porta não padrão ? Isso tem sido muito eficaz para mim em impedir invasões.

— Joel E Salas
fonte
Bloquear tentativas repetidas de conexão no firewall é uma boa prática, mas supor que ataques de força bruta não ocorram "atrás do firewall" não é uma suposição muito boa. Um bruto por bloco baseado em host é uma ideia razoavelmente boa, na minha opinião. Usar o bloqueio de conta é definitivamente uma boa ideia, mas também gosto da ideia de reprimir a força bruta e também manter os registros mais limpos.
— Evan Anderson
1
Já estou executando em uma porta não-padrão, e minha maior preocupação é realmente ter meu servidor offline efetivamente devido ao grande número de tentativas de login.
— boomhauer
Uma opção é desativar completamente o acesso à Área de Trabalho Remota por meio do Firewall, mas ter um serviço em execução no servidor que reconfigura o firewall para permitir o tráfego RDP, esse serviço é protegido por senha e talvez apenas permita acesso de uma fonte IP "confiável" ( como o intervalo de IP de um telefone celular ou o escritório). Introduz aborrecimentos, mas funciona.
— Dai
1

Existem algumas outras soluções também, se você deseja ter uma solução baseada em GUI e criar realmente diferentes conjuntos de regras para eventos diferentes. O mais fácil seria o RDPGuard (hxxp: //www.rdpguard.com), mas em um ambiente corporativo você provavelmente desejaria mais relatórios, como de onde veio o ataque (país, origem) e qual nome de usuário foi usado para que você possa rapidamente decida se é um dos seus próprios usuários bloqueando-se acidentalmente ou tentando fazer login de onde você sabe que não estão.

Pessoalmente, gosto do Syspeace (hxxp: //www.syspeace.com) que faz tudo isso por nós, mas eu pensei em mencionar os dois de qualquer maneira

— Juha Jurvanen
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.