Archive

Archive for the ‘Networking & NetSecurity’ Category

SquidClamav – The Antivirus for your Squid Proxy Server

Ciao a tutti, di recente in una consulenza un cliente mi ha chiesto se fosse possibile integrare, utilizzando sempre Linux,  nel Proxy Server in produzione (che gli avevo tirato su un anno fa con Debian & Squid 3) anche un controllo antivirus sfruttando sempre prodotti open.Era la prima volta, dopo i tentativi passati che avevo fatto con HAVP, (con il quale ho avuto dei problemi lato performance), che provavo nuovamente ad integrare squid con una soluzione AV open.

Ho googlato un pò e sono capitato sulla home del progetto SquidClamav che è arrivato ormai alla release 6 e che sfrutta un server c-icap come backend per interfacciarsi con squid e con clamav.

Effettivamente c-icap mi aveva già dato soddisfazioni in passato, e quindi ho deciso di provare con un altro tentativo incrociando le dita. Bè che dire … semplice l’installazione, semplice la configurazione, e un buon risultato (lato scansione antivirus) con delle performance accettabili anche in ambiente di produzione. Devo dire che anche clamav che non seguivo più da un pò, vanta oggi un euristica non male e delle definizioni per il phishing ben fornite; ed essendo un antivirus nato per il mondo linux non è male come punto di pattenza. Vediamo insieme l’installazione e la configurazione.

Installiamo clamav in versione daemon e facciamogli fare un update delle definitions (altrimenti vi da errore)

apt-get install clamav-daemon

freshclam

Installiamo altri pacchetti per poter procedere alla compilazione e installazione di squidclamav

apt-get install gcc make curl libcurl4-gnutls-dev c-icap libicapapi-dev

Scarichiamo e installiamo squidclamav

wget http://ftp.jaist.ac.jp/pub/sourceforge/s/project/sq/squidclamav/squidclamav/6.2/squidclamav-6.2.tar.gz

tar zxvf squidclamav-6.2.tar.gz

cd squidclamav-6.2

./configure –with-c-icap  && make && make install

Ora modifichiamo i files di configurazione per personalizzare l’installazione e modifichiamo la riga 17 e inseriamo l’URL della pagina di errore personalizzata.

http://nome-server/error.html (qualora vogliate farvi una semplice html di errore personalizzata)
 
Rendiamo il server c-icap avviabile come daemon al bootup
nano /etc/default/c-icap
# alla riga 6: modificate

START= yes

Editiamo il file di configurazione del server c-icap
nano /etc/c-icap/c-icap.conf
# riga 142: inserite l’indirizzo mail dell’amministratore
ServerAdmin tua-mail@gmail.com
#Riga 151 – Modificate l’hostname
ServerName fg-av-ux01.fg.local
# riga 499:  aggiungete
Service squidclamav squidclamav.so
 
Riavviamo il server c-icap con il comando
/etc/init.d/c-icap start
 
Ora modifichiamo squid per rendere la modifica attiva e aggiungiamo le seguenti direttive
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_header X-Authenticated-User
icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access service_req allow all
icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access service_resp allow all
 
Riavviamo ora Squid con il comando /etc/init.d/squid3 restart e godiamoci il nostro nuovo Proxy con Antivirus. Se volete testare il tutto potete visitare il sito EICAR e da lì  scaricare un file di test e verificare che il  corretto funzionamento di squidclamav come da screenshot seguente che vi allego.
 
error_01
 
 
Rimango a disposizione qui sul blog qualora abbiate qualcosa da chiedere.
Ciauz
 

Squid 3 LDAP Groups

Eccomi di nuovo qui …

Su spunto di alcuni colleghi, che mi hanno scritto in questi ultimi giorni in merito all’autenticazione LDAP su Squid 3 con un Domain Controller Active Directory, è nata un’interessante discussione sull’utilità di far autenticare sulle workstation joinate al dominio tutti gli utenti presenti in AD ma di far navigare solamente gli utenti abilitati.

Questa necessità nasce dal fatto che in alcune realtà, sempre per ragioni di sicurezza, si vuole comunque rendere la navigazione fruibile solo agli utenti con mansioni particolari.

Bè chi pensava che il fido e potente Squid 3 non potesse fare ciò si sbagliava!!!

Ecco come ho implementato la cosa sul proxy di un cliente :

auth_param basic program /usr/lib/squid3/squid_ldap_auth -v 3 -R -b “dc=RAV3N,dc=HOME” -D “cn=Admin,cn=Users,dc=RAV3N,dc=HOME” -w passwordSegreta -f sAMAccountName=%s -h xxx.xxx.xxx.xxx:389

Ovviamente per il significato di questo quote vi rimando al post precedente, dove spiegavo come interfacciare via LDAP Squid 3 con Active Directory. Con l’helper LDAP eseguiamo l’autenticazione del singolo utente, ma se vogliamo concedere la navigazione solo agli utenti appartenenti ad un singolo gruppo dobbiamo integrare questo helper con le  external ACL di Squid come segue :

external_acl_type gruppo_ldap %LOGIN /usr/lib/squid3/squid_ldap_group -v 3 -R -K -b “dc=RAV3N,dc=HOME” -D “cn=Admin,cn=Users,dc=RAV3N,dc=HOME” -w “PasswordSegreta” -f “(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,cn=Users,dc=RAV3N,dc=HOME))” -h xxx.xxx.xxx.xxx:389

Il significato di questa ACL è il seguente:

  • richiamiamo l’helper squid_ldap_group
  • -v 3 indica di utilizzare il protocollo LDAP versione 3, come specificato nel post precedente perchè è quello più compatibile con un Domain Controller Windows Server 2008 R2
  • -R indica di non seguire i referal all’interno della foresta Active Directory
  • -b Indica il percorso DN base in cui eseguire la ricerca; io qui ho specificato tutta la foresta Active Directory
  • -D Indica il DN dell’utente che utilizzeremo per fare il bind con il Domain Controller; ovvero un utente abilitato alla lettura degli oggetti e dei loro attributi presenti nella foresta active directory
  • -w indica la password per effettuare il bind associata all’utenza indicata nel parametro -D
  • -f indica la query da eseguire sulla foresta Active Directory
  • -h indica l’indirizzo IP del Domain Controller
  • :389 indica la porta su cui il DC è in ascolto per poter accettare il bind e la richiesta da parte di Squid

Adesso vediamo nello specifico il significato della query, che è la parte più importante di tutto il procedimento per poter eseguire questo tipo di autenticazione basata su gruppi :

  • (objectclass=person) – Indica di ricercare e di verificare l’0ggetto persona o meglio l’oggetto utente
  • (sAMAccountName=%v) – Indica di parsare l’username che  l’utente ha passato all’helper squid_ldap_auth e che è già stato autenticato con successo tramite Active Directory (praticamente il quote precedente al punto sAMAccountName=%s)
  • (memberof=cn=%a,cn=Users,dc=RAV3N,dc=HOME) – Indica di verificare che l’utenza presente nella variabile d’ambiente %v deve far parte del gruppo %a che specificheremo noi nell’ACL ad HOC che vi mostro dopo. Praticamente se l’utente, che è già stato autenticato dall’helper squid_ldap_auth (e messo nella variabile %v) appartiene al gruppo oppure ai gruppi richiamati dalla variabile %a allora la connessione verrà passata.

Adesso non ci resta che specificare un’ACL per ogni gruppo che vogliamo abilitare alla navigazione ad Internet

acl navigazione-limitata external gruppo_ldap limitati
acl navigazione-illimitata external gruppo_ldap illimitati

Il significato, molto semplice devo dire, è il seguente:

  • navigazione-limitata è il nome che diamo all’ACL del gruppo
  • gruppo_ldap è il nome dell’ACL external che parsa l’utenza e ne verifica l’appartenenza al gruppo su AD
  • limitati indica il nome esatto del gruppo presente in AD al quale suddetta utenza deve appartenere

Quindi per concludere ci basterà creare delle direttive http_access come segue:

acl ldap-auth proxy_auth REQUIRED

http_access allow navigazione-limitata ldap-auth

http_access allow navigazione-illimitata ldap-auth

http_access deny all

Dove il significato è il seguente:

  • acl ldap-auth proxy_auth REQUIRED – Indica di forzare l’autenticazione della connessione (via ldap semplice)
  • http_access allow navigazione-limitata ldap-auth – Indica di consentire la navigazione agli utenti verificati sia dall’ACL navigazione-limitata che dall’ACL ldap-auth (che esegue l’autenticazione semplice)
  • Idem per l’acl navigazione-illimitata ldap-auth
  • http_access deny all – Indica di negare l’accesso a tutto il resto

Ovviamente poi potete anche  giocare un pò con le altre direttive relative all’autenticazione per esempio :

auth_param basic children 2
auth_param basic realm Web-Proxy della Rete RAV3N.HOME
auth_param basic credentialsttl 10 minutes
authenticate_ip_ttl 60 seconds
auth_param basic casesensitive on

Il significato delle varie direttive è abbastanza semplice, ed è quanto segue:

  • auth_param basic children 2 – Indica quanti processi dell’helper squid_ldap_auth devono essere attivate da squid
  • auth_param basic realm – Indica il messaggio da sparare all’utente nel pop-up di autenticazione
  • auth_param basic credentialsttl 10 minutes – Indica per quanti minuti vengono cachate le credenziali da squid
  • authenticate_ip_ttl 60 seconds – Indica il TTL dell’autenticazione per singolo IP (Time To Live)
  • auth_param basic casesensitive on – Indica se l’helper deve essere case sensitive oppure no nel parsare i dati passati dall’utente

Poi le possibilità sono veramente tante, ma per questo vi rimando al wiki di squid che è ben fornito e ben fatto 😉

Ecco … spero di essere stato utile e soprattutto di aver aiutato qualcuno che magari si sta cimentando con squid per la prima volta. In qualsiasi caso se avete dei consigli oppure delle integrazioni commentate pure 😉

Ciauz

Squid 3 and LDAP Auth

Ciao a tutti,

scrivo questo breve articolo in merito ad un argomento di cui si è discusso molto su alcune Mailing lists e su alcuni forum negli ultimi mesi. Rifacendomi al whitepaper da me scritto e che trovate anche qui su questo blog, relativo alla multilayered network security, uno strumento molto importante e utilizzato relativamente allo strato perimetral security è dettato proprio dal proxy di rete.

Perchè il proxy vi chiederete? Bè questo strumento permette di discriminare la navigazione, obbligare la navigazione ad essere autenticata e non più “selvaggia”, aiuta a risparmiare banda e permette di impostare ACL utili ai network admin per contenere i costi relativi al calo di produttività e allo spreco inutile di risorse di bandwith; oltre a ridurre i rischi di sicurezza  derivanti dalla navigazione irresponsabile degli utenti.

Su quanto riguarda i metodi di autenticazione, uno strumento open e flessibile come squid 3 ha tantissimi helper che ci permettono di scegliere il metodo che più ci aggrada. Sicuramente in una realtà enterprise dove convivono sistemi Windows e Linux, e  magari dove cè pure una backend Active Directory sicuramente l’helper LDAP è quello più utilizzato in quanto l’autenticazione ntlm non è supportata da tutti i prodotti (chrome per esempio ha ancora dei problemi con l’autenticazione ntlm).

Per autenticare gli utenti via LDAP, utilizzando una distro come debian squeeze con installato squid 3, basta impostare un’ACL come segue :

auth_param basic program /usr/lib/squid3/squid_ldap_auth -v 3 -R -b “dc=RAV3N,dc=HOME” -D “cn=Admin,cn=Users,dc=RAV3N,dc=HOME” -w passwordSegreta -f sAMAccountName=%s -h xxx.xxx.xxx.xxx:389
auth_param basic children 5
auth_param basic realm Web-Proxy della Rete RAV3N.HOME

La prima riga richiama l’helper squid_ldap_auth, e ora vederemo il significato di ognuno di essi :

  • -v 3 >> Indica di utilizzare la versione 3 del protocollo LDAP (Questo perchè utilizzo un DC Windows Server 2008 R2 come backend Active Directory e quindi era l’opzione maggiormente compatibile
  • -R indica di non seguire tutti i referal all’interno della struttura Active Directory
  • -b specifica il DN base della query; in questo caso io ho specificato tutta la forest Active Directory
  • -D Specifica il DN dell’utente abilitato alla lettura e all’estrazione degli attributi degli oggetti presenti nel catalogo AD
  • -w passa la password di autenticazione al dominio dell’utente utilizzato nel parametro -D
  • -f passa la condizione di match, e in questo caso sAMAccountName=%s indica che qualora l’utente sia matchato  venga accettata l’autenticazione della connessione
  • -h indica l’indirizzo ip del domain controller oppure del server LDAP contenente il database degli utenti
  • :389 indica la porta di default sulla quale il nostro DC Windows è in ascolto per queste interrogazioni – ATTENZIONE LA PORTA 389 NON SUPPORTA LA CRITTOGRAFIA SSL/TLS DELLA CONNESSIONE
  • children 5 indica di mantenere attivi 5 processi da parte dell’helper usato da squid per l’autenticazione
  • realm indica il messaggio da sparare all’utente quando comparirà il popup che richiederà di autenticarsi

In questo modo, indifferentemente dalla UO in cui l’oggetto utente sarà allocato, se l’username esiste e la password matcha con il valore dell’attributo password dell’utente presente nella base LDAP la connessione verrà autenticata con successo

Poi per la forzatura dell’autenticazione, e la specifica direttiva http_access da associare vi rimando al wiki di squid che è veramente ben fatto e ben fornito. Spero che questo post possa venire in aiuto a qualcuno che si sta cimentando in questo ambito

Ciauz

Vmware Server 2 e Debian Squeeze 64 bit

Ciao a tutti,

dopo tanto tempo ho deciso di aggiornare il mio blog con una breve esperienza che ho fatto sul campo proprio in questi ultimi giorni. Causa problemi tecnici il mio vecchio server linux è deceduto, e quindi ho deciso di fare un investimento e comprare un bel “server” degno di tale nome;  equipaggiato con un bel XEON Quad Core 2.3 Ghz e 8 GB di RAM con tre schede di rete Gigabit. Che dire …. la prima idea che mi è venuta in mente è stata “Cavolo con tutta questa ram è un peccato fare un singolo server Windows o Linux che sia”. Proprio in quest’ottica ho deciso di ripiegare sul quello che per ora sembra essere il  futuro dell’IT, ovvero la Virtualizzazione (parte integrante dei pradigmi del GreenIT) e quindi provare l’accoppiata Debian Squeeze & Vmware Server 2.

Ho proceduto con l’installazione di una Debian Squeeze 64 bit minimale, partendo dal CD netinstall reperibile sul sito ufficiale di Debian (direttamente da qui). Una volta installato il sistema operativo con il minimo necessario,  (consumo di 50 MB di RAM con SSH Server e Webmin, e con tempi di boot di 7 secondi circa 😉 ) ho scaricato dal sito ufficiale di Vmware l’ultima versione di Vmware Server 2 per sistemi Linux 64 bit. Tuttavia nell’installare il pacchetto ufficiale ho riscontrato alcune difficoltà, perchè il setup spesso e volentieri andava in errore durante la compilazione.

Googlando un pò ho scoperto che è un problema che hanno avuto in parecchi, un problema abbastanza ostico da rimediare manualmente. Fortunatamente ho trovato una patch che risolve il problema, e che segnalo a tutti i lettori di questo post.

Installate innanzitutto i pacchetti build-essential tramite l’apposito comando apt-get install build-essential (ovviamente da root) dopo aver dato un bel apt-get update && apt-get upgrade. A questo punto copiate nella cartella /usr/src l’archivio tar.gz di Vmware Server 2, e seguite le istruzioni che vi riporto qui sotto :

cd /usr/src

wget http://www.troublenow.org/files/vmware/vmware2.0.2-on-debian6.0.1.tar.gz
tar xvzf vmware2.0.2-on-debian6.0.1.tar.gz
cd /usr/src/vmware2
sh install-vmware-2.0.2.sh

Proseguite con l’installazione e rispondete alle domande che vi verranno poste, personalizzando pure l’installazione di Vmware Server come meglio credete e in base alle vostre necessità. Il gioco è fatto e ….Buona virtualizzazione !!!

P.S. >> Ovviamente io ho equipaggiato la mia fida Debian con un filesystem affidabile come XFS (con l’aggiunta di qualche piccolo tuning). Ovviamente è una scelta dettata da esperienze precedenti che qualcuno potrà anche smentire, però sinceramente ho preferito investire i soldi in un bel server carrozzato e farci girare sopra quattro server virtuali Server 2008 R2 Enterprise. Il tutto ovviamente su una piattaforma consolidata, stabile e “sicura” 😉

Saludis

CISCO D.A.I. Module – Sopravvivere al Layer 2

31 ottobre 2009 2 commenti

Ciao a tutti cari lettori, immagino che ormai vi stavate chiedendo che fine avevo fatto e come mai non scrivevo più nulla sul mio blog; ma tra lavoro, corsi di aggiornamento e master  il tempo per bloggare e condividere in rete un pò delle proprie esperienze risulta veramente poco ormai.

Oggi però ho deciso di trovare il tempo (ad un’orario pazzo tra l’altro) per parlare del CISCO D.A.I. Module.

Dieci giorni fa mi è capitato, durante una consulenza per un’azienda della mia zona (eseguita nel dopo lavoro), di controllare come mai ultimamente ci fosse la loro rete lenta, e talmente tanto sovvracaricata da rendere lunghissima qualsiasi comunicazione host to host all’interno della LAN. Fortunatamente la mia fida amica sonda IDS, configurata su una VDI predisposta temporaneamente come segugio sul server aziendale, ha rilevato un eccesso di traffico arp e molti tentativi di arp poisoning da parte di alcuni indirizzi IP che dovrebbero solitamente essere liberi .

Controllando i log, mi sono accorto che gli IP sorgenti cambiavano senza un rigor di logica preciso e senza essere registrati nel database DHCP del server aziendale; segno quindi che qualcuno configurava a random la NIC del proprio PC in static mode e lanciava questi tentativi di avvelenamento ARP.

A questo punto per professionalità( visto che mi pagano per risolvere i problemi) e buon senso civico ho deciso di risolvere la situazione definitivamente; anche se ho deciso di risolverla a modo mio, in quanto ora questa era diventata una sfida personale tra me e lo script kiddie che stava giocando con ettercap. Poi ovviamente ho notificato al responsabile di piano questa bravata affinchè prendesse provvedimenti disciplinari verso costui.

A questo punto entra in gioco come una manna dal cielo il CISCO D.A.I. Module; ovvero il CISCO DYNAMIC ARP INSPECTION MODULE.

Questo modulo, implementato e disponibile nel firmware di molti switch CISCO Catalyst, permette di ispezionare il traffico ARP di determinate VLAN e di verificare che le arp request siano conformi. Faccio un’esempio….se sulla porta 1 l’indirizzo di MAC 00-50-56-C0-00-01 corrisponde all’IP 172.16.10.134, e tale host invia o riceve 200 arp request  D.A.I. entra in  funzione loggando poi l’accaduto.

Voi adesso vi starete chiedendo…. VERY GOOD !!! Ma come si implementa questa cosa? Che scrivevo questo post a fare sennò? Nella rete di questa azienda c’era un server DHCP dedicato, che distribuiva quindi gli indirizzamenti e le configurazioni di networking generali(DNS, WPAD, GW ecc ecc) rendendo così la cosa ancora più semplice e meno macchinosa del previsto.

Mi sono collegato sullo switch via telnet, e entrato nella console ho cominciato la mia missione come da policies seguenti:

switch-p01(config)# configure terminal

switch-p01(config)# ip dhcp snooping

switch-p01(config)# ip dhcp snooping vlan 1-32 (se volete potete modificare il range di VLAN in base alla vostra rete)

switch-p01(config)# ip dhcp snooping information option

switch-p01(config)# interface 12

switch-p01(config)# ip dhcp snooping trust

switch-p01(config)# exit

switch-p01(config)# ip dhcp snooping verify mac-address

switch-p01(config)# ip arp inspection vlan 1-32 (se volete potete modificare il range di VLAN in base alla vostra rete)

switch-p01(config)# ip arp inspection limit 15

switch-p01(config)# errdisable recovery cause arp-inspection interval 300

switch-p01(config)# ip arp inspection validate dst-mac src-mac ip

switch-p01(config)# end

switch-p01(config)# copy running-config startup-config

Cosa succede ora al nostro caro script kiddie che si stava divertendo con ettercap? Ecco qua un piccolo log della console dello switch salvato proprio per voi durante il suo tentativo massiccio che rallentava tutto.

switch-p01# Oct 20 16:42:51.873: %SW_DAI-4-PACKET_RATE_EXCEEDED: 16 packets received in 252 milliseconds on Fa0/3.
switch-p01# Oct 20 16:42:51.873: %PM-4-ERR_DISABLE: arp-inspection error detected on Fa0/3, putting Fa0/3 in err-disable state
switch-p01# Oct 20 16:42:52.877: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
switch-p01# Oct 20 16:42:53.881: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down

Avendo tentato di Poisonare tutta la LAN con ettercap, per protezione la sua interfaccia è stata messa in stato di shutdown per 300 secondi; cioè per cinque minuti esatti. Sono stato cattivo vero? Lo so, però mi sembrava un tempo utile per farlo desistere dal ritentare ancora con questi giochetti 😉

Molti di voi si staranno chiedendo….” Cosa succede se invece di poisonare tutta la LAN lo script kiddie ha già un elenco di host da poisonare oppure imposta un rate limit inferiore a quello massimo che hai impostato sopra??? ” Domanda corretta e lecita da parte vostra. Come avrete già intuito dalle righe di configurazione precedentemente descritte non ho di certo sottovalutato lo script kiddie, cercando di tener conto di tutte le varie modalità alternative con cui egli poteva eseguire l’attacco. Questo consapevole che il nostro amico ci avrebbe riprovato ancora, magari tentando di bypassare tale protezione o policy. Per sua sfortuna però, secondo le righe di sintassi che ho inserito prima, viene fatto pure un check-up sul MAC e l’indirizzo IP di sorgente/destinazione(la ciliegina sulla torta) sia a livello di ARP che di DHCP entries passanti sulle VLAN untrusted. In questo modo viene pure costruito un database in base agli indirizzi IP richiesti & poi rilasciati dal server DHCP della LAN. Insomma il suo attacco non ha più successo.

Infatti ecco a voi cosa succede sulla console dello switch a conferma di quanto detto

switch-p01# Oct 20 16:47:44.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/000c.2957.6b39/192.168.69.112/16:47:44 UTC Tue Oct 20 2009])
switch-p01# Oct 20 16:47:44.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/0016.cb97.3e33/192.168.69.31/16:47:44 UTC Tue Oct 20 2009])
switch-p01# Oct 20 16:47:45.087: %SW_DAI-4-DHCP_SNOOPING_DENY: 2 Invalid ARPs (Res) on Fa0/3, vlan 1.([000c.85a3.e080/192.168.69.11/000c.2957.6b39/192.168.69.31/16:47.44 UTC Tue Oct 20 2009])

Insomma come avrete visto dal secondo log, anche se le arp request fasulle sono in uscita lo switch le rileva e droppa tali pacchetti “manipolati” facendo passare solo le arp request/response valide originate dal client aziendale e non da ettercap.

Bene…. Anche questa volta abbiamo risolto il problema rendendo pure inoffensivo lo script kiddie e i suoi giochetti ARP. Spero che tale tutorial scritto in modo narrativo informale vi abbia soddisfatto, o comunque abbia incuriosito i colleghi in merito a tali features contro questi tipi di attacchi MITM che spesso sono un grattacapo per tanti network admin. Nel caso abbiate domande o dubbi io sono qui a disposizione; tempo permettendo.

Ciauz e alla prossima

MultiLayered Network Security

Voglio annunciarvi che è uscito il secondo whitepaper del progetto NetSecurity & Security Systems. In questo nuovo paper si parlerà dell’approccio logico / teorico alle tecniche di Multilayered Network Security; per il resto non voglio anticiparvi niente e preferisco che scoprite tutti i dettagli leggendo attentamente il PDF.

Il paper è scaricabile dall’apposita sezione apposita del blog che trovate qui

Finora coloro che l’hanno letto hanno dato un feedback positivo; spero che anche tutti voi visitatori siate dello stesso parere o che possiate aiutarmi a migliorare la qualità del suddetto argomento eventualmente.Ovviamente ogni consiglio, dubbio e domanda sono leciti e ben accetti. Sono qui a vostra disposizione come sempre 😉

Colgo l’occasione per augurarvi un buon week end

Ciauz

Windows TCP/IP Stack Hardening

Mi sembra doveroso ribadire, dopo aver spesso dato risposta in giro sui vari forum, che un metodo per proteggere il proprio pc sia proprio l’irrobustimento del sistema stesso e quindi anche delle varie aree che lo caratterizzano e che sono esposte a pericoli e bugs
Proprio in quest’ottica ci viene in aiuto l’hardening, ovvero l’insieme di tutte quelle procedure di irrobustimento di un sistema operativo,  che comprende anche l’hardening dello stack TCP/IP  che spesso viene lasciato configurato di default esponendo comunque la nostra macchina a pericoli e insidie.

Lo stack TCP/IP è il responsabile del trasporto di pacchetti di dati da una sorgente (identificata da un indirizzo IP) ad una destinazione (identificata da un altro indirizzo IP). Se necessario, questo livello del protocollo si occupa di spezzettare i pacchetti troppo grandi in pacchetti di dimensione adatta alla rete da utilizzare.

Sostanzialmente tutte le applicazioni che fanno uso di Internet e tutte le applicazioni tradizionali che si riferiscono a LAN utilizzano IP, benché teoricamente siano possibili altre soluzioni.
Il protocollo IP è per impostazione predefinita privo di protezione. Tuttavia con l’uso e la configurazione di vari parametri nel registro di Windows è possibile aumentare il livello di protezione della rete da attacchi di tipo Denial of Service, inclusi attacchi SYS, ICMP e SNMP. Le chiavi del Registro di sistema possono essere configurate per:

– Attivare la protezione dagli attacchi di tipo SYN quando viene rilevato un attacco
– Impostare valori limite utilizzati per determinare ciò che costituisce un attacco.

Alcune chiavi e valori cui si fa riferimento in questa procedura potrebbero non essere disponibili per impostazione predefinita, in questi casi è necessario creare chiavi, valori e dati valore.

Gli interventi che ci apprestiamo a compiere potrebbero essere, se non eseguiti nel modo corretto, dannosi, per cui è importantissimo, prima di compiere qualunque azione sul registro, premunirsi di farne una copia completa.

Iniziamo : Entriamo in regedit e posizioniamoci alla seguente chiave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters

Valore: EnableDeadGWDetect – Valore consigliato: 0 [Valori validi: 0 (disabilitato), 1 (abilitato)]

1 : se si imposta EnableDeadGWDetect su 1, il protocollo TCP può rilevare i gateway inattivi. Quando il rilevamento dei gateway inattivi è abilitato, TCP può chiedere al protocollo IP (Internet Protocol) di passare a un gateway di backup se per alcune connessioni ci sono dei problemi. I gateway di backup possono essere definiti nella sezione Avanzate della finestra di dialogo di configurazione del protocollo TCP/IP tramite lo strumento Rete nel Pannello di controllo.

0 : è consigliabile impostare il valore di EnableDeadGWDetect su 0, in caso contrario un eventuale attacco potrebbe obbligare il server a cambiare gateway imponendogli di passare a un gateway indesiderato.

Valore: SynAttackProtect – Valore consigliato: 1 [Valori validi: 0 – 2]
Questo valore del Registro di sistema fa sì che il protocollo TCP regoli la ritrasmissione di SYN-ACKS. Quando lo si configura, le risposte di connessione scadono più rapidamente durante un attacco SYN (un tipo di attacco “Denial of Service”).

I seguenti parametri possono essere utilizzati con questo valore del Registro di sistema:
– 0 (valore predefinito): nessuna protezione dagli attacchi SYN
– 1: impostare SynAttackProtect su 1 per una migliore protezione dagli attacchi SYN.

Questo parametro fa sì che il protocollo TCP regoli la ritrasmissione di SYN-ACKS. Se si imposta SynAttackProtect su 1, il timeout delle risposte di connessione è più veloce qualora il sistema rilevi un attacco SYN in corso. Per determinare se è in corso un attacco, Windows utilizza i valori seguenti:
– TcpMaxPortsExhausted
– TCPMaxHalfOpen
– TCPMaxHalfOpenRetried

Nome valore: TcpMaxPortsExhausted – Valore consigliato: 0 [Valori validi: 0 – 65535]
specifica il limite di richieste di connessione TCP che deve essere superato prima di attivare la protezione dagli attacchi SYN.

Nome valore: TcpMaxHalfOpen – Valore consigliato: 64 [Valori validi: 100 – 65535]
quando SynAttackProtect è attivato, questo valore specifica il limite di connessioni TCP nello stato SYN_RCVD. Al superamento del valore SynAttackProtect viene attivata la protezione dagli attacchi di tipo SYN.

Nome valore: TcpMaxHalfOpenRetried – Valore consigliato: 400 [Valori validi: 80 – 65535]
quando SynAttackProtect è attivato, questo valore specifica il limite di connessioni TCP nello stato SYN_RCVD per cui è stata inviata almeno una ritrasmissione. Al superamento del valore SynAttackProtect viene attivata la protezione dagli attacchi di tipo SYN.

Nome valore: TcpMaxConnectResponseRetransmissions
– Valore consigliato: 2 [Valori validi: 0 – 255]
controlla il numero di ritrasmissioni di un SYN-ACK prima di annullare il tentativo di risposta a una richiesta SYN.

Nome valore: TcpMaxDataRetransmissions – Valore consigliato: 3 [Valori validi: 0 – 65535]
specifica il numero di volte in cui TCP ritrasmetterà un singolo segmento di dati (non di connessione) prima di annullare la connessione

Nome valore: EnablePMTUDiscovery – Valore consigliato: 1 [Valori validi: 0, 1]
se questo valore è impostato su 1 (valore predefinito), il protocollo TCP deve individuare l’unità massima di trasmissione o il pacchetto con la dimensione maggiore nel percorso di un host remoto. Un pirata informatico può forzare la frammentazione del pacchetto e quindi sovraccaricare lo stack. Specificando il valore 0, verrà imposta la MTU di 576 byte per le connessioni da host non inclusi nella subnet locale.

Nome valore: KeepAliveTime – Valore consigliato: 300000 [Valori validi: 80 – 4294967295]
specifica la frequenza con cui il protocollo TCP tenta di verificare se una connessione inattiva è ancora intatta inviando un pacchetto keep-alive

Nome valore: NoNameReleaseOnDemand – Valore consigliato: 1 [Valori validi: 0, 1]
specifica che il computer non deve rivelare il nome NetBIOS quando riceve una richiesta di rilascio dei nomi.

Nome Valore: DisableIPSourceRouting – Valore consigliato: 1 [Valori validi: 0, 1, 2]
disattiva l’origine routing IP, che consente a un mittente di determinare la route che un datagramma deve seguire attraverso la rete.

Nome Valore: EnableFragmentChecking – Valore consigliato: 1 [Valori validi: 0 (disabilitato), 1 (abilitato)]
impedisce allo stack IP di accettare pacchetti frammentati

Nome Valore: EnableMulticastForwarding – Valore consigliato: 0 [Intervallo valido: 0 (false), 1 (true)]
il servizio di routing si basa su questo parametro per determinare se i pacchetti multicst IP debbano essere inoltrati o meno. Questo parametro viene creato dal servizio Routing e accesso remoto.

Nome Valore: IPEnableRouter – Valore consigliato: 0 [Intervallo valido: 0 (false), 1 (true)]
l’impostazione di questo parametro su 1 (true) consente al sistema di inoltrare i pacchetti IP alle reti a cui è connesso.

Nome Valore: EnableAddrMaskReply – Valore consigliato: 0 [Intervallo valido: 0 (false), 1 (true)]
questo parametro stabilisce se il computer deve rispondere a una richiesta di maschera indirizzo ICMP.

Ora rechiamoci alla chiave:

HKLM\System\CurrentControlSet\Services\AFD\Parameters

Nome Valore: EnableICMPRedirect – Valore consigliato: 0 [Valori validi: 0, 1]
se si modifica questo valore su 0, viene impedita la creazione di route host dispendiose in seguito alla ricezione di un pacchetto di reindirizzamento ICMP.

Nome Valore: EnableDynamicBacklog – Valore consigliato: 1 [Valori validi: 0 (disabilitato), 1 (abilitato)]
specifica che la funzionalità AFD.SYS dovrà gestire un numero elevato di connessioni SYN_RCVD in modo efficace.

Nome valore: MinimumDynamicBacklog – Valore consigliato: 0 [Valori validi: 0 – 4294967295]
specifica il numero minimo di connessioni disponibili consentito per un endpoint in ascolto. Se il numero di connessioni disponibili risulta inferiore a questo valore, viene inserito un thread nella coda per creare altre connessioni disponibili.

Nome valore: MaximumDynamicBacklog – Valore consigliato: 20 [Valori validi: 0 – 4294967295]
specifica il numero totale delle connessioni disponibili e di quelle in stato SYN_RCVD.

Nome valore: DynamicBacklogGrowthDelta – Valore consigliato: 0 [Valori validi: 0 – 4294967295]
quando sono necessarie altre connessioni, specifica il numero di connessioni disponibili che devono essere create.

Articolo formatted by:  PIANETAPC.IT