Archivi tag: microsoft

Configurare un router Cisco 2800 come server VPN PPTP

Premesso che le VPN PPTP non sono il massimo per ciò che concerne la sicurezza, a volte è conveniente scegliere tale tecnologia per questioni di semplicità. Infatti, il protocollo PPTP, essendo stato introdotto da Microsoft, è ampiamente supportato dai client Windows e quindi la loro configurazione risulta quasi immediata.

2811Ma bando alle ciance a vediamo come configurare il nostro router.

Per prima cosa è necessario abilitare il server VPN mediante il comando:

Router(config)# vpdn enable

successivamente occorre creare un gruppo vpnd, specificando diversi parametri come, ad esempio, il virtual-template:

Router(config)# vpdn-group 1
Router(config-vpdn)# accept-dialin
Router(config-vpdn-acc-in)# protocol pptp
Router(config-vpdn-acc-in)# virtual-template 1

Ora è necessario configurare il suddetto virtual-template:

Router(config)#int virtual-template 1
Router(config)# ip unnumbered FastEthernet0/1
Router(config)# ip nat inside
Router(config)# ip virtual-reassembly
Router(config)# peer default ip address pool PPTP-Pool
Router(config)# no keepalive
Router(config)# ppp encrypt mppe 128
Router(config)# ppp authentication ms-chap ms-chap-v2

In particolare, con i comandi:

Router(config)#ip unnumbered FastEthernet0/1
Router(config)# peer default ip address pool PPTP-Pool

faremo in modo che ai client VPN venga assegnato un IP del pool associato alla nostra LAN (PPTP-Pool non è altro che il nome del pool DHCP configurato sul router), mentre con il comando:

Router(config)# ip nat inside

consentiremo ai client VPN di uscire su Internet utilizzando l’IP pubblico del router.

Per la creazione delle utenze, è sufficiente lanciare il seguente comando in modalità di configurazione:

Router(config)# username <user> password <pass>

Se avete abilitato il service password-encryption la password non verà mostrata in chiaro nella configurazione ma in formato digest propriatario Cisco (che è comunque reversibile).

Salviamo la configurazione con un copy run start ed abbiamo finito.

Alla prossima.

Traffico PPTP in uscita dai router Cisco

Il PPTP (Point to Point Tunnel Protocol) è uno dei protocolli utilizzati nell’ambito delle cosiddette VPN (Virtual Private Network). Esso venne introdotto dalla Microsfot e garantisce un certo livello di sicurezza, certamente molto inferiore a quello tipico delle VPN IPSec o SSL/TLS.

Site-to-site-pptp-example.jpg

Senza scendere troppo nel dettaglio è bene specificare che il protocollo PPTP non va per niente daccordo con il NAT/PAT. Per questo motivo, affinchè le connessioni in uscita dalla nostra LAN e dirette al server VPN remoto vadano a buon fine, è necessario implementare un meccanismo di PPTP Passthrough. In realtà, tale meccanismo si basa sull’EGRE (Enhanced Generic Routing Protocol), quindi quello che faremo sarà semplicemente consentire il traffico GRE in ingresso alla nostra LAN.

Inoltre, poichè tale connessione è di tipo punto-punto, il router non vedrà l’indirizzo IP sorgente relativo alla VPN, ergo non dovremo neppure modificare le regole dell’ACL che hanno come scopo il blocco del traffico proveniente da Internet e con indirizzi IP privati (spoofing).

Come al solito, bando alle ciance ed ecco la regola da inserire subito prima il deny ip any any (implicito) della nostra ACL:

access-list 102 permit gre any any log

Ebbene si, il GRE è un protocollo differente da quelli visti fin’ora (ad esempio IP, TCP o UDP), non prevede l’uso di porte ed è abbastanza intelligente da lavorare senza ulteriori configurazioni.

Una volta aggiunta tale regola sul nostro router Cisco sarà possibile atterrare tranquillamente sul VPN Concentrator, ricevere un indirizzo IP appartenente al pool privato e navigare tra le risorse di rete (ed eventualmente su Internet) come se si fosse connessi direttamente alla LAN dell’ufficio.

E’ tutto. Bye.

Query WMI clientless mediante Nagios ed NRPE_NT

Premessa

Prima di introdurre questa piccola guida, occorre spiegare cosa s’intende per WMI. Nella fattispecie, tale acronimo sta per Windows Management Instrumental, ovvero un’estensione del Win32 driver model, grazie alla quale è possibile monitorare e gestire le macchine (sia client che server) su cui è installato il sistema operativo di casa Microsoft (da Windows 2000 in poi).

Inulte dire che esistono già delle piattaforme sviluppate ad hoc che supportano le query WMI (tra cui SCOM), ma la cosa veramente interessante consiste nel poter sviluppare i propri sistemi di monitoraggio basati su scrip custom editati in VBscrip o PowerShell.

Ora, nel caso in cui si voglia allestire un sistema di monitoraggio che supporti le query WMI in ambiente open source, la scelta ricade necessariamente su nagios3. Inoltre, poichè nagios3 non supporta in modo nativo le query WMI, si rende indispensabile l’utilizzo di un tool che funge da tramite tra il server di monitoraggio e le macchine che verranno interrogate. Tale tool prende il nome di NRPE_NT (potete scaricarlo da qui, è gratuito).

nrpe.png

 

Come si può capire dall’immagine precedente, nagios3, attraverso il comando check_nrpe, invia una query ad NRPE_NT (installato su una macchina Windows), il quale la inoltrerà (comportandosi come un vero e proprio proxy) all’host Microsoft di destinazione.

Ricapitolando, abbiamo bisogno dei seguenti elementi per mettere in piedi il nostro sistema di monitoraggio WMI:

1) nagios3;

2) il plugin check_nrpe;

2) NRPE_NT;

3) i plugins V2 per NRPE_NT (potete scaricarli da qui).

Installazione di check_nrpe e configurazione di nagios3

Partendo dal presupposto che nagios3 sia già presente sulla nostra linux box, procediamo con l’installazione del plugin check_nrpe. Per fare ciò occorre digitare:

nightfly@nightbox:~$ sudo apt-get install nagios-nrpe-plugin

Adesso possiamo definire alcuni comandi custom da inviare alla macchina Windows su cui è installato NRPE_NT, affinchè quest’ultima possa inoltrare la query all’host di destinazione. In particolare, creiamo il file wmi.cfg all’interno della directory /etc/nagios-plugins/config, il cui contenuto sarà:

# nagios-WMI-cpu check command definition

define command {

command_name check_WMI_cpu

command_line /usr/lib/nagios/plugins/check_nrpe -H <IP macchina NRPE_NT> -c get_cpu -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-disk check command definition

define command {

command_name check_WMI_disk

command_line /usr/lib/nagios/plugins/check_nrpe -H<IP macchina NRPE_NT> -c get_disk -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-mem check command definition

define command {

command_name check_WMI_mem

command_line /usr/lib/nagios/plugins/check_nrpe -H<IP macchina NRPE_NT> -c get_mem -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

Ovviamente esistono altri comandi di cui si può usufruire, una lista a cui far riferimento la trovate qui.

Bene, adesso definiamo i servizi da monitorare per i nostri host Windows. Un file di configurazione da utilizzare come template e da posizionare nella directory /etc/nagios3/conf.d è il seguente:

define host {
host_name   hostWindows
alias       nightflyclient
address     192.168.1.11
use         generic-host
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI CPU for Microsoft Windows Machine
check_command                   check_WMI_cpu!CPU0!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI Disk for Microsoft Windows Machine
check_command                   check_WMI_disk!C:!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI Memory for Microsoft Windows Machine
check_command                   check_WMI_mem!_TOTAL!80,90
}

Salviamo il file appena creato e passiamo all’installazione di NRPE_NT sulla macchina Windows che fungerà da proxy per le query WMI.

Installazione di NRPE_NT

Per prima cosa scompattiamo il file nrpe_nt.0.8b-bin.rar e salviamone il contenuto all’interno della directory NRPE_NT presente in C:

Creiamo inoltre, sempre all’interno della directory NRPE_NT, la cartella Plugins ed all’interno di quest’ultima creiamo un’ulteriore cartella che chiameremo V2, nella quale salveremo il contenuto del file wmi-1.3.rar.

A questo punto editiamo il file nrpe.cfg presente nella directory bin, che si trova dentro la cartella NRPE_NT.

I punti da modificare sono sostanzialmente tre, ovvero:

allowed_hosts=<IP della linux box su cui è installato nagios3>

(in modo da consentire a nagios di connettersi ad NRPE_NT per usarlo come proxy);

dont_blame_nrpe=1

(in modo da consentire l’esecuzione di comandi da remoto);

include=C:\NRPE_NT\Plugins\V2\V2_nrpe_commands.cfg

(per dare in pasto ad NRPE_NT alcuni comandi aggiuntivi di monitoraggio).

Una volta configurato NRPE_NT passiamo alla sua installazione. Per fare ciò apriamo il prompt (start->esegui->cmd), posizioniamoci in C: e successivamente nella dir bin presente in NRPE_NT.

cmd.jpg

A questo punto lanciamo il comando:

nrpe_nt.exe -i

dove la flag -i sta per install.

NB: nel caso in cui stiate utilizzando una macchina su cui è installato Windows 7, prima di procedere con l’installazione di NRPE_NT dovete modificare le impostazioni di controllo dell’account utente:

controllo.png

Una volta installato il servizio NRPE_NT occorre avviarlo mediante il comando net start nrpe_nt oppure attraverso pannello di controllo -> strumenti di amministrazione -> servizi.

Controlliamo ora che NRPE_NT sia in ascolto sulla nostra macchina digitando:

netstat -ano | find ":5666"

il cui output dovrà essere simile al seguente:

TCP    0.0.0.0:5666           0.0.0.0:0              LISTENING       1976

NB: affinchè la macchina su cui è installato nagios3 possa connettersi ad NRPE_NT occorre disabilitare il Firewall di Windows.

Test per verificare il corretto funzionamento di NRPE_NT

Per verificare il corretto funzionamento di NRPE_NT effettuiamo il login sulla nostra linux box e posizioniamoci nella directory /usr/lib/nagios/plugins. A questo punto lanciamo il comando:

nightfly@nightbox:/usr/lib/nagios/plugins$ ./check_nrpe -H <IP della macchina Windows su cui è installato NRPE_NT>

Se l’output immediatamente successivo sarà:

NRPE_NT v0.8b/2.0

vuol dire che NRPE_NT funziona correttamente.

Infine, riavviamo nagios3 per rendere effettive le modifiche della sua configurazione messe in atto nella prima parte di questa guida:

nightfly@nightbox:~$ sudo service nagios3 restart

Adesso sarà possibile monitorare gli host Windows mediante nagios3 ed NRPE_NT.

See ya.

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.