Archivi tag: domain controller

Script powershell per identificare le password di dominio “deboli”

Ogni tanto fare una sorta di security audit sulla nostra rete è cosa buona e giusta, soprattutto se in passato questo task è stato totalmente ingnorato dai sistemisti di turno.

Proprio per questo motivo, ho pensato di realizzare un scrip powershell in grado di testare la robustezza delle password utilizzate dalle varie utenze di dominio.

powershellPreparazione

Per prima cosa occorre creare una lista di password “deboli” all’interno di un file di testo (weakpasswords.txt). Tale file dovrà contenere una sola password per riga, ad esempio:

 password1
 password2
 password3

Una volta fatto ciò occorre salvare in un altro file di testo le utenze di dominio, lanciando tale comando direttamente sul domain controller:

NET USERS /DOMAIN > users.txt

Il contenuto del file users.txt sarà simile al seguente:

User accounts for \\DC
------------------------------------------------------------------ utente1                        utente2               utente3  utente4                        utente5               utente6

Affinchè lo scrip possa funzionare, però, è necessario che vi sia un solo utente per riga, ergo bisogna parsare il file users.txt e salvare il suo contenuto (opportunamente formattato) all’interno di un altro file (parsed.txt). Per farè ciò ho utilizzato awk (su una Linux box):

[root@server ~]# cat users.txt | awk '{print $1}' >> parsed.txt
[root@server ~]# cat users.txt | awk '{print $2}' >> parsed.txt
[root@server ~]# cat users.txt | awk '{print $3}' >> parsed.txt

Contenuto dello script

Adesso il file parsed.txt può essere spostato sul DC e possiamo creare il nostro scrip (che chiameremo testauth.ps1) il cui contenuto dovrà essere:

Function Test-ADAuthentication {
    param($username,$password)
    (new-object directoryservices.directoryentry "",$username,$password).psbase.name -ne $null
}

$users = Get-Content parsed.txt 
foreach ($user in $users) {
    $user = $user.Trim()
    $passwords = Get-Content weakpasswords.txt
    foreach ($password in $passwords) {
        $password = $password.Trim()
        $result = Test-ADAuthentication "NOMEDOMINIO\$user" "$password"
        if ($result -like "True") {
            echo "Username $user has got a the weak password $password" >> passresult.txt
        }
        else
        {
            echo "Password for user $user did not match" 
        }
    }
}

Esecuzione

Non ci resta che eseguire tale scrip powershell mediante il comando:

./testauth.ps1

e successivamente verificare il contenuto del file passresult.txt, in cui saranno presenti le associazioni utente/password “debole”.

Alla prossima.

Disabilitare i check di Nagios durante determinate fasce orarie

Scenario

Windows Server 2008 R2 che funge da Domain Controller ed Exchange server (si tratta di una piccola LAN, ergo, non è indispensabile dislocare tali servizi su due macchine differenti). Per monitorarne le risorse (in termini di RAM, CPU e di spazio sul disco), utilizzo delle query WMI, instradate dall’NMS (Nagios) ad un servizio dedicato in ascolto sul server (ovvero NRPE_NT – per approfondire l’argomento vi consiglio di consultare questo post).

nag.jpg

Problema

Poichè sul server in questione viene eseguito il backup dell’intero sistema operativo (compreso il DB di Exchange) a partire dalle 22 di ogni sera, durante tale lasso di tempo, Nagios produce una miriade di allarmi recanti l’errore Socket timeout after 10 seconds. Questo, in soldoni, significa che il DC non è stato in grado di servire la richiesta in quanto troppo impegnato (oppure la richiesta gli è giunta proprio durante il backup dei file utilizzati da NRPE_NT).

Soluzione

Disabilitare le query WMI di Nagios dalle 22 alle 23.

Per fare questo si possono seguire due strade:

1) utilizzare uno scrip bash creato ad hoc per disabilitare i check specifici, da lanciare mediante cron;

2) lavorare direttamente sul file di configurazione dell’NMS in questione.

Personalmente preferisco la seconda soluzione, in quanto più pulita (poichè coinvolge direttamente Nagios senza passare per uno scrip aggiuntivo e per cron – less is more).

Per prima cosa, occorre lavorare sul file timeperiods.cfg presente nella directory /etc/nagios/objects, creando l’oggetto NRPE_off:

define timeperiod{
         timeperiod_name NRPE_off
         alias           24 Hours A Day, 7 Days A Week
         sunday          00:00-22:00,23:00-24:00
         monday          00:00-22:00,23:00-24:00
         tuesday         00:00-22:00,23:00-24:00
         wednesday       00:00-22:00,23:00-24:00
         thursday        00:00-22:00,23:00-24:00
         friday          00:00-22:00,23:00-24:00
         saturday        00:00-22:00,23:00-24:00
         }

A questo punto è necessario modificare l’oggetto windows-service, presente nel file templates.cfg. Nella fattispecie, l’opzione da editare è check_period il cui valore dovrà essere NRPE_off:

define service{
        name                            windows-service
        check_period              NRPE_off

        ...

Ovviamente, le query WMI definite su Nagios sfruttano il template windows-service e quindi ereditano come check_period NRPE_off (precedentemente definito).

Per completezza, riporto uno stralcio della configurazione relativa alla query WMI che ha il compito di monitorare la RAM allocata:

define service{
         use                                  windows-service        ; Name of service template to use
         host_name                    domain-controller
         service_description     query WMI Memory for Microsoft Windows Machine
         check_command          check_WMI_mem!_TOTAL!85,95
 }

Lanciamo un restart di Nagios per rendere effettive le suddette modifiche:

[root@nagios objects]# service nagios restart

ed abbiamo finito.

Alla prossima.

Script bash per verificare la raggiungibilità dei Domain Controller

Supponiamo che nella vostra rete venga utilizzato Squid come proxy, sul quale è stata abilitata l’autenticazione NTLM. In questo modo, mediante Active Direcetory ed ai Domain Controller di casa Microsoft, sarà possibile fare in modo che, in base ai gruppi di appartenenza, i vari utenti della LAN possano visualizzare soltanto alcune tipologie di siti.

Però, occorre precisare che Squid, di per sè, non è in grado di gestire alcun tipo di content filtering, ma per fare ciò è necessario utilizzare alcuni add-on, quali DansGuardian o squidGuard.

Saranno proprio questi ultimi, mediante delle query ldap dirette al Domain Controller, a suddividere l’utenza in base ai siti che può visitare.

Nel caso in cui il primo Domain Controller di riferimento non sia più raggiungibile, si potrebbe operare direttamente sul file hosts, posizionato nella directory /etc, in modo da modificare il contenuto della entry relativa all’hostname del DC (ad esempio ldap.vostrodominio.org), associandolo all’indirizzo IP dell’altro Domain Controller.


bash.jpg

 

 

Il seguente scrip serve proprio a mettere in pratica quanto appena detto:

#!/bin/bash

DC1=192.168.1.1

DC2=192.168.1.2

destinatario=<vostroindirizzo>@<vistrodominio.org>

logfile=/var/log/ping.log

count_1=0

count_2=0

tmp=/var/log/tmp.log

var=`cat $tmp`

while [ $count_1 -lt 2 ]

do

echo "Pinging DC1..."

if ping -c 1 $DC1

then

if grep -q "$DC2" "/etc/hosts"

then

/bin/sed -i 's/192.168.1.2/192.168.1.1/g' /etc/hosts

echo "0" > $tmp

exit 0

else

exit 0

fi

else

let count_1=count_1+1

if [ $count_1 -eq 1 ]

then

echo "$(date) Primary Domain Controller Unreachable, trying again..." >> $logfile

else

echo "$(date) Primary Domain Controller Unreachable, trying to switch over DC2..." >> $logfile

if [ "$var" = "0" ]

then

echo "$(date) Primary Domain Controller Unreachable, trying to switch over DC2." | mail -iv -s "Alert: DC1 unreachable" $destinatario;

echo "1" > $tmp

fi

fi

fi
done

if [ $count_1 -eq 2 ]

then

while [ $count_2 -lt 2 ]

do

echo "Pinging DC2..."

if ping -c 1 $DC2

then

/bin/sed -i 's/192.168.1.1/192.168.1.2/g' /etc/hosts

exit 0

else

let count_2=count_2+1

if [ $count_2 -eq 1 ]

then

echo "$(date) Secondary Domain Controller Unreachable, trying again..." >> $logfile

else

echo "$(date) Unable To Contact Any Domain Controller" >> $logfile

if [ "$var" = "1" ]

then

echo "$(date) Unable To Contact Any Domain Controller." | mail -iv -s "Alert: DC1 and DC2 unreachable" $destinatario;

echo "2" > $tmp

fi

fi

fi

done

fi

exit 0

Rendiamo eseguibile lo scrip appena creato:

nightfly@nightbox:~$ sudo chmod +x ping.sh

Creiamo infine una entry per crontab, schedulando l’esecuzione di tale scrip ogni minuto:

* * * * *   root     ping.sh > /dev/null 2>&1

Ovviamente, nel caso in cui abbiate bisogno di alcuni chiarimenti sul codice, non esitate a contattarmi.

A presto.

DNS Scavenging

Da buon (presunto) sistemista Unix, disconosco (in parte) i server Microsoft. Però, recentemente ho avuto a che fare con un DC (Domain Controller) basato su Active Directory, che svolge (ovviamente) anche funzioni di DNS. Ora, da una rapida occhiata ai record, ho notato la presenza di diverse entry duplicate. Dove sta l’intoppo? Semplice, sta nel cosiddetto scavenging, ovvero un parametro che specifica ogni quanto verranno effettuate della scansioni automatiche sui record DNS alla ricerca di eventuali duplicati (per rimuovere le entry scadute, soprattutto nel caso in cui i stia usando un server DHCP). Basta quindi abilitare tale funzionalità (e settarla a dovere) per risolvere questo problema.

See ya.