Protezione contro blocco account DoS

22

Qualche idea su come proteggersi dal seguente scenario?

La società x utilizza la directory attiva per l'autenticazione dei suoi dipendenti. La società ha più punti di autenticazione semi-pubblici e alcuni completamente pubblici. (ad es. Extranet accessibile da Internet)

I nomi utente sono abbastanza facili da indovinare, poiché seguono una convenzione di denominazione standard, basata sul nome del dipendente.

Se Eve voleva montare un DoS contro Company X e ha accesso a un gran numero di nomi di dipendenti, per lei sarebbe piuttosto banale bloccare account di molti dipendenti dell'azienda.

Qualche idea su come proteggere da questo tipo di attacco?

Capisco che un blocco della lunghezza variabile possa essere d'aiuto, ma significherebbe comunque che i dipendenti non hanno effettuato l'accesso, lavorando.

Pensieri?

    
posta Josh Brower 16.01.2011 - 05:29
fonte

4 risposte

9

C'è un articolo che descrive come usare Microsoft Lync (precedentemente Office Communications Server) per mitigare gli attacchi brute force:

link

frammenti:

"DoS attacks are indistinguishable from legitimate sign-in requests. The only differentiation is in the frequency of sign-in attempts and origin. A large number of sign-in attempts in rapid succession can be indicative of a DoS attack. DoS attacks attempt to guess the user's password to gain unauthorized access, and often result in locking out the user account if security policy is enabled in Active Directory."

"By enforcing account lockout at the Edge Server, the security filter prevents DoS attacks at the edge of the network perimeter, and as a result, protects internal Office Communications Server resources"

Microsoft ha un altro white paper intitolato: White paper sulle best practice per il blocco degli account
cerca "Protezione dagli attacchi di negazione del servizio di blocco degli account esterni"

snippet di chiave (copiati letteralmente):

Protecting from External Account Lockout Denial of Service Attacks
It is possible for a malicious user to launch a denial-of-service attack against your enterprise from outside of your network. Because most networks are interconnected, this can be a difficult attack to mitigate. The following techniques technologies are common techniques and technologies that you can use to help mitigate or prevent such attacks:

Require complex passwords: All accounts should have a complex password. All administrator accounts (local and domain) should have a long, complex password and you should change the password regularly.

Rename the administrator account: Because the administrator account cannot be locked out, it is recommended that you rename the account. Although this does not mitigate all of the attacks against the administrator account, it does help mitigate these attacks most of the time. For more information, see "HOW TO: Rename the Administrator and Guest Account in Windows 2000" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=320053.

Protect your environment with firewalls: To avoid an account lockout denial of service attack, block the TCP and UDP ports 135 through 139 and port 445 on your routers and firewalls. When you do this, you prevent logon attempts that occur outside of your network.

Prevent anonymous access: Set the RestrictAnonymous value to 2 on all computers that are exposed to the internet and to the entire domain if all of the computers are running versions of Windows 2000 or later. This stops malicious users from making anonymous connections to resources and may help defeat some types of attacks. Note that some operating systems have limited support for computers that have this setting. Some programs may also have issues with this setting if the programs use an anonymous connection to gain access to resources. For more information, see "How to Use the RestrictAnonymous Registry Value in Windows 2000" on the Microsoft Knowledge Basehttp://support.microsoft.com/?id=246261.

Protect site-to-site traffic by using a VPN tunnel: If communication between domain members in two sites is required, use a site-to-site VPN tunnel to securely connect site networks together. Do not open all NetBIOS ports on the firewall. You can use the Windows 2000 Server Routing and Remote Access service to create site-to-site VPN tunnels. If no VPN devices are available, you should configure the edge firewall or router filters to limit the traffic that is permitted to flow between the Internet Protocol (IP) address ranges that are used by each site. If sites need to use Active Directory replication only across the Internet, then use Internet Protocol security (IPSec) transport mode through the firewalls to secure all traffic between Active Directory servers. For more information about Active Directory replication through firewalls, see the "Active Directory Replication over Firewalls" white paper on the Microsoft Web site|http://www.microsoft.com/serviceproviders/columns/config_ipsec_p63623.asp.

Protecting authentication and NetBIOS ports from Internet attack: On either the firewall or the router that connects your internal network to the Internet, block access to TCP and UDP ports 135 through 139 and port 445. If no edge filtering device is available, you can use IPSec filters to block these ports. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878.

• In the same IPSec policy, you must create an additional rule that adds filters to permit traffic to these ports when the source address is in a subnet that is used by the internal network. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878.

Protecting authentication and NetBIOS ports from internal attack: If you must protect access to both authentication and NetBIOS ports from internal malicious users, you can restrict the computers that are permitted to gain access to these ports to only domain member computers by using the feature in IPSec that allows you to negotiate security. By allowing only trusted computers (domain member computers) to gain access to both authentication and NetBIOS ports, you reduce the number of computers that can perform the attack. This extra protection provides a defense against any breaches in your security perimeter and against malicious users who can connect to the internal network. For information about how to create a custom IPSec policy to use Kerberos authentication when negotiating IPSec security for access to TCP and UDP ports 135 through 139 and port 445 see the "Step-by-Step Guide to Internet Protocol Security (IPSec)" on the Microsoft Web site|http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp.

Update the server: Keep all of your servers up-to-date with current versions of antivirus software, firewall software, and Windows security patches. This helps prevent trojan horse programs and viruses from attacking your resources if the malicious user can launch an attack from your internal network instead of from the Internet. These updates are an important part of an in-depth and defensive security strategy.

    
risposta data 16.01.2011 - 06:17
fonte
7
  1. Rilevamento
    • Sono necessari controlli di controllo per avvisare di un'alta frequenza di blocchi dell'account
  2. Difesa
    • Un'idea è tracciare l'indirizzo IP di origine che sta causando il blocco degli account. Dopo che questo indirizzo IP src ha superato una soglia definita (ad esempio 2 account in 10 secondi), all'utente viene richiesto un CAPTCHA che deve essere completato correttamente per continuare i tentativi di autenticazione sul sito Web. Ciò impedirebbe all'attaccante di essere in grado di scrivere un attacco di blocco dell'account.
    • Dopo che l'indirizzo IP src ha superato una seconda soglia (ad esempio 10 account bloccati in 60 secondi), l'indirizzo IP viene bloccato per X minuti. Certo, questo potrebbe bloccare altri utenti se l'attaccante è dietro un NAT aziendale, ma è un'opzione che puoi usare per difendere la tua applicazione.

Se l'autore dell'attacco utilizza più proxy e ha programmato un attacco di blocco degli account che utilizza una varietà di indirizzi IP di origine, non sarà possibile utilizzare queste idee. Tuttavia, si spera che i controlli di rilevamento nel passaggio 1 abbiano avvisato un amministratore che può indagare manualmente sul problema.

Nessuno di questi elementi è incorporato in LDAP: sarebbe tutto un codice personalizzato.

  • Michael
risposta data 18.01.2011 - 02:46
fonte
3

La prima cosa che viene in mente è quella di controllare più accessi non riusciti su più account una volta che sono stati bloccati. Per esempio. Eve cerca l'account di Bob 10 volte e viene bloccato. Quindi cerca l'account di Tim e viene bloccato. Dopo n numero di account hai una buona idea che qualcuno stia provando a eseguire gli account. Tuttavia, questo non risolve il tuo problema, ti consente solo di controllarlo.

Una soluzione semplice sarebbe quella di separare i blocchi di accesso dalla rete, quindi se provate ad accedere tramite l'extranet e vieni bloccato, puoi comunque accedere localmente. Detto questo, non sono sicuro di come sia possibile farlo tramite Active Directory, né sono sicuro di che tipo di implicazioni abbia questo.

    
risposta data 16.01.2011 - 06:09
fonte
2

Se per qualsiasi motivo non puoi davvero separare i tuoi punti di autenticazione pubblici dagli account utente interni, devi affrontare la possibilità di dover costantemente confrontarti con utenti bloccati. Anche se non vi è alcuna minaccia immediata di violazione, questo potrebbe sovraccaricare il team di amministrazione con richieste di sblocco.

Inoltre, c'è un altro aspetto: il blocco degli account può diventare un problema anche nella rete interna. In passato si sapeva che il malware tentava di utilizzare account di forza bruta per diffondersi (ad esempio alcune versioni di Conficker stavano provando attacchi di dizionario sulle azioni ADMIN $) che potevano portare a situazioni di disagio per gli amministratori.

Suggerirei quindi:

  1. per considerare attentamente le tue politiche di blocco per impedire un blocco completo
  2. per mettere a punto le sicurezze di "sblocco" per consentire l'eventuale lock-release

LockOutThreshold , ObservationWindow e LockOutDuration possono essere di aiuto in questi casi. Per il loro esatto utilizzo controlla MS Best practice per il blocco degli account .

Un approccio a cui penserei (più suggerimenti nel documento sopra) sono:

utenti normali :

  • numero medio o elevato di tentativi (per aiutare gli utenti smemorati),

  • (relativamente) breve finestra di osservazione (per prevenire attacchi di forza bruta),

  • versione rapida, forse 15'-30 '(per salvare l'helpdesk da quelle chiamate ...)

admin :

  • un numero ridotto di tentativi (dovrebbero conoscere la password),

  • finestra di osservazione bit più lunga (la complessità della password dovrebbe offrire una certa protezione dalla forza bruta),

  • rilascia dopo alcune ore

Le tue idee?

    
risposta data 16.05.2012 - 13:09
fonte

Leggi altre domande sui tag