Archivi categoria: Sicurezza

PENETRATION TEST

Penetration Test

Penetration Test

 

Oggi giorno tutto e’ e sara’ sempre piu’ connesso o interconnesso in rete, dalle nostre vite sociali, ai dati aziendali fino all’ultima frontiera rappresentata dall’Internet delle Cose IoT, che è un neologismo riferito all’estensione di Internet al mondo degli oggetti e dei luoghi concreti.

Tutto questo scambio continuo di dati (foto, login, codici…) richiede che le aziende incaricate di mantenere al sicuro i nostri dati piu’ importanti debbano essere sempre preparati dal pericolo sempre maggiore di un’intrusione, in effetti il comportamento non sarebbe diverso da una squadra di vigili del fuoco che si allenano costantemente simulando ogni tipologia di situazione cosi da sapere sempre cosa fare, come risolvere e se possibile come prevenire un disastro.

Una delle metodologie a cui dovrebbero affidarsi i team di sicurezza interni, o tramite specifiche consulenze, sono i cosidetti PENETRATION TEST.
Che cosa s’intende quando si usa questo termine? Il penetration test è la metodologia di valutazione della sicurezza di un sistema o di una rete. L’analisi comprende più fasi ed ha come obiettivo evidenziare le debolezze della piattaforma fornendo il maggior numero di informazioni sulle vulnerabilità che ne hanno permesso l’accesso non autorizzato. L’analisi è condotta dal punto di vista di un potenziale attaccante e consiste nello sfruttamento delle vulnerabilità rilevate al fine di ottenere più informazioni possibili per accedere in modo fraudolento al sistema. Un pen-test dunque consiste nel testare la sicurezza di un sistema cercando di violarlo sottoponendolo ad una grande varietà di attacchi informatici e non. L’obiettivo è quello di individuare eventuali vulnerabilità sfruttabili da terzi per ottenere accessi non autorizzati ai servizi e ai sistemi analizzati.

Oltre ai problemi di sicurezza, devono essere rilevati, quali possibili punti deboli, i problemi relativi alla configurazione, il cosidetto “tuning“, che incidono sulla robustezza e le performance del sistema, e gli errori di progettazione della rete. Non a caso, a volte una cattiva configurazione è più pericolosa di un bug.

Questa e’ una lista sintetica che descrive cio che un pen-tet cerca d’individuare:

  • bug, vulnerabilità e security hole nel software presente;
  • punti deboli nella progettazione della rete;
  • punti deboli di firewall e router;
  • punti deboli negli script dei web-server;
  • errori nella configurazione dei principali servizi in esecuzione;
  • problemi relativi l’accesso fisico alle macchine.

Una volta portato a termine il test, tutti i problemi di sicurezza rilevati vengono presentati al cliente o alla propria direzione informatica assieme ad una valutazione del loro impatto nel sistema e nello scenario del business aziendale, fornendo inoltre una soluzione tecnica o proposta di migrazione e mitigazione del sistema.

Il penetration test ci fornisce quindi una stima chiara sulle capacità di difesa e del livello di penetrazione raggiunto nei confronti di problematiche quali:

  • vulnerabilità interne al sistema;
  • vulnerabilità esterna al sistema;
  • difetti sicurezza fisica

Quali sono le modalita’ in cui i Penetration Tester svolgono il loro ruolo ??
I processi di penetration test possono essere effettuati in diverse modalità. La differenza consiste sulla quantità e qualità delle informazioni disponibili a coloro che devono effettuare l’analisi riguardo ai sistemi analizzati. I processi di analisi che vengono condotti in un penetration test hanno diversi tempi di azione in cui vengono alternate fasi manuali e fasi automatiche. Vengono acquisite inizialmente le informazioni principali sull’architettura della piattaforma e sui servizi offerti. Dall’analisi di questi dati deriva la scelta di come condurre il passo successivo, consistente in una enumerazione dei principali errori e problemi. Subentrano cosi nell’equazione i Penetration Tools che, uniti all’esperienza manuale dell’analista permettono quindi di evidenziare tutte le possibili vulnerabilità, incluse quelle più recenti e, a volte, alcune ancora non di pubblico dominio. I problemi riscontrati sono quindi manualmente verificati.

L’attività si considera conclusa una volta portata a termine la reportistica composta dal report di analisi sommaria dedicato al management o executive summary, contenente l’analisi dell’impatto di rischio di quanto riscontrato e tempistiche per l’azione di rientro o mitigazione delle problematiche riscontrate, e dal report tecnico, contenente l’analisi dettagliata dei problemi e la soluzione tecnica.

Va aggiunto per maggiore chiarezza che il penetration test va effettuato su sistemi esposti su Internet e comunque sulle piattaforme sensibili collegate a grosse reti, testando le vulnerabilita’ sia con attacchi esterni alla rete che con attacchi dall’interno della stessa e, possibilmente gia prima prima che esse entrino nella fase di completo esercizio.
Possiamo distinguere vari livelli tecnici dei test, piu’ a grandi linee si possono delineare tre grandi categorie:

  • livello basso: questo è il test che in genere fanno i tool di auditing automatici, a la Nessus per intenderci. Si controlla solo se ci sono servizi in esecuzione con vulnerabilità note, in genere vengono rilevate solo grosse falle e misconfigurazioni macroscopiche.
  • livello medio: oltre a controllare i servizi in esecuzione, viene testata la rete, i firewall, i router, etc…, e si fa spesso ricorso anche a tecniche di social engineering.
  • livello alto: qui siamo a livelli paranoici, si può arrivare a controllare i sorgenti (se disponibili) dei programmi alla ricerca di nuove vulnerabilità (quindi meglio optare per software open source e li dove e’ possibile per far sviluppare internamente cio di cui si ha bisogno), o ad esercitare la tecnica denominata del trashing detto anche information diving, che è la pratica di risalire ad informazioni riservate attraverso il setacciamento dei rifiuti della vittima, come resoconti, bollette, corrispondenza. Una delle tecniche preferite dal famoso Kevin Mitnick.

Mettendo insieme tutte queste metodologie ed informazioni possiamo darvi un piccolo scenario di cio che viene eseguito, a grandi linee, durante un’attacco:

  • Ricognizione di base: informazioni dal sito, informazioni sul dominio e sull’amministratore. A volte basta visitare il sito per raccogliere importanti notizie sul software presente sul server, spesso infatti in fondo all’home page i webmaster inseriscono notizie sul sistema operativo, webserver, etc…., come ad esempio trovare indicazioni come queste “Powered by Apache, Linux Inside…” , mettono a rischio i sistemi.
  • Ricostruzione della struttura interna della rete
  • Raccolta Info:Una volta identificata la struttura della rete e il numero di macchine bisogna raccogliere il maggior numero di informazioni su ognuna di esse. Quindi occorre ricercare i servizi in esecuzione, identificare i sistemi operativi, la versione dei servizi, il tipo di processore, i nomi utente (standard e non), le risorse condivise, etc.
  • Tracciamento vulnerabilita‘: dopo aver determinato i tipi di servizi attivi sull’host bersaglio si deve tracciare una mappa delle vulnerabilità, e occorre ricercare (o scrivere) gli exploit applicabili contro i servizi bersaglio.
  • Analisi della topologia della rete.
  • Applicazione degli exploit.
  • Verifica della possibilità di sniffing e tentativi di DoS & DDoS.
  • Test su router e firewall.
  • Pulizia delle tracce dell’attacco.
  • Stesura del report.

Al termine degli attacchi e della valutazione dei log raccolti un sistema potra’ dirsi vulnerabile se è possibile:

  • accedere a risorse interne;
  • leggere e modificare file riservati;
  • controllare il traffico in entrata e/o uscita;
  • eseguire programmi senza averne i permessi;
  • accedere alla macchina con i permessi di amministratore (root) da parte di utenti non privilegiati;
  • controllare la configurazione della rete e dei servizi.

Punti critici:
cerchiamo ora di evidenziare i lati negativi del preparare un pen-test che purtroppo e’ un po come fare i lavori di casa mentre voi ci abitate dentro……
I punti critici da prendere in considerazioni sono: trattamento dei dati raccolti, salvaguardia dei sistemi e dei dati, riservatezza riguardo le vulnerabilità emerse durante il pen-test. Durante il penetration test potrebbero verificarsi dei disagi dovuti al lavoro del tester, si potrebbero avere perdite o danni ai dati o ancora una momentanea perdita di accessibilità. Ad esempio una macchina dedicata all’e-commerce potrebbe rimanere inaccessibile a causa di una simulazione di un DoS, con conseguenze economiche dirette. O ancora, una azienda che fornisce servizi a terzi, potrebbe vedere i propri servizi interrotti con evidente disagio per i clienti.
Prima di cominciare il test bisogna concordare quale livello di rischio il committente è disposto a correre, invitandolo anche a fare un backup dei dati prima di effettuare il pen-test. Bisogna prevedere tali evenienze in fase di stipula del contratto, declinando per quanto possibile le responsabilità e garantendo però, allo stesso tempo, adeguate misure per il recupero del sistema.

Per ultimare questa carellata sul valore di un Pen-test aggiungo che il suo valore è strettamente legato alle capacità del tester, dunque affidiamoci soltanto a persone preparate che possono dimostrare esperienza pratica svolta su clienti tracciabili; inoltre esso perde di validità non appena si apportano modifiche (anche minime) alla configurazione di una macchina interessata al test, quindi è consigliabile eseguire un pen-test poco prima di mettere in produzione la rete. Inoltre anche lasciando inalterate le macchine testate, il pen-test dovrebbe essere ripetuto periodicamente, poichè oggi giorno vengono trovate quotidianamente nuove vulnerabilità e nuovi exploit.

Semplificate i vostri Firewall

Ipset facilita il Firewall

Ipset facilita il Firewall

Facilitare la gestione del Firewall usando IPSET

Premessa
iptables, che fa parte del più ampio framework netfilter, è notoriamente il tool in user-space destinato alla definizione delle regole di firewall del kernel Linux.

Ipset è una estensione per iptables che permette la creazione di regole firewall applicabili contemporaneamente ad interi insiemi di indirizzi. A differenza di quanto avviene nelle normali catene iptables, che sono memorizzate e traversate linearmente, i sets sono memorizzati in strutture dati indicizzate, caratteristica che ne rende la consultazione molto efficiente, anche in presenza di sets voluminosi, oltre che in situazioni dove è facile immaginarne l’utilità, come il blocco di lunghe liste di “bad” hosts senza doversi preoccupare dell’eccessivo impiego di risorse di sistema o della congestione di quelle di rete, ipset offre anche un nuovo approccio a determinati aspetti inerenti la progettazione di un firewall, semplificandone la configurazione.

Ipset e’ composto da due parti, un modulo kernel e, uno strumento di amministrazione, alcune distribuzioni includono anche dei wrapper di servizio per caricare configurazioni ipset al boot, come l’ipset-service di Fedora.

Prima di proseguire è doveroso spendere un po’ di tempo a rinfrescare alcuni concetti fondamentali di iptables.

In sintesi, la configuratione di un firewall iptables consiste di un set di “chains” built-in (raggruppate in quattro “tables”) che contengono ciascuna una lista di regole o “rules”.

Per ciascun pacchetto, in ciascuna fase del suo trattamento, il kernel consulta la chain appropriata per determinarne il destino.
Le chains vengono consultate in rigoroso ordine, basato sulla direzione del pacchetto (remoto->locale, remoto->remoto oppure locale->remoto) e la sua fase corrente di trattamento o processing (prima o dopo il “routing”).

Il pacchetto viene confrontato con ciascuna delle regole della chain, nell’ ordine, fino a che non viene trovata una corrispondenza. Una volta che ciò avviene, viene intrapresa la azione specificata nel target della regola.
Se viene invece raggiunta la fine della chain senza trovare una corrispondenza, viene intrapresa la azione target di default per la catena, o policy.

Una chain non è altro che una lista ordinata di regole, ed una regola non è altro che una combinazione corrispondenza/target.
Un semplice esempio di corrispondenza è “TCP destination port 25″.
Un semplice esempio di target può essere “scarta il pacchetto” (DROP).
I targets possono anche redirigere ad altre chains definite dall’utente, cosa che fornisce un meccanismo per raggruppare e suddividere le regole seguendo una logica.
Ciascun comando iptables destinato a definire una regola, corto o lungo che sia, è composto di tre parti fondamentali che specificano la table/chain, la corrispondenza (match) ed il target

Per creare una completa configurazione firewall, occorre di fatto mandare in esecuzione una serie di comandi iptables, in uno specifico ordine.

ipset
ipset è una “match extension”, cioè una estensione basata sulla definizione di corrispondenze, per iptables.
Per poterla usare è prima necessario creare e popolare dei “sets” univocamente chiamati utilizzando il tool a linea di comando ipset, e successivamente fare riferimento a tali sets in una o più regole iptables.

Un set può essere semplicemente una lista di indirizzi archiviata per un efficiente ritrovamento.
Prendiamo come riferimento i seguenti normali comandi iptables destinati a bloccare il traffico in ingresso proveniente da 201.121.12.1 e 202.121.12.2:

# iptables -A INPUT -s 201.121.12.1 -j DROP
# iptables -A INPUT -s 202.121.12.2 -j DROP

La sintassi che specifica la corrispondenza (-s 201.121.12.1) significa “i pacchetti il cui indirizzo di origine è 201.121.12.1″. Per bloccare sia 201.121.12.1 che 202.121.12.2, devono venire definite due distinte regole iptables con due distinte specificazioni di corrispondenza (una per 201.121.12.1 ed una per 202.121.12.2).

In alternativa, i seguenti comandi ipset/iptables servono ad ottenere lo stesso risultato:

# ipset -N myset iphash
# ipset -A myset 201.121.12.1
# ipset -A myset 202.121.12.2
# iptables -A INPUT -m set --set myset src -j DROP

I comandi ipset appena visti creano un nuovo set (myset, del tipo iphash) con due indirizzi (201.121.12.1 e 202.121.12.2).
Il successivo comando iptables fa quindi riferimento al set specificando la corrispondenza con -m set –set myset src, che significa “i pacchetti il cui source header è compreso nel set di nome myset”.
Il flag src significa che la corrispondenza deve avvenire su “source”. Analogamente il flag dst avrebbe spostato la corrispondenza su “destination”, mentre il flag src,dst avrebbe riguardato sia source che destination.

Nella seconda versione è richiesto un solo comando iptables, indipententemente da quanti indirizzi IP siano presenti nel set.
Anche se fossero migliaia, sarebbe necessaria sempre una singola regola iptables, mentre l’approccio tradizionale, senza il vantaggio offerto da ipset, richiederebbe migliaia di regole.

Tipi di set
Ciascun set è di uno specifico tipo, che definisce che genere di valore possa esservi memorizzato (indirizzi IP, networks, porte ecc.) così come debba essere ricercata la corrispondenza (ovvero, quale parte del pacchetto debba essere controllata e come debba essere confrontata coi valori presenti nel set).
Oltre ai tipi più comuni, che controllano gli indirizzi IP, ne sono disponibili addizionali che si riferiscono alla porta, sia all’indirizzo IP che alla porta contemporaneamente, oppure contemporaneamente al MAC address e all’indirizzo IP, ecc.

Ciascun tipo di set ha le proprie regole per tipo, range e distribuzione dei valori che può contenere.
Differenti tipi di set usano anche differenti tipi di indici e risultano ottimizzati per differenti scenari. La scelta del migliore o più efficiente tipo di set dipende quindi dalla situazione.

I tipi più flessibili di set sono iphash, che archivia liste di indirizzi IP arbitrari, e nethash, che archivia liste di networks eterogenee (IP/mask) di varie dimensioni. Si faccia comunque riferimento all man page di ipset per un elenco completo ed una descrizione di tutti i tipi di set.

È anche disponibile il tipo speciale setlist, che consente di raggruppare insieme differenti sets in un set unico.
È vantaggioso se si desidera, ad esempio,avere un singolo set che contenga sia singoli indirizzi IP che networks.

Faccio ora un esempio per capire meglio la potenza di ipset:

Limitare l’accesso restringendolo solo a certi hosts pubblici da parte di certi PC della rete locale
Supponiamo che nell’ufficio di cui gestite la rete passino spesso stagisti e che il megadirettore sia molto infastidito dall’idea che questi impiegati, Pippo, Pluto e Paperino possano passare il tempo a trastullarsi con Internet invece di lavorare e vi chieda di limitare l’accesso da parte dei loro PCs a uno specifico set di siti cui è necessario collegarsi solo per lavoro.
Per limitare i tre PC (192.168.0.5 è quello di Pippo, 192.168.0.6 quello di Pluto e 192.168.0.7 quello di Paperino) ad accedere solamente a corriere.it, repubblica.it e inps.it, si possono utilizzare i seguenti comandi:

# ipset -N limited_hosts iphash
# ipset -A limited_hosts 192.168.0.5
# ipset -A limited_hosts 192.168.0.6
# ipset -A limited_hosts 192.168.0.7
# ipset -N allowed_sites iphash
# ipset -A allowed_sites corriere.it
# ipset -A allowed_sites repubblica.it
# ipset -A allowed_sites inps.it
# iptables -I FORWARD \
-m set --set limited_hosts src \
-m set ! --set allowed_sites dst \
-j DROP

Questo esempio effettua un confronto con due sets in una singola regola. Se il l’indirizzo sorgente è compreso in limited_hosts e la destinazione non è compresa in allowed_sites, il pacchetto viene semplicemente scartato (a limited_hosts è permesso comunicare solamente con allowed_sites).

Si noti che dato che questa regola si trova nella chain FORWARD, non riguarda le comunicazioni da e verso il firewall stesso nè il traffico interno.

Cosi’ come per iptables, ipset vi permette di caricare le regole da un file ed effettuare l’output in un formato adatto al caricamento, nel seguente modo :

# ipset save > /path/to/ipset.save
# ipset restore < /path/to/ipset.save

Ipset vi permettera’ di mantenere la configurazione del vostro firewall piu’ corta, leggibile e molto piu’ facile da mantenere. Se vi servono ulteriori informazioni potete visitare il sito del progetto http://ipset.netfilter.org

 

#IpsetfacilitailvostroFirewall

Proteggere i Server da attacchi SlowHTTP/Slowloris

SlowHTTP difendersi da attacchi DDOS

SlowHTTP difendersi da attacchi DDOS

Gli attacchi del tipo SlowHTTP/Slowloris sono tra i più fastidiosi da ricevere in quanto il server di per sè non riporta nessuna anomalia se non un elevato numero di processi attivo, ma senza carico effettivo sulla macchina, questo perchè l’attacco apre quante più connessioni possibili al webserver e le lascia aperte inviando saltuariamente qualche header per mantenere aperta la connessione saturando di fatto il numero massimo di connessioni che il server può gestire e rendendolo irraggiungibile.

N.B.: con il termine attacco Slowloris s’intende un tipo di attacco chiamato Distributed Denial of Service (DDoS) che, in questo caso, sfrutta lo script Slowloris, scritto da Robert Hansen, grazie a cui vengono create una serie di connessioni web con lo scopo di inviare una enorme quantità di dati al server vittima in modo da renderlo inutilizzabile per gli utenti.

Un’ attacco con tale script permette tra l’altro ad una singola macchina attaccante di occupare le risorse di un server con un’ampiezza di banda minima e limitati effetti collaterali a servizi e porte non coinvolte.

Slowloris prova a mantenere le connessioni aperte ad un server web obiettivo e trattenerle aperte il più a lungo possibile. Fa questo, aprendo le connessioni al server web obiettivo e inviandogli richieste parziali. Periodicamente, invierà le successive intestazioni HTTP, aggiungendo ma mai completando la richiesta. I server attaccati terranno così le connessioni aperte, riempiendo il loro numero di connessioni disponibili, infine negando ulteriori tentativi di connessione dai client. Viene spesso usato anche per effettuare verifiche sulla stabilità di server, che forniscono servizi sotto stress.

Per proteggersi da questo tipo di attacchi si ricorre a degli escamotage, uno dei quali è limitare il numero di connessioni massime per IP in modo da evitare che questo possa intasare il server, per proteggere un server con directadmin, come pannello di gestione, e apache da questo tipo di attacchi basta semplicemente lanciare i seguenti comandi da root

cd /root
wget ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/installoris

chmod 755 installoris
./installoris

come segnalato sul sito di DirectAdmin

questi comandi non faranno altro che scaricare e installare il modulo mod_antiloris per apache (httpd), installarlo e riavviarlo.

 

#DifendersidaAttacchiSlowHTTP

 

Proteggiti dagli attacchi brute force con APF BFD e DDOS Deflate

APF & BFD difenditi dai Brute Force

APF & BFD difenditi dai Brute Force

Usare password lunghe e complesse spesso non è sufficiente a proteggere il proprio server da eventuali intrusioni, proprio per questo oggi spieghiamo come proteggerli da attacchi di tipo brute force utilizzando due semplici software che sfruttano il firewall iptables.

Questi due software vengono distribuiti gratuitamente dal sito http://www.rfxn.com/ . Vediamo quindi nel dettaglio cosa fanno e come configurarli.


APF

Partiamo da APF (advanced policy firewall), questo software è una sorta di configuratore per iptables, che ci permette di configurare in modo semplice e rapido le regole base di iptables come ad esempio le porte da aprire in base ai servizi che utilizziamo, il tutto a partire da un semplice file di configurazione molto dettagliato e con ogni opzione ben commentata.

INSTALLAZIONE
Per installarlo basta scaricare il pacchetto http://www.rfxn.com/downloads/apf-current.tar.gz e decomprimerlo (per versioni ubuntu/debian possiamo usare sudo apt-get install apf-firewall).

wget http://www.rfxn.com/downloads/apf-current.tar.gz

tar zxf apf-current.tar.gz

ora entriamo nella directory appena estratta e installare APF

cd apf-9.7-2/

./install.sh

Installing APF 9.7-2: Completed.

Installation Details:
Install path: /etc/apf/
Config path: /etc/apf<firewall>/conf.apf
Executable path: /usr/local/sbin/apf

Other Details:
Listening TCP ports: 21,22,80,631,3306,5900,15749,17500
Listening UDP ports: 5353,15749,17500,38366
Note: These ports are not auto-configured; they are simply presented for information purposes. You must manually configure all port options.
ora andiamo a modificare il file di configurazione /etc/apf<firewall>/conf.apf

DEVEL_MODE="1"
questo parametro indica se apf è in modalità sviluppo (e quindi non applica le regole) o in modalità produzione e quindi rende effettive le regole del firewall, prima di impostarlo a 0 per renderlo attivo modifichiamo il resto delle regole altrimenti rischiamo di chiuderci fuori dal server

Impostiamo le porte in ascolto modificando il paramentro IG_TCP_CPORTS

# Common inbound (ingress) TCP ports
IG_TCP_CPORTS="22,21,20,80,25,53,110,143,443,2222,587,953,993,995,4949"
esempio d'impostazioni che sono valide per i servizi ssh,ftp,web,mail (pop/imap/smtp),directadmin e munin

questi invece gli esempi per le impostazioni per le porte in uscita

# Common outbound (egress) TCP ports
EG_TCP_CPORTS="21,25,80,443,43"
e poi più sotto impostiamo a “1″ le seguenti variabili che ci permettono di scaricare delle liste di ip conosciuti come malevoli in modo da filtrare a priori il loro traffico

DLIST_PHP="1"
DLIST_SPAMHAUS="1"
DLIST_DSHIELD="1"
DLIST_RESERVED="1"

ora salviamo ed avviamo apf tramite il comando

apf -s

BFD
Ora passiamo a BFD (brute force detection) il quale è un software che, analizzando i log, rileva i tentativi
d’intrusione ai servr con metodologia Brute Force, ciò significa che se qualcuno tenta di accedere alla nostra macchina per bucarla, nei log di sistema, BFD troverà traccia dei vari tentativi, e se questi superano una soglia, che possiamo impostare, banna gli ip responsabili tramite APF.
Procediamo con il download (http://www.rfxn.com/downloads/bfd-current.tar.gz) e l’installazione

wget http://www.rfxn.com/downloads/bfd-current.tar.gz
tar zxf bfd-current.tar.gz
cd bfd-1.5/2/
./install.sh

A differenza di apf, bfd viene installato in /usr/local/bfd, procediamo ora alla modifica del fine di configurazione /usr/local/bfd/conf.bfd

# how many failure events must an address have before being blocked?
# you can override this on a per rule basis in /usr/local/bfd/rules/
TRIG="15"

# send email alerts for all events [0 = off; 1 = on]
EMAIL_ALERTS="1"

# local user or email address alerts are sent to (separate multiple with comma)
EMAIL_ADDRESS="<your@email.com>"

# subject of email alerts
EMAIL_SUBJECT="Brute Force Warning for $HOSTNAME"

la prima variabile indica il numero di eventi che devono esser trovati nei file di log per scatenare il ban, questa impostazione può essere modificata successivamente servizio per servizio mentre EMAIL_ALERTS,EMAIL_ADDRESS e EMAIL_SUBJECT servono per ricevere una copia via email dei vari attacchi rilevati e delle azioni intraprese da bfd per bloccare eventuali nuovi attacchi dall’host.

# syslog auth log path
AUTH_LOG_PATH="/var/log/auth.log"

verificate anche che questo file punti correttamente al vostro auth log (di default nell’installazione bfd punta a /var/log/secure)

e come ultima cosa modificate il file /etc/cron.d/bfd e rimuovete le seguenti righe altrimenti il cron non funzionerà

MAILTO=
SHELL=/bin/bash

a questo punto anche bfd è installato e funzionante;

Per avviare BFD usiamo il seguente comando :

# sudo /usr /local /sbin /BFD – s

DDOS Deflate

E’ un piccolissimo script in bash che serve a prevenire attacchi di tipo DoS o DDOS. Principalmente si basa sempre sul blocco degli indirizzi ip come mod_evasive, se quest’ultimi inviano “X” richieste al server in modo continuativo. In tal caso lo script attiva il firewall del server.

Vediamo come installarlo

Installare DDOS Deflate
dalla vostra shell di Linux, lanciate questo comando:

wget http://www.inetbase.com/scripts/ddos/install.sh

Successivamente andranno impostati i permessi al file ed eseguire l’installazione
chmod 0700 install.sh

./install.sh

Leggerete la lincenza dello script, quindi premete
q

Potrete leggere a video che è stato creato un file di configurazione ddos.conf nella directori /usr/local/ddos/
Possiamo notare come lavora in cron lo script, lanciando il comando
ls -l /etc/cron.d

 

#DifenditidagliattacchiBruteForce

Proteggiti da attacchi DoS e DDoS

APF-Firewall Server Protection

APF-Firewall Server Protection

Proteggere il server dagli attacchi DoS e DDoS 

Un attacco DoS (Denial of Service), ha come scopo il rendere inutilizzabile un determinato servizio sul web, inondandolo di richieste fittizie, quindi qualsiasi servizio esposto su internet che fornisce servizi di rete basati sul protocollo TCP/IP e soggetto al potenziale rischio di attacchi DoS. La differenza tra DoS e DDoS (Distributed Denial of Service) sta nel numero di macchine (PC, server, cellulari, in generale, qualsiasi dispositivo connesso ad internet che sia stato compromesso) utilizzate per lanciare l’attacco. Nel caso di un DoS l’attacco avviene da una sola macchina, mentre (nel ben piu difficile caso da bloccare) nel DDoS l’attacco puo avvenire contemporaneamente da centinaia di macchine diverse.

Come potrete quindi immaginare tutti i consigli contenuti in questo articolo non vi assicureranno una protezione totale contro i DDoS, perché quando sono ben organizzati e l’attacco arriva da un grande numero di macchine diverse, l’unico modo per cercare di bloccarlo o più realisticamente, mitigarlo, è agire a monte, direttamente sull’infrastruttura del vostro provider (che quindi dovrete contattare), a meno che non abbiate una vostra infrastruttura di rete.

Come riconoscere un attacco ?

Questa è sicuramente la prima cosa da imparare, ossia imparare a riconoscere un attacco DoS, perche’ tante volte si corre il rischio di pensare ad un attacco di questo tipo appena i servizi ospitati sul server risultano irraggiungibili, quando invece le cose più probabili sono ben altre.
Innanzitutto se siete sotto attacco vedrete sicuramente un picco (che può variare da pochi a diversi mbit/s) nei vostri grafici della banda utilizzata, ed un picco nelle connessioni netstat, anche per questo sarebbe bene generare dei grafici di tutto rispetto magari tramite Munin (di cui parleremo nel prossimo articolo) o con Vnstat, i servizi più importanti sul vostro server.

Una volta accertato che ci sono effettivamente picchi anomali nell’utilizzo della banda, usate questo comando per visualizzare lo stato di tutte le connessioni attive sul vostro server:

netstat -nat | awk ‘{print $6}’ | sort | uniq -c | sort –n

L’output sarà qualcosa del genere:

1 CLOSING

1 established

1 Foreign

7 LAST_ACK

25 FIN_WAIT1

26 LISTEN

69 FIN_WAIT2

484 TIME_WAIT

542 ESTABLISHED

Se notate che ci sono diverse connessioni in stato SYS_SENT siete sicuramente sotto attacco, a questo punto non resta altro da fare che individuare l’IP o gli IP dai quali arrivano più connessioni, potete farlo con questo comando:

netstat -atun | awk ‘{print $5}’ | cut -d: -f1 | sed -e ‘/^$/d’ |sort | uniq -c | sort –n

A questo punto avrete una lista ordinata per numero di connessioni aperte da ogni IP, ed alla fine, molto probabilmente, avrete gli IP delle macchine dalle quali vi stanno attaccando, ora non resta che bloccare questi IP.
Una utility molto utile per analizzare il traffico di rete e vederlo in tempo reale è tcptrack, una volta installata usate i seguenti comandi per avviare il monitoring:

tcptrack -i eth0 vi mostrerà tutto il traffico attivo sulla scheda di rete

tcptrack -i eth0 port 80 vi mostrerà tutto il traffico sulla porta 80

Es:

tcptrack -i eth0 src or dst 192.168.2.138

vi mostrerà tutto il traffico generato dall’ip specificato. In più tcptrack vi mosterà in tempo reale l’utilizzo della banda.

Bloccare un attacco

Ora che sappiamo individuare un attacco e capire da quali IP sta arrivando possiamo cercare di bloccarlo, vediamo come.
Premesso che la cosa migliore sarebbe comunicare gli IP degli attaccanti al vostro provider così che possano essere bloccati a monte e che non possano quindi influire neanche minimamente sulla vostra banda disponibile, esistono principalmente due metodi per bloccare questi IP sul vostro server: bloccarli con iptables, oppure metterli in nullroute (che è, secondo me, preferibile).

Per bloccare questi IP da itptables potete usare questo semplice comando:

iptables -A INPUT -s IP-ATTACCANTE -j DROP

Invece, per mettere un IP in nullroute, dobbiamo lanciare questo comando:

route add IP-ATTACANTE gw 127.0.0.1 lo

Possiamo anche mettere in nullroute un’ intera subnet ad esempio così:

route add -net 192.168.2.0/24 gw 127.0.0.1 lo

Verifichiamo quindi che i settaggi siano stati effettivamente applicati con

netstat -nr

Per rimuovere il nullroute possiamo utilizzare il comando route delete IP

Per far sì che i nullroute impostati vengano mantenuti al reboot dovrete scrivere gli stessi comandi di prima nel file /etc/rc.local


Come prevenire gli attacchi

Fin’ora abbiamo visto come comportarci una volta sotto attacco, ora vediamo cosa possiamo fare per evitare di trovarci coi servizi down e doverli ripristinare.
Per prima cosa consiglio di installare APF (Advanced Policy Firewall), un firewall basato su iptables che bloccherà autonomamente molti degli attacchi conosciuti, confrontandone i pattern, in più, grazie alla sua semplice e versatile configurazione diventa un’ottimo sostituto di iptables che spesso risulta abbastanza macchinoso da mantenere.

Potete installare APF usando un packet manager tipo apt o yum, oppure compilando l’ultima versione :

Scaricate l’ultima versione stabile:

wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz

Scompattate il file appena scaricato: tar -xvzf apf-current.tar.gz

Entrate nella directory creata ed eseguite ./install.sh

A questo punto APF va configurato a dovere e, per farlo, bastera’ editare il file /etc/apf/conf.apf .

Per prima cosa bisognera’ settare il parametro DEVEL_MODE a 1, così se sbagliate qualche settaggio e vi chiudete fuori dal server, dopo 5 minuti il firewall verrà automaticamente stoppato.

Questo parametro indica se apf è in modalità sviluppo (e quindi non applica le regole) o in modalità produzione e quindi rende effettive le regole del firewall, prima di impostarlo a 0 per renderlo attivo modifichiamo il resto delle regole altrimenti rischiamo di chiuderci fuori dal server

Impostiamo le porte in ascolto modificando il paramentro IG_TCP_CPORTS

# Common inbound (ingress) TCP ports
IG_TCP_CPORTS="22,21,20,80,25,53,110,143,443,2222,587,953,993,995,4949"

io utilizzo queste impostazioni che sono per i servizi ssh,ftp,web,mail (pop/imap/smtp), directadmin e munin

e queste sono le impostazioni per le porte in uscita
# Common outbound (egress) TCP ports
EG_TCP_CPORTS="21,25,80,443,43"

e poi più sotto impostiamo a “1″ le seguenti variabili che ci permettono di scaricare delle liste di ip conosciuti come malevoli in modo da filtrare a priori il loro traffico

DLIST_PHP="1"
DLIST_SPAMHAUS="1"
DLIST_DSHIELD="1"
DLIST_RESERVED="1"

Ricordatevi di rimettere su 0 questo parametro una volta terminata la configurazione, altrimenti il firewall funzionerà solo per 5 minuti ad ogni riavvio.

Settate su 1 tutti i parametri che abilitano le liste di network malefici dai quali le connessioni saranno rifiutate (DLIST_*).

Settate manualmente le porte TCP che devono rimanere aperte nella variabile IG_TCP_CPORTS (ad esempio la 80 per il traffico web, se avete modificato la porta di ssh come avreste dovuto fare ricordatevi di settarla qua, altrimenti vi chiuderete fuori dal server), tutte le altre risulteranno chiuse.

Stessa cosa per le porte UDP subito sotto, se ne fate uso.

Impostando il parametro SYSCTL_SYNCOOKIES su 1, vi proteggerà dagli attacchi di tipo syn flood.

salviamo ed avviamo apf con

apf -s

#Proteggiti#AttacchiDoSeDDoS