Archivi tag: iptables

Difenditi con ARTILLERY

Artillery Honeypot All-in-one

Artillery Honeypot All-in-one

In questo articolo parleremo di un tool che si pone come interessante aiuto verso la sicurezza delle nostre macchine in rete, il suo nome e’ Artillery , esso è un interessante software scritto interamente in python. La cosa molto interessante di questo tool e’ che lo possiamo intendere come una combinazione tra un honeypot, un tool di monitoraggio, ed un sistema di alerting. Uahoooo, tutto in un’unico strumento…….

I principi di funzionamento si caratterizzano dal fatto che in presenza di determinate attività di networking esso si comporta parzialmente come un honeypot, adottando anche manovre evasive e, contemporaneamente monitorizza il cambiamento di file sensibili; in entrambi i casi avvisando di quanto riscontrato i destinatari designati.
Artillery si pone in ascolto su di un certo numero di porte di uso comune (peraltro configurabile, tramite la variabile PORTS), e qualora riceva una richiesta di connessione per uno qualsiasi dei servizi fasulli, blocca in modo permanente l’indirizzo IP sorgente aggiungendo una relativa regola con target DROP a iptables.

Artillery può essere anche usato per prevenire attacchi di tipo brute force

L’ installazione ed il lancio di Artillery sono molto semplici: una volta effettuato il download via git, occorre lanciare uno script installer, editare un file di configurazione (“all’inizio questo passaggio sara’ meglio farlo su macchina virtuale per fare pratica della configurazione delle regole”) e poi mandarlo in esecuzione:

# cd /opt
# apt-get update && apt-get install git [solo se ancora non avete installato il pacchetto git]
# git clone https://github.com/trustedsec/artillery/ artillery/
# cd artillery
# sudo ./setup.py

Welcome to the Artillery installer. Artillery is a honeypot, file monitoring, and overall security tool used to protect your nix systems.

Written by: Dave Kennedy (ReL1K)

Do you want to install Artillery and have it automatically run when you restart [y/n]: y
[*] Beginning installation. This should only take a moment.
[*] Adding artillery into startup through init scripts..
[*] Triggering update-rc.d on artillery to automatic start…
Do you want to keep Artillery updated? (requires internet) [y/n]: y
[*] Checking out Artillery through github to /var/artillery
Cloning into ‘/var/artillery’…
remote: Counting objects: 876, done.
remote: Total 876 (delta 0), reused 0 (delta 0), pack-reused 876
Receiving objects: 100% (876/876), 207.83 KiB | 293.00 KiB/s, done.
Resolving deltas: 100% (568/568), done.
Checking connectivity… done.
[*] Finished. If you want to update Artillery go to /var/artillery and type ‘git pull’
Would you like to start Artillery now? [y/n]: y
Starting Artillery… Ok
[*] Installation complete. Edit /var/artillery/config in order to config artillery to your liking..

Durante il processo di installazione verranno poste, come potete leggere qui sopra, alcune domande:
Do you want to install Artillery and have it automatically run when you restart [y/n]:
Do you want to keep Artillery updated? (requires internet) [y/n]:
Would you like to start Artillery now? [y/n]:

Artillery verrà installato come servizio sotto /etc/init.d/
E’ sempre consigliabile leggere con attenzione prima d’ impostare il file di configurazione.
In ogni caso, una volta effettuate delle modifiche alla configurazione, si può impartire e renderle immediatamente operanti:
# python restart_server.py

Fate attenzione a non commettere l’errore di editare invece i files risultanti dal download via git. Una volta che che lo script di installazione sia stato eseguito, per modificarne la configurazione posizionatevi piuttosto nella directory /var/artillery.

Il contenuto del file config è piuttosto chiarificatore delle funzionalità del software:
# determina se attivare l’attività di monitoraggio dell’integrità di files sensibili
MONITOR=YES
#
# le directories da monitorare, se ne possono ancora aggiungere “/root”,”/var/”, ecc.
MONITOR_FOLDERS=”/var/www”,”/etc/”
#
# frequenza del controllo in secondi.
MONITOR_FREQUENCY=60
#
# esclusione dal controllo per certe directories o files, ad esempio: /etc/passwd,/etc/hosts.allow
EXCLUDE=
#
# determina se attivare l’attività di HONEYPOT
HONEYPOT=YES
#
# ban automatico HONEYPOT
HONEYPOT_BAN=YES
#
# WHITELIST di indirizzi IP non vincolati dalle regole di controllo
WHITELIST_IP=127.0.0.1,localhost
#
# PORTS su cui attivare il monitoring
PORTS=”135,445,22,1433,3389,8080,21,5900,25,53,110,1723,1337,10000,5800,44443″
#
# determina se attivare l’alerting via email
EMAIL_ALERTS=OFF
#
# username SMTP
USERNAME=”thisisjustatest@gmail.com”
#
# password SMTP
PASSWORD=”pass”
#
# destinatario
SMTP_TO=”testing@test.com”
#
# server per l’invio, per default gmail
SMTP_ADDRESS=”smtp.gmail.com”
#
# Porta SMTP per l’invio. Di default è quella gmail con TTLS
SMTP_PORT=”587″
#
# Indirizzo EMAIL su cui ricevere gli ALERTS
ALERT_USER_EMAIL=”user@whatever.com”
#
# determina se l’invio delle email di alerting debba avvenire seguendo una certa frequenza. Se impostato a off, gli alerts
# verranno inviati automaticamente in tempo reale (può significare un mucchio di spam)
EMAIL_TIMER=ON
#
# la frequenza con la quale saranno inviati gli ALERTS per email (per default ogni 10 minuti)
EMAIL_FREQUENCY=600
#
# Attivazione del monitoraggio dei tentativi BRUTE FORCE contro SSH
SSH_BRUTE_MONITOR=ON
#
# Quanti tentativi prima del BAN
SSH_BRUTE_ATTEMPTS=4
#
# Per effettuare degli aggiornamenti automatici
AUTO_UPDATE=OFF
#
# ANTI DOS imposta la macchina a limitare le connessioni, e va impostato ad OFF nel caso non lo si intenda utilizzare
ANTI_DOS=ON
#
# Le porte dotate di protezione ANTI-DOS
ANTI_DOS_PORTS=80,443
#
# I parametri che limitano le connessioni come misura anti DOS
ANTI_DOS_THROTTLE_CONNECTIONS=50
ANTI_DOS_LIMIT_BURST=200
#

Artillery ha un set di porte (comuni o comunemente attaccate) preimpostato sulle quali si pone in ascolto.
A rivelarle basta un semplice:

# netstat -antp |grep LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 827/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 637/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 706/cupsd
tcp 0 0 0.0.0.0:1433 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:1337 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:90 0.0.0.0:* LISTEN 734/nginx -g daemon
tcp 0 0 0.0.0.0:44443 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:47323 0.0.0.0:* LISTEN 616/rpc.statd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:5800 0.0.0.0:* LISTEN 2428/python
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1089/mysqld
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 606/rpcbind
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 2428/python
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2428/python
tcp6 0 0 :::53 :::* LISTEN 827/dnsmasq
tcp6 0 0 :::22 :::* LISTEN 637/sshd
tcp6 0 0 ::1:631 :::* LISTEN 706/cupsd
tcp6 0 0 :::46327 :::* LISTEN 616/rpc.statd
tcp6 0 0 :::90 :::* LISTEN 734/nginx -g daemon
tcp6 0 0 :::111 :::* LISTEN 606/rpcbind
tcp6 0 0 :::80 :::* LISTEN 1153/apache2
…

P.S.: L’esclusione dell’indirizzo IP che non riesca ad autenticarsi validamente viene effettuata attraverso il controllo del file /var/log/auth.log (per le distribuzioni basate su Debian).

Il tool e’ potente ed altamente configurabile; non rimane che dare un’occhiata alla configurazione e fare qualche prova, magari all’inizio giocando con qualche servizio aperto su di una VM.

 

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

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

Firehol il firewall flessibile

fireholSi parla spesso di come proteggere il proprio PC/Server e la parola che sicuramente ricorre piu’ spesso e’ FIREWALL, non c’e’ dubbio.

Il problema che salta all’occhio di chiunque si sia mai cimentato con la “scrittura” delle regole di IPtables e derivati, e’ la non immediata semplicita’ nel comprendere la giusta sintassi da utilizzare e dunque nel capire il corretto posizionamento delle tante/tantissime variabili che rendono questi strumenti ottimi nel tenere lontani la maggior parte dei malintenzionati .

Uno strumento che potra’ certamente darvi una mano e’ il tool FireHol.

FireHOL è un linguaggio per esprimere le regole del firewall, non semplicemente uno script che produce un qualche tipo di firewall.” I file di configurazione di FireHOL sono script shell (ma di fatto non lo sembrano poiche’ sono semplici che più semplici non si può).

FireHOL viene fornito con firehol-wizard, che crea un file di configurazione che è poi necessario modificare a mano.

Il suggerimento migliore che posso dare rimane quello di utilizzare sempre, soprattutto all’inizio, le macchine virtuali, per  riuscire a prendere dimestichezza con la nuova tecnologia.

Si tratta dunque di un particolare software che, tramite un “semplice” file di configurazione, permette di impostare velocemente le regole del firewall per proteggere l’accesso dalla LAN verso Internet e viceversa. Il file in questione si trova in /etc/firehol/firehol.conf, quindi apriamolo con sudo vim /etc/ firehol/firehol.conf, cancelliamone il contenuto pre esistente e scriviamo quanto segue:

Anche l’installazione e’ semplice come bere un bicchier d’acqua

sudo apt-get install firehol

Questo e’ un piccolo esempio utile per dare un’idea della metodologia di configurazione del file:

#Imposto la LAN eth0 scheda di rete verso internet

interface eth0 internet

# Di default non accettare nessun pacchetto

policy reject

protection strong

#Accetta solamente questi servizi

server ssh accept

server ping accept

server http accept

server https accept

server dns accept

client ping accept

client http accept

client https accept

#Imposto eth1 come rete interna lan

interface eth1 lan

#Accetta tutto il traffico nella LAN interna

policy accept

#Imposto le tabelle di routing

#Il traffico dalla LAN (eth1) reindirizzato verso eth0

router lan2internet inface eth1 outface eth0

# Regola per il masquerade

masquerade

#Accetta tutto il traffico

router all accept

#In ingresso, invece, fai il contrario...

router internet2lan inface eth0 outface eth1

** Le righe precedute dal simbolo # sono commenti che possono essere omessi, ma che possono essere sempre di grande aiuto nel rileggere vecchie configurazioni. Dopo aver inserito tutte le regole, salviamo e usciamo dall’editor.

A questo punto, bastera’ impostare il firewall in modo che si attivi automaticamente all’avvio del server. Apriamo dunque il file firehol con sudo vim /etc/default/firehol e cambiamo la riga START_FIREHOL=NO in START_FIREHOL=YES.

Infine, avviamo il firewall con il comando sudo /etc/init.d/firehol start. Il nostro lavoro è quasi finito, ma mancano ancora alcuni passi.

Buone configurazioni!