# [iptables] perchÃ¨ non funzionano le policy?[risolto]

## drumpaul

Il problema Ã¨ presto detto, il settaggio della policy sembra non aver effetto... o meglio se utilizzo una politica di DROP e poi inserisco le regole per abilitare solo un certo tipo di traffico mi viene droppato tutto a prescindere.

Premetto che le regole che utilizzo le ho estrapolate da vari how-to e documentazione varia e in passato hanno funzionato anche 'con me'!

Ora mi chiedo (posto che le regole siano giuste) perchÃ¨ la policy, in particolare quella di DROP, sembra non funzionare correttamente?

PuÃ² dipendere da qualche impostazione del kernel che non ho abilitato?

Illuminatemi per favore!

Ciao!

PS

Per completezza di test ho provato la politica inversa a quella che vorrei utilizzare io, cioÃ¨ ACCEPT e poi come ultima regola della catena in questione DROP ALL from e to ANYWHERE e cosÃ¬ sembra funzionare, perÃ² siccome la macchina Ã¨ solo uno strumento voglio che faccia quello che decido io o nel caso mi basterebbe capire quest'arcano comportamento.Last edited by drumpaul on Thu Aug 24, 2006 9:00 pm; edited 1 time in total

----------

## Kernel78

A quanto ne so io iptables legge e applica le regle in ordine ...

Se come prima regola metti un drop di tutto nessun pacchetto andrÃ  mai oltre ...

----------

## fat_penguin

 *Kernel78 wrote:*   

> A quanto ne so io iptables legge e applica le regle in ordine ...
> 
> Se come prima regola metti un drop di tutto nessun pacchetto andrÃ  mai oltre ...

 

Questo è valido, ma non per la politica di default!

```
iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP
```

possono essere messe anche all'inizio dello script che attiva il firewall.

@drumpaul: senza qualche info in piu è difficile darti una mano. Sicuro di lavorare giusto che le tabelle si stato? Posta la tua conf...

byebye

fat_penguin

----------

## Kernel78

 *fat_penguin wrote:*   

> Questo è valido, ma non per la politica di default!

 

Io non ho mai considerato la politica di default come una regola ... ho sempre sbagliato ?

----------

## fat_penguin

 *Kernel78 wrote:*   

>  *fat_penguin wrote:*   Questo è valido, ma non per la politica di default! 
> 
> Io non ho mai considerato la politica di default come una regola ... ho sempre sbagliato ?

 

Io ho solo chiarito che i comadi:

```
iptables -P xxxxxxx
```

possono essere messi ad inizio script di configurazione senza incorrere in problemi. Penso che drumpaul parlasse di questo.

Cmq confermo quello che hai detto tu: in NETFILTER vale la regola "first match win"

byebye

fat_penguin

----------

## drumpaul

@Kernel78:

Si le policy sono importanti, o per lo meno molto utili in adozione di certe politiche, poi ovviamente si possono ottenere gli stessi risultati in vari modi, perÃ² personalmente e facendo riferimento al mio caso ritengo che sia molto pratico nonchÃ¨ concettualmente corretto in un firewall negare tutto e permettere solo quello che si vuole.

@fat_penguin scusa non ho ben capito il suggerimento, cmq posto un iptables -L

```

Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     icmp --  anywhere             anywhere            icmp echo-request

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination
```

in questo modo se sul server su cui c'Ã¨ iptables pingo su 127.0.0.1 non ottengo risposta

mentre ovviamente se metto la polici su ACCEPT risponde.

Puoi spiegare meglio il fatto di impostare le policy prima dello script?

----------

## fat_penguin

Ciao,

se vuoi puoi partire da questo script d'esempio per configurare il tuo firewall.

E' rudimentale e forse non molto elegante, ma fa il suo dovere. E' chiaramente per una proteggere una macchina standalone!

Lo lanci e lui mette a zero l'attuale conf di netfilter e setta le nuove regole tramite il comando iptables...

```

#Any kernel modules that need to be loaded go here

#/sbin/modprobe ip_conntrack_ftp   # lancera automaticamente anche la dipendenza "ip_conntrack"

# Set to zero chains

iptables -F

iptables -X

iptables -t nat -F

iptables -t nat -X

# Set to closed all

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP

##########################################

# INPUT RULES

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 22 -j LOG --log-prefix "Connessione SSH  "

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 22 -j ACCEPT

        iptables -A INPUT -p tcp -s 127.0.0.1 --dport 25 -j ACCEPT

        iptables -A INPUT -p tcp -s 127.0.0.1 -j ACCEPT

        iptables -A INPUT -p udp -s 127.0.0.1 -j ACCEPT

        iptables -A INPUT -p icmp -s 127.0.0.1 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --dport 53 -j ACCEPT

        iptables -A INPUT -p udp --dport 53 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 80 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 443 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 25 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 110 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 143 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 995 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 993 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 21 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 465 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 5060 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 5001 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 60000:60050 -j ACCEPT

        iptables -A INPUT -p udp  --sport 1024: --dport 5060 -j ACCEPT

######################################

# OUTPUT RULES

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

        iptables -A OUTPUT -p icmp -j ACCEPT

        iptables -A OUTPUT -p tcp -j ACCEPT

        iptables -A OUTPUT -p udp -j ACCEPT
```

----------

## drumpaul

Ok, magari lo provo, perÃ² siccome il mio Ã¨ un server mi serve capire perchÃ© questa situazione. Non per essere paranoico ma non vorrei fare un copia e incolla di soluzioni qua e la per poi non sapere esattamente da cosa mi sto difendendo o a cosa mi sto esponendo con certe regole.

Posto che il tuo script funzioni anche a me Ã¨ apprezzabile ma non chiarisce il punto del mio problema che sono le policy. Se Ã¨ come penso io, cioÃ¨ un problema del mio server/iptables, cosÃ¬ a occhio anche col tuo script dovrei avere gli stessi problemi, comunque ti faccio sapere.

Grazie per l'aiuto, altre soluzioni?

----------

## fat_penguin

 *drumpaul wrote:*   

> Ok, magari lo provo, perÃ² siccome il mio Ã¨ un server mi serve capire perchÃ© questa situazione. Non per essere paranoico ma non vorrei fare un copia e incolla di soluzioni qua e la per poi non sapere esattamente da cosa mi sto difendendo o a cosa mi sto esponendo con certe regole.
> 
> Posto che il tuo script funzioni anche a me Ã¨ apprezzabile ma non chiarisce il punto del mio problema che sono le policy. Se Ã¨ come penso io, cioÃ¨ un problema del mio server/iptables, cosÃ¬ a occhio anche col tuo script dovrei avere gli stessi problemi, comunque ti faccio sapere.
> 
> Grazie per l'aiuto, altre soluzioni?

 

beh, piu chiaro di uno script ....   :Shocked: 

Le regole sono li scritte, te le leggi e cerchi sui manuali le cose che non capisci... eventualmente posti i tuoi dubbi...

... ma forse sono io che non ho capito il tuo problema ...

byebye

fat_penguin

----------

## drumpaul

Come non detto... con il tuo script funziona!

Ok, escludendo le regole che vengono assegnate alle catene, e posto che

```
# Set to closed all

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP
```

presente in uno script o dato a mano dia lo stesso risultato, il campo si restringe a:

```

# Set to zero chains

iptables -F

iptables -X

iptables -t nat -F

iptables -t nat -X

```

Ora che io sappia questi comandi non fanno altro che 'resettare' le catene di filter e nat, quindi posto che dia anche a mano questi ultimi comandi il risultato dovrebbe esser lo stesso che lanciare lo script.

E' dunque tale script cosÃ¬ magico che fa funzionare le policy a dovere solo con il suo utilizzo?

e sembra di per contro che anche riscrivendolo a mano comando per comando nella console non abbia lo stesso effetto sulle policy... qual'Ã¨ dunque il mistero?

----------

## fat_penguin

Allora, vediamo di capirci...

Se metti riga per riga in una shell quello che sta nello script ottieni lo stesso identico risultato.... non ci piove e non puo' essere diversamente!!!! 

Eccoti qualche spiegazione in piu, magari ti chiarisce il concetto:

Queste righe, come ha detto tu, resettano le varie tabelle e catene. In questo modo metti tutto a zero per evitare che alcune regole precedenti restino attive.

```
# Set to zero chains

iptables -F

iptables -X

iptables -t nat -F

iptables -t nat -X
```

Queste sono le policy di default, in questo caso tutto chiuso!

```
# Set to closed all

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP
```

Qui è descritto quello che accetti in entrata verso il tuo server. 

Per semplificare in questo caso accetti "tutte" le connessioni che arrivano dal server stesso, e le connessioni verso la porta 80.

```
##########################################

# INPUT RULES

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

        iptables -A INPUT -p tcp -s 127.0.0.1 -j ACCEPT

        iptables -A INPUT -p udp -s 127.0.0.1 -j ACCEPT

        iptables -A INPUT -p icmp -s 127.0.0.1 -j ACCEPT

        iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN --sport 1024: --dport 80 -j ACCEPT
```

Qui invece che possa iniziare delle connesioni verso l'esterno sui principali protocolli.

```
######################################

# OUTPUT RULES

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

        iptables -A OUTPUT -p icmp -j ACCEPT

        iptables -A OUTPUT -p tcp -j ACCEPT

        iptables -A OUTPUT -p udp -j ACCEPT
```

Ora, queste due regolette che hai visto prima:

```
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
```

sono fondamentali in quanto permetto alle connessioni gia instaurate di proseguire lo scambio di pacchetti... praticamente viene detto che i pacchetti appartenenti a connessioni stabilite posso transitare.

Spero di averti chiarito qualche dubbio.

byebye

fat_penguin

----------

## drumpaul

Forse ci sono:

nella fattispecie questa regola sembra non funzionare:

```
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
```

invece la tua 

```
iptables -A INPUT -p icmp -s 127.0.0.1 -j ACCEPT
```

 si.

Ora la prima regola l'ho trovata su un how-to abbastanza 'famoso' e l'avevo giÃ  utilizzata con successo...

perchÃ© adesso mi ritrovo con la stessa che non funziona?

Per la cronaca l'how-to in questione Ã¨ "IPtables for Fun -- Implementare un firewall in linux".

Nonostante abbia capito (nel caso del ping localhost) cosa non andava il dubbio Ã¨ sempre maggiore...

ci sono delle spiegazioni plausibili a questa mia situazione?? :Surprised: 

----------

## fat_penguin

 *drumpaul wrote:*   

> Forse ci sono:
> 
> nella fattispecie questa regola sembra non funzionare:
> 
> ```
> ...

 

Beh, se ci spiegassi cosa non funziona... non è che sia molto chiaro cosa vuoi ottenere...

Con la "mia regola" accetto in entrata i pacchetti icmp solo da localhost, con la "tua" accetti da tutti paccheti icmp echo-request ... sono due cose diverse...

fat_penguin

----------

## drumpaul

La questione non sta in quello che voglio ottenere, ma dal fatto che in un caso (il tuo) la policy DROP 'ha effetto', mentre nel mio la policy DROP non ha effetto.

Vedo anch'io la differenza tra le 2regole, ma ho testato anche da altre parti, nonchÃ¨ in precedenza sul mio stesso pc che la mia regola accetta il ping su localhost; la tua anche (nonostante sia diversa dalla mia), ma il punto Ã¨ che nella situazione attuale pingando con la tua funge con la mia no (sempre tenendo conto della catena INPUT con policy DROP).

Riassumendo, posto che la nostra chain INPUT abbia la politica DROP, le 2 regole sono differenti ma entrambe consentono il ping su localhost,giusto?

ora perchÃ¨ riesco a pingare localhost solo con la tua e con la mia no?

Ora mi verrebbe da chiederti se la 'mia' regola a te funziona con la policy INPUT DROP, dopodichÃ© non so, cambierÃ² politica di filtraggio... (anche se la cosa mi darebbe fastidio)!

----------

## fat_penguin

 *drumpaul wrote:*   

> La questione non sta in quello che voglio ottenere, ma dal fatto che in un caso (il tuo) la policy DROP 'ha effetto', mentre nel mio la policy DROP non ha effetto.
> 
> Vedo anch'io la differenza tra le 2regole, ma ho testato anche da altre parti, nonchÃ¨ in precedenza sul mio stesso pc che la mia regola accetta il ping su localhost; la tua anche (nonostante sia diversa dalla mia), ma il punto Ã¨ che nella situazione attuale pingando con la tua funge con la mia no (sempre tenendo conto della catena INPUT con policy DROP).
> 
> Riassumendo, posto che la nostra chain INPUT abbia la politica DROP, le 2 regole sono differenti ma entrambe consentono il ping su localhost,giusto?
> ...

 

ma in OUTPUT permetti l'uscita dei pacchetti icmp?

fat_pengiuin

----------

## drumpaul

No, anche accettando l'icmp in OUTPUT c'Ã¨ lo stesso problema... ma scusa pingando localhost che pacchetti devono uscire?

Con la tua regola in INPUT, OUTPUT e INPUT vuote e tutte le chain in policy DROP il ping su localhost funziona quindi cmq non penso sia quello il problema.

La situazione che sto cercando di testare Ã¨ quella che ho quotato in un precedente messaggio.

Ora sto solo testando/cercando di capire il problema con la regola per abilitare il ping su localhost.

----------

## fat_penguin

 *drumpaul wrote:*   

> No, anche accettando l'icmp in OUTPUT c'Ã¨ lo stesso problema... ma scusa pingando localhost che pacchetti devono uscire?
> 
> Con la tua regola in INPUT, OUTPUT e INPUT vuote e tutte le chain in policy DROP il ping su localhost funziona quindi cmq non penso sia quello il problema.
> 
> La situazione che sto cercando di testare Ã¨ quella che ho quotato in un precedente messaggio.
> ...

 

Se la default policy è di DROP neanche localhost è raggiungibile, va specificato che i pacchetti provenienti da 127.0.0.1 sono accettati!

Perchè, come ti ho gia chiesto post addietro, non posti esattamente tutti i comandi che inserisci? Forse cosi sara' piu facile capire dove sta il problema...

fat_penguin

----------

## drumpaul

Ehm non penso che quello che sostieni sia del tutto corretto, cmq ammetto le mie eventuali lacune.

Per quanto riguarda scriverti tutti i comandi che digito sarebbe lunga... in compenso ti posso far vedere la configurazione del mio iptables!

Ora cerchiamo di chiarire 1paio di cose, se no mi sa che non ci capiamo!

Poni che la situazione del mio iptables Ã¨ la seguente:

```

Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     icmp --  anywhere             anywhere            icmp echo-request

Chain FORWARD (policy DROP)

target     prot opt source               destination

Chain OUTPUT (policy DROP)

target     prot opt source               destination

ACCEPT     icmp --  anywhere             anywhere            icmp echo-request

```

le regole con target ACCEPT che sono inserite sono conseguenza del comando:

```

iptables -A <CATENA> -p icmp --icmp-type echo-request -j ACCEPT

```

Ora mi sbaglio nel dire che in questa particolare situazione dovrebbe essere possibile un ping 127.0.0.1 con risultato positivo nonostante le policy DROP?

Se la risposta Ã¨ no (non mi sbaglio) allora dovrebbe apparire lampante il mio problema: cioÃ¨ che in questa identica situazione il suddetto ping da risultato negativo!

Altrimenti vorrei sapere quali errori di regole o di concetto commetto!

----------

## fat_penguin

 *drumpaul wrote:*   

> Ehm non penso che quello che sostieni sia del tutto corretto, cmq ammetto le mie eventuali lacune.
> 
> Per quanto riguarda scriverti tutti i comandi che digito sarebbe lunga... in compenso ti posso far vedere la configurazione del mio iptables!
> 
> Ora cerchiamo di chiarire 1paio di cose, se no mi sa che non ci capiamo!
> ...

 

Secondo me ti mancano le regole per lo stato delle connessioni. Con un iptables -L dovresti ottenere da qualche parte questo tipo di stringhe:

```
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
```

Come ti ho gia spiegato, senza queste regole i pacchetti non possono tornare indietro...

Cmq è inutile che stiamo qui a discutere se non posti i comandi iptables dall'inizio alla fine... spero tu non li inserinca a mano tutte le volte... esistono gli script per qualcosa...

fat_penguin

----------

## drumpaul

Ohhh ecco che ci siamo!

PerÃ² se permetti non eri stato proprio cosÃ¬ chiaro, cmq faccio anche un mea culpa perchÃ¨ (oltre a non esprimermi benissimo, lo ammetto) avevo tralasciato l'importanza di tale regola che in effetti risolve il 'problema'!

Quindi riepilogando la regola

```
iptables -A <CATENA> -m state --state ESTABLISHED,RELATED -j ACCEPT
```

risulta a mio parere fondamentale per il corretto transito di qualsivoglia pacchetto.

A parte tutto grazie per la pazienza e per l'aiuto fat_penguin!

Ciao a tutti

----------

## X-Act!

Non vorrei dire una ca**ata, ma se vuoi poter mandare un ping e ricevere la risposta o accetti comunque le connessioni già established come ti ha suggerito giustamente fat_penguin (cose che comunque mi sembra necessaria per qualsiasi protocollo) oppure devi permettere non solo echo-request in un verso, ma anche echo-reply nell'altro.

Ecco quindi la differenza tra la tua regola

```
iptables -A <CATENA> -p icmp --icmp-type echo-request -j ACCEPT
```

e quella di fat_penguin:

```
iptables -A INPUT -p icmp -s 127.0.0.1 -j ACCEPT
```

Ovviamente questo non lo scrivo per risolvere il tuo problema: la soluzione più elegante e funzionale è sicuramente quella che hai già implementato. Ma visto che ci tieni (e ci tengo anch'io) a capire come funzionano le cose volevo sollevare anche quest'aspetto!

EDIT:

P.S.: ma perchè siamo nel forum di supporto e non in quello di discussione? MOD??

----------

## randomaze

Moved from Forum italiano (Italian) to Forum di discussione italiano.

 *X-Act! wrote:*   

> P.S.: ma perchè siamo nel forum di supporto e non in quello di discussione? MOD??

 

ero distratto dal lavoro   :Rolling Eyes: 

----------

## drumpaul

Ti assicuro che basta l'echo-request perÃ² sia in entrata che in uscita, per lo meno nel mio caso, poi non ho testato come dici tu.

In teoria avresti ragione ma non so spiegarti tecnicamente cosa avviene in entrambi i casi.

----------

## Kernel78

 *drumpaul wrote:*   

> Ti assicuro che basta l'echo-request perÃ² sia in entrata che in uscita, per lo meno nel mio caso, poi non ho testato come dici tu.
> 
> In teoria avresti ragione ma non so spiegarti tecnicamente cosa avviene in entrambi i casi.

 

Drum se ci assicuri tu una cosa è meglio controllare due volte  :Wink: 

 *http://pluto.panservice.it/ildp/lfs/blfs/6.0/postlfs/firewall.html wrote:*   

> Si vuole poter fare il ping alla propria macchina per assicurarsi che sia ancora viva:
> 
>                 iptables -A INPUT  -p icmp -m icmp --icmp-type echo-request -j ACCEPT
> 
> iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply   -j ACCEPT
> ...

 

echo-request è appunto la richiesta che viene effettuata dal ping

echo-reply è la risposta ad un ping

Perchè un host possa rispondere ad un ping (con policy di DROP) allora devi permettere gli echo-request in input (altrimenti non arriva la richiesta) e echo-reply in ouput (altrimenti la risposta non lascia la macchina).

Inoltre se tu vuoi poter pingare DA un host con policy di DROP devi accettare echo-request in ouput e echo-reply in input.

----------

## drumpaul

Ok come non detto!Ma la mia risposta precedente Ã¨ dal fatto che io non ho autorizzato nessun echo-reply eppure il ping funziona...

non saprei e cmq giuro di aver capito + o - il funzionamento, la spiegazione Ã¨ chiara ma io sul mio server ho un comportamento quantomeno diverso, eppure uso la politica di DROP..!non saprei ke dirti!

farÃ² ulteriori prove e poi ti dico!

cmq grazie per la spiegazione chiara

----------

## drumpaul

Confermo che per ping da e per il server mi basta abilitare l'echo-request sia in INPUT che in OUTPUT.

Nello specifico ho provato a pingare dal server a 1client della rete ed al server stesso, poi dal client al sever e appunto funziona tranquillamente solo con l'echo-request sottolineando che non ho abilitato altri tipi di icmp quindi viene tutto droppato come da policy.

Comunque con questo non voglio mettere in dubbio un concetto a mio avviso piÃ¹ logico del comportamento che riscontro sulla mia macchina, perÃ² ora mi piacerebbe sapere il motivo di questa mia situazione.idee al riguardo?

----------

## X-Act!

Forse (e dico forse) avendo abilitato:

```
iptables -A <CATENA> -m state --state ESTABLISHED,RELATED -j ACCEPT
```

i pacchetti di echo-reply vengono considerati come risposta ad una connessione già stabilita e vengono fatti transitare lo stesso.

Ci vorrebbe una sniffata con ethereal ehm pardon, wireshark per fugare ogni dubbio! Purtroppo io non sono a casa e qui non ho neanche un tcpdump...

Magari se qualcuno ha a portata di mano un Tanenbaum può vedere se lì c'è qualche dettaglio.

----------

## drumpaul

Si,effettivamente Ã¨ plausibile come ipotesi,infatti il ruolo della regola

```
iptables -A <CATENA> -m state --state ESTABLISHED,RELATED -j ACCEPT
```

Ã¨ proprio quello.

In alternativa si potrebbe provare togliendo la suddetta regola e inserendo gradualmente le varie regole per il ping... agirÃ² in questo senso visto che non ho dimestichezza con gli applicativi menzionati.

----------

