# [Diciamo risolto] Problemi con regole iptables

## fbcyborg

Salve, 

non conoscendo bene iptables mi sono trovato in una situazione un po' spiacevole.

Ho dovuto impostare alcune regole di iptables per via del fatto che sto utilizzando squid, che mi fa da proxy sull'interfaccia eth0 (10.0.0.0).

Quando sto navigando grazie all'interfaccia eth1 (192.168.1.0) che ha come gateway 192.168.1.254, se iptables è in funzione non riesco a navigare in alcun sito.

Quindi dovrei creare una regola che mi dice che se ho una richiesta in uscita che parte da eth1, me la deve far passare.. come posso fare?

Le regole che ho impostato attualmente sono le seguenti (prese dal file rules-save)

```
[207:12420] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

[0:0] -A OUTPUT -p tcp -m tcp --dport 80 -m owner --uid-owner squid -j ACCEPT

[0:0] -A OUTPUT -p tcp -m tcp --dport 3128 -m owner --uid-owner squid -j ACCEPT

[2:120] -A OUTPUT -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

[0:0] -A OUTPUT -p tcp -m tcp --dport 3128 -j REDIRECT --to-ports 8080

```

Grazie

----------

## devilheart

```
iptables -A OUTPUT -o eth1 -j ACCEPT
```

?

anche se ho la sensazione che non sia quello che vuoi. descrivi meglio ciò che vuoi ottenere

(e tutta la configurazione attuale di iptables, specialmente le regole di default)

----------

## fbcyborg

Grazie mille devilheart.

Quello che voglio ottenere è concettualmente semplice e di uso comune.

Ho un server con due interfacce di rete, eth0 ed eth1.

L'interfaccia eth1 è connessa ad un router adsl e prende da esso un IP, dinamicamente (che poi alla fine è come se fosse fisso, visto che non cambierà mai, essendo il server sempre acceso).

Quindi il mio mezzo per andare su internet è appunto eth1.

eth0 la uso, invece, per creare una nuova sottorete del tipo 10.0.0.0/8. Ho installato DHCP e l'ho impostato per rilasciare IP su quell'interfaccia.

Ora, il mio scopo finale è quello di impostare squid+dansguardian+iptables in modo che gli utenti della LAN 10.0.0.0/8 colleghino i loro pc allo switch e navighino. Devono navigare però "filtrati" da dansguardian.

Ecco per l'appunto cosa c'entra iptables. Leggendo i vari howto e guide in giro ho letto un sacco di regole di iptables, e alla fine non c'ho capito gran che (infatti sto cercando di studiarlo per capire un po' meglio). Quindi il risultato è che ho inserito una serie di regole di iptables ma quanto a risultati zero.

Squid dovrebbe funzionarmi in modalità trasparente, in modo da non dover impostare ciascun browser per navigare in Internet.

La sequenza è appunto la seguente:

```
    * browser -> port 80 ->

    * firewall redirects to 8080 ->

    * dansguardian listens on 8080 and outputs on 3128 ->

    * squid listening on 3128

    * ->www
```

----------

## devilheart

prova con

```
iptables -t nat -A PREROUTING -i eth0 --destination-port 80 -j REDIRECT --to-ports 8080
```

----------

## fbcyborg

Non so perché ma:

```
# iptables -t nat -A PREROUTING -i eth0 --destination-port 80 -j REDIRECT --to-ports 8080

iptables v1.4.2: Unknown arg `(null)'

Try `iptables -h' or 'iptables --help' for more information.
```

Forse manca qualche opzione nel kernel... 

Adesso comunque riesco a navigare dai PC in rete, solo che ci riesco a patto che abbia impostato il proxy in firefox (10.0.0.1:3128). Invece io dovrei settare "No proxy"...

----------

## devilheart

errore mio 

```
iptables -t nat -A PREROUTING -i eth0 -p tcp --destination-port 80 -j REDIRECT --to-ports 8080 
```

ricorda che devi avere il supporto a REDIRECT abilitato nel kernel

----------

## fbcyborg

mmh... 

la mia situazione ora è la seguente:

```
# iptables -t nat -L

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination

REDIRECT   tcp  --  anywhere             anywhere            tcp dpt:http redir ports 8080

Chain POSTROUTING (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http owner UID match squid

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3128 owner UID match squid

REDIRECT   tcp  --  anywhere             anywhere            tcp dpt:http redir ports 8080

```

Ma come prima, se non imposto sul browser un proxy non navigo.  :Neutral: 

----------

## devilheart

imposta i browser per non usare il proxy e poi vedi cosa arriva al server (con tcpdump) e se arriva qualcosa a DansGuardian e squid

----------

## fbcyborg

Ecco cosa accade quando ad esempio cerco di accedere a www.google.it:

```
21:08:14.817423 IP 10.0.0.2.38842 > ML310-G5.myworkgroup.domain: 47807+ A? www.google.it. (31)

21:08:15.058569 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 67

21:08:14.817868 IP 10.0.0.2.44911 > ML310-G5.myworkgroup.domain: 47807+ A? www.google.it. (31)

21:08:14.817883 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 67

21:08:14.818117 IP 10.0.0.2.39881 > ML310-G5.myworkgroup.domain: 7868+ A? www.google.it.myworkgroup.lan. (45)

21:08:14.818129 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 81

21:08:14.818368 IP 10.0.0.2.33247 > ML310-G5.myworkgroup.domain: 7868+ A? www.google.it.myworkgroup.lan. (45)

21:08:14.818385 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 81

21:08:14.830360 IP 10.0.0.2.45620 > ML310-G5.myworkgroup.domain: 33298+ A? toolbarqueries.google.it. (42)

21:08:14.830372 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 78

21:08:14.830610 IP 10.0.0.2.38885 > ML310-G5.myworkgroup.domain: 33298+ A? toolbarqueries.google.it. (42)

21:08:14.830622 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 78

21:08:14.830861 IP 10.0.0.2.46051 > ML310-G5.myworkgroup.domain: 11988+[|domain]

21:08:19.816939 arp who-has ML310-G5.myworkgroup tell 10.0.0.2

21:08:19.816949 arp reply ML310-G5.myworkgroup is-at 00:23:7d:fc:dd:dd (oui Unknown)

21:08:19.836925 IP 10.0.0.2.46051 > ML310-G5.myworkgroup.domain: 11988+[|domain]

21:08:19.836943 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 92

21:08:19.837424 IP 10.0.0.2.38064 > ML310-G5.myworkgroup.domain: 47674+ A? toolbarqueries.google.it. (42)

21:08:19.837441 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 78

21:08:19.837675 IP 10.0.0.2.42589 > ML310-G5.myworkgroup.domain: 47674+ A? toolbarqueries.google.it. (42)

21:08:19.837690 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 78

21:08:19.837924 IP 10.0.0.2.54788 > ML310-G5.myworkgroup.domain: 61063+[|domain]

21:08:19.837939 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 92

21:08:19.838174 IP 10.0.0.2.51910 > ML310-G5.myworkgroup.domain: 61063+[|domain]

21:08:19.838187 IP ML310-G5.myworkgroup > 10.0.0.2: ICMP ML310-G5.myworkgroup udp port domain unreachable, length 92

21:08:24.836053 arp who-has 10.0.0.2 tell ML310-G5.myworkgroup

21:08:24.836244 arp reply 10.0.0.2 is-at 00:13:a9:8b:89:e0 (oui Unknown)
```

----------

## devilheart

a me sembra che non riesca a risolvere gli indirizzi. prova ad aprire 216.239.59.104 e vedi cosa ti dice. nei log del proxy c'è qualcosa? c'è un motivo particolare che ti impedisce di configurare l'uso del proxy su tutti i browser

----------

## fbcyborg

Allora, dunque.

A prescindere da iptables, nel mio caso dovrebbe essere possibile far funzionare il proxy anche senza fare il redirect delle porte.

Correggimi se sbaglio, ma se io metto squid in ascolto sulla porta 80 (senza specificare l'interfaccia), e se imposto i browser su modalità "No Proxy", dovrei poter navigare giusto?

A quanto ho sempre visto (e in base a come funzionano i classici router/modem adsl, io prendo come gateway l'indirizzo IP interno del router, e ovviamente non devo impostare sui browser che l'IP del router è il mio proxy server. Perché è così complicato fare una cosa simile con Gentoo?

Inoltre con questo set di regole prese dal file /var/lib/iptables/rules-save :

```
[43:2580] -A OUTPUT -p tcp -m tcp --dport 80 -m owner --uid-owner squid -j ACCEPT

[0:0] -A OUTPUT -p tcp -m tcp --dport 3128 -m owner --uid-owner squid -j ACCEPT

[0:0] -A OUTPUT -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

```

ho un altro problema.

Quando iptables è attivo, se provo ad emergere qualcosa, non riesco a fare il fetch dei files. 

E questo perché anche i pacchetti in uscita dal'interfaccia eth1 vengono redirezionati, allora mi chiedo se facendo così, posso risolvere:

```
iptables -t nat -P OUTPUT -i eth1 -j ACCEPT
```

Chiedo perché non sono sicuro.. la prima cosa che mi viene in mente è quella di abilitare tutto il traffico in uscita da eth1.. ma mi sa che non basta.

----------

## devilheart

 *fbcyborg wrote:*   

> Allora, dunque.
> 
> A prescindere da iptables, nel mio caso dovrebbe essere possibile far funzionare il proxy anche senza fare il redirect delle porte.
> 
> Correggimi se sbaglio, ma se io metto squid in ascolto sulla porta 80 (senza specificare l'interfaccia), e se imposto i browser su modalità "No Proxy", dovrei poter navigare giusto?
> ...

 normalmente sui browser devi mettere esplicitamente l'indirizzo del proxy. il transparent proxy mi sembra più uno scamuffo che una vera soluzione

vedi questo se ti aiuta http://openskill.info/infobox.php?ID=1032

comunque il linea generale dovresti fare un po' di analisi di traffico e log per vedere dove si bloccano i pacchetti. non hai ancora detto però perché non configuri l'uso del proxy su ogni browser

 *Quote:*   

> 
> 
> Inoltre con questo set di regole prese dal file /var/lib/iptables/rules-save :
> 
> ```
> ...

 

così non risolvi perché la terza regola viene applicata e non serve usare la politica di default. tu vuoi che le connessioni che si originano dal server passino dal proxy che gira sul server stesso? non mi sembra utile come cosa

----------

## fbcyborg

 *devilheart wrote:*   

> normalmente sui browser devi mettere esplicitamente l'indirizzo del proxy. il transparent proxy mi sembra più uno scamuffo che una vera soluzione
> 
> vedi questo se ti aiuta http://openskill.info/infobox.php?ID=1032
> 
> comunque il linea generale dovresti fare un po' di analisi di traffico e log per vedere dove si bloccano i pacchetti. non hai ancora detto però perché non configuri l'uso del proxy su ogni browser
> ...

 

Il link che mi hai dato mi sa che è riferito alle versioni di squid precedenti alla 3, infatti cambiano alcune cosette per il transparent mode.

Perché non voglio impostare l'uso del proxy nei browser? Semplice: gli utenti della lan devono fare il meno possibile. Devono potersi connettere con il cavetto, e andare su internet ma con delle limitazioni (imposte poi da dansguardian, che però voglio considerare in un passo successivo).

Mi pare che per questo ci sia appunto il transparent mode.

Mi chiedo come mai sia così assurdo realizzare con gentoo quello che tipicamente si realizza con i router adsl. In più io devo solo mettere un filtro alla navigazione. Devo per forza farlo con Gentoo Linux.

----------

## fbcyborg

Non capisco per quale ragione, se iptables è disattivato, quando provo a digitare un URL nel browser, sul lato server non arrivano richieste sulla porta 80 (con impostazione "No proxy" nel browser).

Infatti con tcpdump port 80 non catturo alcun pacchetto!!! Mentre se faccio semplicemente tcpdump, qualcosa viene visualizzato.  :Neutral: 

Ovvero quanto ho riportato in precedenza: 

```
ML310-G5.myworkgroup.domain
```

. Ma il ".domain" cosa indica?

Ho notato che se provo a telnettare sulla porta 80, arrivano richieste identificate come ".http". Quindi qualcosa mi dice che quando digito qualsiasi URL nel browser le richieste non vanno sulla porta 80 (?). Possibile???   :Shocked: 

Qualcosa non mi torna.

----------

## devilheart

forse hai ancora qualche regola nat attiva. comunque io proverei prima a far funzionare le cose impostando manualmente l'uso del proxy, poi puoi passare al transparent. ma squid e dansguardian non hanno qualche file di log per vedere cosa gli è arrivato?

----------

## fbcyborg

Dunque, 

Ho smanettato parecchio nel frattempo ed ho fatto un po' di cambiamenti.

Sto utilizzando squid+squidguard (ho visto che quest'ultimo sembra più facile da configurare/usare). Ho scoperto perché non arrivavano richieste sulla 80 su quell'interfaccia. Il problema era appunto iptables.

Quindi ricapitolando, ecco quello che ho fatto:

Ho attivato il nat:

```
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
```

E qui mi sono impicciato parecchio prima di capire che fosse questa ad essere sbagliata. Prima mettevo eth0 invece di eth1 perché, facevo riferimento all'interfaccia alla quale sono attaccati tutti i client (eth0) e non eth1. Ancora ho qualche dubbio, però ora funziona.

Poi ho messo un 1 fisso in /proc/sys/net/ipv4/ip_forward grazie a sysctl.conf.

Ora i client della sottorete vanno su Internet benissimo, senza limiti.

Passo successivo è stato quello di redirigere tutte le richieste in arrivo sulla porta 80 verso la 3128 (dove c'è Squid in ascolto).

```
iptables -t nat -A PREROUTING -d ! 10.0.0.0/24 -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
```

Ora i client non lo sanno neanche di essere dietro proxy.

Ora gli ultimi problemi sono i seguenti:

poter controllare/bloccare gli URL in https. Attenzione, più che altro bloccare, e non voglio/posso ovviamente fare caching di siti https.

bloccare porte di irc/amule/msn, e cose simili.

Intanto, per quanto riguarda le porte standard di emule ho fatto così:

```
iptables -t filter -A FORWARD -p tcp -m tcp --dport 4661:4711 -j REJECT --reject-with icmp-port-unreachable

iptables -t filter -A FORWARD -p udp -m udp --dport 4661:4711 -j REJECT --reject-with icmp-port-unreachable
```

Qualche altro suggerimento?

Grazie ancora.

----------

## devilheart

così però non va bene. se attivi il forwarding i client possono bypassare il proxy. in una soluzione con proxy routing, forwarding e masquerading devono essere disattivati. ora, non ricordo cosa implichi il redirect ma mi pare che così cambi solo la porta di destinazione. l'indirizzo della destinazione non è mutato e non è il server dove gira il proxy

----------

## fbcyborg

Non c'ho capito molto per la verità, però credo che nat e forwarding mi servano abilitati.

Ho trovato una lista di regole di iptables per bloccare diversi sistemi di chat e msn, yahoo messenger ecc.. 

Pensate che possa ancora andar bene?

----------

## devilheart

se il nat e forward sono attivi allora i pc interni possono sbattersene del proxy per tutte quelle connessioni che non sono esplicitamente dirottate sul proxy. potrebbe avere senso se vuoi che solo http sia inviato al proxy

----------

## fbcyborg

Alla fine a me interessa mettere un filtro alla navigazione e bloccare la maggior parte delle applicazioni più comuni, tipo MSN, chat e quant'altro.

Per questo cercavo una serie di regole "pronte per l'uso" e standard per bloccare una serie di cose.

----------

## oRDeX

Quindi, non vuoi bloccare *TUTTO* e permettere solo la navigazione attraverso il proxy?

----------

## fbcyborg

Ho scelto di non bloccare tutto perché poi avevo paura di avere problemi con iptables. Onestamente non lo conosco benissimo e vorrei impararlo (cerco anche libro buono).

Però posso sempre prendere in considerazione di bloccare tutto, così evito di dover bloccare esplicitamente programmi come amule, IRC e via dicendo... Ovvio che per programmi come skype che usano la porta 80 come alternativa, il discorso cambia.

Ora così come stanno le cose passa tutto, ma la navigazione è dietro proxy in transparent mode. Redirigo tutto ciò che arriva sulla 80, verso la 3128. Il problema è anche che non riesco ad applicare i filtri sui siti https, e quindi sono costretto a non farli passare per squid.

----------

## oRDeX

Bhè, per https il discorso non è semplice. Hai provato a cercare qualche howto a riguardo (https + squid)? Non ne so tantissimo in campo pratico, però posso dirti che un proxy che funge da itermediario in una comunicazione basata su ssl di norma non dovrebbe permettere il corretto funzionamento della stessa.

Per quanto riguarda skype, lui è capace di tutto  :Very Happy:  Anche con un proxy (basta inserirlo nelle opzioni) lui riesce a connettersi  :Razz:  Forse con l'aiuto di l7filter potresti tentare di bloccarlo, ma attualmente non so a che punto siano con questo problema.

Comunque, al tuo posto, proverei a sbattere ancora un pò contro iptbales   :Wink: 

----------

## fbcyborg

 *oRDeX wrote:*   

> Bhè, per https il discorso non è semplice. Hai provato a cercare qualche howto a riguardo (https + squid)?

 uuuuh! mamma mia! Sono in ricerca continua, ma non è molto chiaro come funzioni. Sembra che si possa fare, ma non funziona come dicono di fare. *oRDeX wrote:*   

>  Non ne so tantissimo in campo pratico, però posso dirti che un proxy che funge da itermediario in una comunicazione basata su ssl di norma non dovrebbe permettere il corretto funzionamento della stessa.

 E infatti... Io ovviamente non voglio cachare le pagine https, ma quantomeno poterle filtrare e bloccare qualche URL. *oRDeX wrote:*   

> 
> 
> Per quanto riguarda skype, lui è capace di tutto  Anche con un proxy (basta inserirlo nelle opzioni) lui riesce a connettersi  Forse con l'aiuto di l7filter potresti tentare di bloccarlo, ma attualmente non so a che punto siano con questo problema.

 Eh, infatti skype su questo punto di vista è proprio tosto! Comunque, questo l7filter, è interessante, se mi fa bloccare msn e quant'altro sarebbe il massimo *oRDeX wrote:*   

> 
> 
> Comunque, al tuo posto, proverei a sbattere ancora un pò contro iptbales  

 

Eh sì... c'è qualche manuale che mi consigli?

Grazie

----------

## oRDeX

Una cosa che ho letto a suo tempo è http://lartc.org/ ma ormai pare essere molto vecchio come documento...ed inoltre non parla di iptables nello specifico ma parla tanto anche di routing avanzato.

l7filter è una sorta di *modulo di pattern matching* che viene inserito in iptables. Ovviamente non da certezza al 100% di ottenere i risultati sperati, però su molti protocolli dicono che funzioni bene.

http://l7-filter.sourceforge.net/, per altro esiste la USE flag apposita per iptables.

Il discorso di https è particolare perchè, detta in modo semplice, si stabilisce una sorta di "fiducia" fra i due endpoint della connessione, di conseguenza, un proxy nel mezzo non fa funzionare le cose come dovrebbero. Se non sbaglio dovrebbero esistere due strategie diverse per raggirare la cosa. Se trovo qualche riferimento ti faccio sapere.  :Wink: 

Ma visto che vuoi filtrare "alcuni siti https" perchè non parti da un ACCEPT sulla 443 e poi fai DROP sulla base degli ip che vuoi bloccare?

----------

## fbcyborg

 *oRDeX wrote:*   

> Una cosa che ho letto a suo tempo è http://lartc.org/ ma ormai pare essere molto vecchio come documento...ed inoltre non parla di iptables nello specifico ma parla tanto anche di routing avanzato.

 In effetti cerco qualcosa di più recente e magari che non sia proprio del tutto "for dummies". Un manuale ben fatto dove spiega iptables anche per i profani sarebbe il massimo. *oRDeX wrote:*   

> 
> 
> l7filter è una sorta di *modulo di pattern matching* che viene inserito in iptables. Ovviamente non da certezza al 100% di ottenere i risultati sperati, però su molti protocolli dicono che funzioni bene.
> 
> http://l7-filter.sourceforge.net/, per altro esiste la USE flag apposita per iptables.

 Dovrei provare a riemergere iptables con quella flag. Ho letto anche un wiki.. ora vediamo di applicarlo. *oRDeX wrote:*   

> 
> 
> Il discorso di https è particolare perchè, detta in modo semplice, si stabilisce una sorta di "fiducia" fra i due endpoint della connessione, di conseguenza, un proxy nel mezzo non fa funzionare le cose come dovrebbero.

 Eh sì, ma infatti il punto sta tutto lì. Quello che dovrebbe fare squid, alla fine è "semplicemente" quello di inoltrare pari pari le richieste https e passare per squidguard. *oRDeX wrote:*   

>  Se non sbaglio dovrebbero esistere due strategie diverse per raggirare la cosa. Se trovo qualche riferimento ti faccio sapere.  

 Ti ringrazio, lo apprezzo molto! *oRDeX wrote:*   

> 
> 
> Ma visto che vuoi filtrare "alcuni siti https" perchè non parti da un ACCEPT sulla 443 e poi fai DROP sulla base degli ip che vuoi bloccare?

 

In effetti avevo pensato anche a questo!!! Magari dopo che ho fatto un po' di esperienza con iptables...  :Smile: 

Grazie ancora.

----------

## Kernel78

Scusa, ho sonno e mal di testa e non ho troppa voglia di leggere tutti i post ma a quanto ho capito non hai ancora risolto il tuo problema.

Posso permettermi di consigliarti un approccio al problema che sia meno incasinato ?

1) imposti squid come proxy normale, non trasparente e vedi se funziona

2) imposti in squid le regole per le whitelist o blacklist di siti che vuoi consentire o bloccare e vedi se funziona

3) modifichi la configurazione per avere squid come proxy trasparente e vedi se funziona

----------

## fbcyborg

Grazie!

Ma queste cose le ho già fatte tutte e funziona!

EDIT:

Stavo provando ad emergere l7filter-2.21 ma vedo che ci sono problemi di packet collision:

```
 * Detected file collision(s):

 *

 *      /usr/src/linux-2.6.28-hardened-r7/net/netfilter/Kconfig

 *      /usr/src/linux-2.6.28-hardened-r7/net/netfilter/Makefile

 *      /usr/src/linux-2.6.28-hardened-r7/net/netfilter/nf_conntrack_core.c

 *      /usr/src/linux-2.6.28-hardened-r7/net/netfilter/nf_conntrack_standalone.c

 *      /usr/src/linux-2.6.28-hardened-r7/include/net/netfilter/nf_conntrack.h

```

Ho letto qualche bug report, ma non vorrei togliere il supporto a conntrack nel kernel.. ammesso che questo risolva il problema..  :Neutral: 

----------

## Kernel78

Sarà che ho dormito 3 ore ma a rileggermi la discussione sono andato in confusione di brutto ...

cerco di andare con ordine:

 *Quote:*   

> A quanto ho sempre visto (e in base a come funzionano i classici router/modem adsl, io prendo come gateway l'indirizzo IP interno del router, e ovviamente non devo impostare sui browser che l'IP del router è il mio proxy server.

 

router, gateway e proxy sono cose decisamente diverse, giusto per far notare la confusione dovresti tener conto che si tratta si apparati o sw che lavorano a livelli diversi dello stack osi e servono a compiti diversi. Inoltre non ho mai visto nessun modem/router che faccia anche da proxy, in genere fungono da gateway ...

 *Quote:*   

> Perché è così complicato fare una cosa simile con Gentoo? 

 

utilizzare Gentoo come router non è affatto difficile ma non è quello che vuoi fare tu ...

 *Quote:*   

> Ma queste cose le ho già fatte tutte e funziona! 

 

e allora mi sfugge perchè non hai messo il tag [risolto] ?

----------

## devilheart

allora. prova a dare

```
sysctl -w net.ipv4.ip_forward=0
```

se i client non riescono ad aprire più pagine via http allora NON hai risolto il problema

comunque per bloccare emule&c devi mettere regole che si basino sull'applicazione che genera il pacchetto invece che usare le porte. per fare ciò usa il modulo ]ipp2p

----------

## fbcyborg

Allora riepilogo per riassumere un attimo la situazione.

Devo ammettere che è la prima volta che faccio un server su misura per una ditta e quindi mi trovo di fronte ad alcune cosette che non ho mai visto.

Inoltre sono quasi profano di iptables ed ecco uno dei perché di questo thread.

L'esigenza primaria (molto a grandi linee - poi ci sono tanti altri dettagli nel merito dei quali non entro) che avevo io è questa: 

server di dati con Samba (directory condivise per lo storage di tutti i dati aziendali ecc..)

Filtro per Internet (e qui si può scrivere un libro).

Sempre a linee generiche ecco come funzionano le cose:

2 interfacce di rete: eth0 ed eth1.

eth1 connessa a internet (prende IP dal router di alice) 192.168.1.X

eth0 ip fisso 10.0.0.1/24 con Server DHCP che rilascia IP su questa interfaccia.

Ora, i client della subnet 10.0.0.0 devono accedere alle risorse condivise, e nella fattispecie ad Internet, MA, con restrizioni:

NO siti inutili (webmessenger, blog, porno, e-commerce e quant'altro sia inutile a tale lavoro)

NO chat, MSN, ecc..

NO P2P

All'inizio facevo un casino con iptables perché non lo conosco benissimo (purtroppo) quindi il fatto che non funzionasse quasi nulla era dovuto al fatto che sbagliavo a dare la regola di NAT.

Scrivevo 

```
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
```

invece di 

```
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
```

Non riuscivo a capire perché con eth0 non va e con eth1 sì... non so, forse perché l'interfaccia di output per i client della subnet 10.0.0.0/24 è eth1 e non eth0 (questo me lo saprete dire meglio sicuramente voi).

Per quanto riguarda il filtro dei siti ho risolto (anche se in parte visto che i siti https non riesco a filtrarli - ed anche se sto appunto pensando di bloccarli con iptables qualora mi venisse richiesto).

Poi ho abilitato il forwarding, (il contenuto del file /proc/sys/net/ipv4/ip_forward è sempre 1).

Ora l'accesso ad Internet è illimitato per la subnet 10.0.0.0/24.

Quindi è ora di mettere il filtro.

Ho fatto in modo che tutte le richieste in arrivo sulla porta 80 me le deve ridirigere sulla 3128 dove c'è in ascolto squid. Così in modalità trasparente la navigazione avviene tramite proxy. Con squidGuard posso così negare l'accesso ai siti che dico io, filtrando gran parte dei siti inutili anche grazie all'aiuto di blacklist già pronte.

Ora però dovrei bloccare appunto chat, p2p, e quanto detto prima.

Quello che mi chiedevo io (per ultimare il lavoro) era se ci fossero delle altre cosette da mettere a punto meglio, prima di concludere tutto.

Quindi mi mancano questi blocchi che ho appena accennato. l7-filter non me lo fa installare per i motivi di cui sopra.

Ora cercherò di provare questo ipp2p.  :Smile: 

EDIT: Ho provato ipp2p, ma non funziona.

La regola che do per bloccare il traffico emule/kazaa è la seguente ma non sortisce alcun effetto:

```
iptables -A FORWARD -m ipp2p --edk --kazaa -j DROP
```

Riesco comunque a connettermi ai server ed2k ed a scaricare.

Anche con queste tre regole tutte insieme, alla fine poi riesce sempre a connettersi:

```
iptables -I FORWARD -m ipp2p --ipp2p -j DROP

iptables -I OUTPUT -m ipp2p --ipp2p -j DROP

iptables -I INPUT -m ipp2p --ipp2p -j DROP
```

KAD invece si connette sempre! Quindi le regole sono totalmente inefficaci.  :Sad: 

Grazie a tutti per l'aiuto

----------

## Kernel78

scusa ma in questo periodo ho sempre troppo sonno per aver la certezza di capire esattamente il tuo problema ...

da quanto ho capito tu vorresti concedere di uscire su internet solo per fruire della navigazione su alcuni siti.

Nel caso abbia capito correttamente la tua problematica ti basta evitare di mettere un gateway che faccia uscire il traffico e mettere solo un proxy con una whitelist, in questo modo non avresti nemmeno il problema di bloccare le chat e il p2p perchè le macchine interne non avrebbero modo di collegarsi a internet se non tramite il proxy che permetterà solo il transito http e https.

A voler far le cose veramente per bene bisognerebbe poi filtrare quegli applicativi che possono essere configurati per sfruttare quelle porte per i fattacci loro ma inizia a diventare una battaglia contro i mulini a vento, puoi solo accontentarti di rendere la vita difficile a chi vuole abusare delle risorse aziendali.

----------

## fbcyborg

Sì diciamo che hai afferrato la questione. 

Intanto ti ringrazio per il tempo che dedichi a questo thread nonostante il sonno!  :Smile: 

Il fatto è che poi dovrei preoccuparmi anche di aprire alcune porte, ad esempio per la posta elettronica, per consentire ai diversi antivirus di aggiornarsi, a windows update di collegarsi, ecc... 

Per questo ho preferito l'approccio al contrario, cercando di bloccare il più possibile.

Fin'ora sono riuscito a bloccare amule (ed2k+kad - anche se per kad non sono sicurissimo che funzionerà sempre per via del fatto che non so se usa una o più porte diverse), e ho inserito delle regole anche per bittorrent.

Le regole usate sono queste:

```
iptables -A FORWARD -p tcp -m multiport --dports 6881,6882,6883,6884,6885,6886,6887,6888,6889,1214 -j REJECT

iptables -A FORWARD -p udp -m multiport --dports 6881,6882,6883,6884,6885,6886,6887,6888,6889,1214 -j REJECT

iptables -A FORWARD -p tcp -m multiport --dports 6346,6347 -j REJECT

iptables -A FORWARD -p udp -m multiport --dports 6346,6347 -j REJECT

iptables -A FORWARD -p tcp -m multiport --dports 4500,4711,4665,4661,4672,4662,8080,9955 -j REJECT

iptables -A FORWARD -p udp -m multiport --dports 4500,4711,4665,4661,4672,4662,8080,9955 -j REJECT

iptables -A FORWARD -p tcp --dport 4242:4299 -j REJECT

iptables -A FORWARD -p udp --dport 4242:4299 -j REJECT

iptables -A FORWARD -p tcp --dport 6881:6999 -j REJECT

iptables -A FORWARD -p udp --dport 6881:6999 -j REJECT
```

----------

## oRDeX

Chiarito il tuo problema al 100%, tralasciando un attimo il problema di https che può essere affrontato diversamente alla fine   :Razz: 

Allora, dato che i client dovranno avere la possibilità di collegarsi a determinati servizi è il caso di lasciare sia il gateway che il forwarding di base. Quindi io pensavo ad una configurazione di questo tipo:

```
# sysctl -w net.ipv4.ip_forward=1

# iptables -t nat -A POSTROUTING -d ! 10.0.0.0/24 -j MASQUERADE #Volendo puoi usare l'interfaccia come parametro, ma io in genere preferisco fare così

# iptables -P FORWARD DROP #Di default non si forwarda nulla!

# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Su questa regola sono leggermente incerto ma dovrebbe andare

# iptables -A FORWARD -d servermail.mail.fu -p tcp --dport 110 -j ACCEPT #Apri accesso al server pop3

# #Come la riga precedente per le altre porte da lasciar passare

# iptables -t nat -A PREROUTING -d ! 10.0.0.0/24 -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 # LA tua regola, ma funziona? non dovresti specificare l'ip del proxy? io userei la seguente:

# iptables -t nat -A PREROUTING -d ! 10.0.0.0/24 -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:3128

```

Spero funzioni tutto e spero di esserti stato di aiuto   :Smile: 

----------

## fbcyborg

Grazie oRDeX,

le provo quanto prima le regole, prima però alcune domande:

1) 

```
iptables -P FORWARD DROP #Di default non si forwarda nulla! 
```

Quindi con questa è bloccato tutto il traffico (IN e OUT), a meno che non se ne dia consenso esplicito?

2)

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

Questa non ho capito molto a cosa serva!

3)Quindi per la posta in uscita farò:

```
iptables -A FORWARD -d servermail.mail.fu -p tcp --dport 25 -j ACCEPT 
```

 :Question:   :Question:   :Question: 

4) Sì, la mia regola funziona. Non mi chiedere come!!!  :Very Happy:  Ma tutto il traffico viene rediretto verso il proxy sulla 3128.

5) Che cambia all'atto pratico fra quella che uso io e la seguente?

```
iptables -t nat -A PREROUTING -d ! 10.0.0.0/24 -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:3128 
```

Cioè, intuisco ma non ne sono poi così sicuro.

Il problema poi sorgerà anche quando dovrò abilitare altri traffici, come quello per gli aggiornamenti degli antivirus, windows update, ecc.. 

Inoltre, il discorso è che così facendo dovrò fracassarmi le scatole ogni volta che non gli funzionerà qualcosa...  :Sad: 

----------

## devilheart

la seconda regola cambia anche l'indirizzo di destinazione del pacchetto

----------

## oRDeX

 *fbcyborg wrote:*   

> Grazie oRDeX,
> 
> 

 prego! *Quote:*   

> 
> 
> le provo quanto prima le regole, prima però alcune domande:
> 
> 1) 
> ...

 non incasiniamoci con i termini  :Razz:  sei su un router, se per IN e OUT intendi i pacchetti "passanti", quindi quelli FORWARDATI, allora la risposta è si: il router non si lascia attraversare come policy di default. *Quote:*   

> 
> 
> 2)
> 
> ```
> ...

 non sono certo al 100% del suo funzionamento (perchè non l'ho mai testata), ma in pratica permette che connessioni in stato ESTABILISHED o RELATED possano "attraversare il router". Questo perchè, se stabilisci una connessione sulla porta XX che il server rimappa sulla YY, una volta stabilita, essa deve continuare a funzionare nonostante il remapping. *Quote:*   

> 
> 
> 3)Quindi per la posta in uscita farò:
> 
> ```
> ...

 esatto.  *Quote:*   

> 
> 
> 4) Sì, la mia regola funziona. Non mi chiedere come!!!  Ma tutto il traffico viene rediretto verso il proxy sulla 3128.
> 
> 

 si sulla 3128, ma non capisco come mai vada a finire sulla 3128 proprio del proxy  :Razz:  *Quote:*   

> 
> 
> 5) Che cambia all'atto pratico fra quella che uso io e la seguente?
> 
> ```
> ...

 Questa regola modifica l'header del pacchetto, prima che questo venga instradato, in particolare modifica il campo destinazione e porta-destinazione secondo i valori specificati come argomento. *Quote:*   

> 
> 
> Il problema poi sorgerà anche quando dovrò abilitare altri traffici, come quello per gli aggiornamenti degli antivirus, windows update, ecc.. 
> 
> Inoltre, il discorso è che così facendo dovrò fracassarmi le scatole ogni volta che non gli funzionerà qualcosa... 

 

Sono sempre singole porte da aprire. In questo modo (default DROP) hai una sicurezza più alta. Tu prima avevi bloccato le porte di emule a scaglioni: a parte che ora di default viene impostata una porta davvero a caso, non più la 4662 (se non erro ora si comporta così), o comunque basterebbe impostare una porta casuale in modo manuale per continuare a far andare tutto bene   :Rolling Eyes: 

----------

## fbcyborg

OK, ti ringrazio, cercherò prima di tutto di fare tesoro dei tuoi preziosi consigli (anche per casi futuri) e di impostare le cose in modo che si adattino meglio alla mia situazione.

Il fatto che redirigo tutto sulla 3128, lo faccio apposta perché così posso filtrare la navigazione e bloccare gli URL che voglio.. non so se era questa la tua perplessità.

----------

## oRDeX

la mia perplessità era legata al fatto che quella regola redirige tutto sulla 3128, come dici tu, non sulla 3128 del proxy. Quindi non capisco come funzioni  :Razz: 

Che il proxy, dato che è lo stesso router, abbia qualche politica sua di controllo?   :Rolling Eyes: 

----------

## fbcyborg

Forse funziona perché in squid.conf ho messo: 

```
http_port 3128
```

Quindi magari non ascolta su un indirizzo preciso, ma su tutti(?).

Non lo so.. ho anche io il dubbio, ma onestamente mi importa fino ad un certo punto!!!  :Very Happy: 

visto che funzionare funziona!  :Razz: 

----------

## oRDeX

mh..al massimo sarà in ascolto su tutti i suoi indirzzi....non su "tutti"   :Rolling Eyes:  bhu, comunque per adesso questo non è un problema dato che funziona tutto (sicuro che tu non abbia impostato il proxy in firefox?)

----------

## fbcyborg

Sì sì, assolutamente sicuro! Anzi, per me è stato un traguardo quando sono riuscito a far navigare i client senza impostare il proxy!  :Very Happy: 

Prima ci riuscivo solo tramite il proxy!

----------

## Kernel78

 *fbcyborg wrote:*   

> Sì sì, assolutamente sicuro! Anzi, per me è stato un traguardo quando sono riuscito a far navigare i client senza impostare il proxy! 
> 
> Prima ci riuscivo solo tramite il proxy!

 

e sei sicuro che passino dal proxy ? non è che vengono semplicemente forwardati ?

anche io sono un po' perplesso (ma fa parte della mia natura quindi non faccio testo  :Laughing:  )

----------

## fbcyborg

Fammi fare un test a tua scelta, così sei sicuro che passa tutto per il proxy!

A proposito... Io tramite squidguard riesco a bloccare qualsiasi URL, però quelli della rete interna no.. Mi spiego meglio. Sempre sul server ho installato SARG, accessibile dall'indirizzo http://10.0.0.1/squid-reports . Con squidGuard non riesco a fare in modo che tale URL sia accessibile solo da uno o più ip (al max 2). Come si può risolvere?

----------

## Kernel78

 *fbcyborg wrote:*   

> Fammi fare un test a tua scelta, così sei sicuro che passa tutto per il proxy!

 

beh, la cosa più banale è 

```
echo 0 > /proc/sys/net/ipv4/ip_forward 
```

così disabiliti il forwarding e se qualcosa passa deve passare dal proxy o puoi anche provare a fermare il proxy e a vedere se riesci a navigare o meno  :Wink: 

 *Quote:*   

> A proposito... Io tramite squidguard riesco a bloccare qualsiasi URL, però quelli della rete interna no.. Mi spiego meglio. Sempre sul server ho installato SARG, accessibile dall'indirizzo http://10.0.0.1/squid-reports . Con squidGuard non riesco a fare in modo che tale URL sia accessibile solo da uno o più ip (al max 2). Come si può risolvere?

 

essendo nella rete interna tutte le macchine possono raggiungere la macchina con SARG direttamente, per impedirlo dovresti metterci un firewall o mettere la macchina fuori dalla rete, dipende dalle tue esigenze

----------

## fbcyborg

Ovviamente con squid stoppato non naviga, te lo dico senza fare questa prova, perché per sbaglio l'avevo già fatta in passato!  :Smile: 

Quindi non c'è modo di bloccare l'accesso a quel sito.... nemmeno facendo con un sistema di password.. mmh..

----------

## Kernel78

 *fbcyborg wrote:*   

> Quindi non c'è modo di bloccare l'accesso a quel sito.... nemmeno facendo con un sistema di password.. mmh..

 

sarg non lo conosco, potrebbe avere un sistema di protezione suo ma essendo interno alla rete viene raggiunto direttamente quindi non puoi basarti sul proxy per filtrare gli accessi ...

----------

## fbcyborg

Ok, grazie, vedrò se esiste qualche script php da metterci sopra!  :Smile: 

----------

## fbcyborg

Avevi ragione, solo che per inesperienza ho sottovalutato la cosa.  :Sad: 

 *devilheart wrote:*   

> se il nat e forward sono attivi allora i pc interni possono sbattersene del proxy per tutte quelle connessioni che non sono esplicitamente dirottate sul proxy. potrebbe avere senso se vuoi che solo http sia inviato al proxy

 

Alla fine il fatto che esistano programmi del genere invisible proxy, mi ha spinto ad optare per la drastica scelta:

bloccare tutto di default e autorizzare esplicitamente le connessioni.  :Sad: 

La prima cosa che ho fatto è inserire una blacklist di proxy in squidguard.

Il problema forse si ripresenta se viene utilizzato qualche programmino che faccia la stessa funzione.

Purtroppo anche se c'è squidguard, se qualcuno installa qualche programma proxy, baypassa i controlli di squidguard.

Devo trovare una soluzione anche a questo.  :Sad: 

Attualmente il mio file rules-save è il seguente:

```
# Generated by iptables-save v1.4.2 on Fri May 15 16:37:36 2009

*nat

:PREROUTING ACCEPT [3679:386755]

:POSTROUTING ACCEPT [2582:199185]

:OUTPUT ACCEPT [4839:351636]

[233:11664] -A PREROUTING -d ! 10.0.0.0/24 -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

[3941:250829] -A POSTROUTING -o eth1 -j MASQUERADE

COMMIT

# Completed on Fri May 15 16:37:36 2009

# Generated by iptables-save v1.4.2 on Fri May 15 16:37:36 2009

*mangle

:PREROUTING ACCEPT [152279:78315888]

:INPUT ACCEPT [134042:69556679]

:FORWARD ACCEPT [18037:8736109]

:OUTPUT ACCEPT [98110:69755897]

:POSTROUTING ACCEPT [117017:78647198]

COMMIT

# Completed on Fri May 15 16:37:36 2009

# Generated by iptables-save v1.4.2 on Fri May 15 16:37:36 2009

*filter

:INPUT ACCEPT [16057:6100575]

:FORWARD ACCEPT [4558:1617331]

:OUTPUT ACCEPT [15465:5696586]

[6:288] -A INPUT -s ! 10.0.0.2/32 -d 10.0.0.1/32 -p tcp -m tcp --dport 10000 -j REJECT --reject-with icmp-port-unreachable

[24:1152] -A FORWARD -p tcp -m tcp --dport 4661:4711 -j REJECT --reject-with icmp-port-unreachable

[31:1584] -A FORWARD -p udp -m udp --dport 4661:4711 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p tcp -m multiport --dports 6881,6882,6883,6884,6885,6886,6887,6888,6889,1214 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p udp -m multiport --dports 6881,6882,6883,6884,6885,6886,6887,6888,6889,1214 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p tcp -m multiport --dports 6346,6347 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p udp -m multiport --dports 6346,6347 -j REJECT --reject-with icmp-port-unreachable

[27:1248] -A FORWARD -p tcp -m multiport --dports 4500,4711,4665,4661,4672,4662,5000,6543,8080,9955,56652 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p udp -m multiport --dports 4500,4711,4665,4661,4672,4662,5000,6543,8080,9955,56652 -j REJECT --reject-with icmp-port-unreachable

[6:288] -A FORWARD -p tcp -m tcp --dport 4242:4299 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p udp -m udp --dport 4242:4299 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p tcp -m tcp --dport 6881:6999 -j REJECT --reject-with icmp-port-unreachable

[0:0] -A FORWARD -p udp -m udp --dport 6881:6999 -j REJECT --reject-with icmp-port-unreachable

COMMIT

# Completed on Fri May 15 16:37:36 2009

```

```
# cat /proc/sys/net/ipv4/ip_forward

1

```

Ma ho visto che non è che sia poi così buono.

A quanto pare dovrei tasformarlo nel seguente modo:

abilitare il nat (?) (già fatto)

negare tutto

```
iptables -P FORWARD DROP
```

 ?????

redirigere tutte le richieste in arrivo sulla 80 verso la 3128 del proxy ovvero

```
[233:11664] -A PREROUTING -d ! 10.0.0.0/24 -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
```

 abilitare https (443 ?)

 abilitare pop3 e smtp

 abilitare windows update

 abilitare aggiornamenti vari antivirus

Per favore qualcuno mi può dare una mano?

L'ordine delle operazioni è corretto?

Grazie, come sempre!  :Smile: 

EDIT: mi sa che alla fine ho risolto un'alta percentuale di questi problemi aggiungendo le blacklist dei proxy su squidguard e credo che si risolverà definitivamente quando toglierò a tutti i client winzozz i privilegi di amministratore. E' chiaro che una soluzione sicura al 100% non esiste, ma così facendo almeno si dovrebbero limitare un bel po' di cose. Creando account limitati almeno si potrà evitare che gli utenti installino programmi che fanno da proxy.

----------

## devilheart

io direi

1)togli il masquerade. visto che il server non manda roba su una interfaccia pubblica, il nat è solo uno spreco di risorse. ricorda solo di configurare opportunamente il router adsl

2)di default blocca tutto. questo vuol dire che INPUT, FORWARD e OUTPUT devono essere drop. sostituisci anche tutti i REJECT con dei DROP perché coi REJECT è come dire all'attaccante "hey, c'è un firewal che blocca"

3)abilita un po' alla volta solo i servizi che ti servono. se ti accorgi che il filtraggio in base alla porta non ti è sufficiente allora dovrai ricorrere alla deep packet inspection

come altra opzione c'è il modulo string di iptables. con esso puoi ad esempio bloccare tutti i pacchetti che contengono la parola "facebook" all'internoLast edited by devilheart on Mon Jun 01, 2009 11:03 am; edited 1 time in total

----------

## fbcyborg

Ok, ti ringrazio, vedrò cosa riesco a combinare!  :Smile: 

----------

## fbcyborg

Stavo tentando di bloccare l'accesso a un sito se questo viene richiesto da un certo mac address, solo che ottengo un errore:

```
# iptables -t filter -A OUTPUT -m mac --mac-source 00:00:00:00:00:00 -d 92.60.65.198 -p tcp -m tcp --dport 80 -j DROP

iptables: No chain/target/match by that name
```

Qual'è il problema?

Da notare che questa prova la sto facendo in locale sul mio pc, quindi la regola penso che sarà forse leggermente diversa quando la farò sul server.

----------

## devilheart

ti serve CONFIG_NETFILTER_XT_MATCH_MAC

----------

## fbcyborg

L'ho compilato ma adesso mi da "iptables: invalid argument".

----------

## devilheart

http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html

----------

## fbcyborg

Grazie, 

l'avevo letto quello, ma non ci riesco. Non capisco come specificare che se quel source mac, vuole un certo dest ip, la richiesta deve essere droppata.

EDIT:

Allora, con questo riesco a bloccare il sito:

```
iptables -A OUTPUT -s 192.168.1.100/32 -d 92.60.65.198/32 -p tcp -m tcp -j DROP
```

Ora devo riuscire a bloccarlo tramite il mac address.

----------

## devilheart

e mettere solo la destinazione? una semplice regola che blocca tutto quello che vuole andare su 92.60.65.198, indipendentemente da chi ci vuole andare

----------

## fbcyborg

Sarebbe una buona idea, ma ripensandoci alla fine il discorso è sempre lo stesso: usa un proxy e baypassa il filtro.

----------

## Kernel78

La questione mi interessa e mi piacerebbe discuterla più approfonditamente ma non ne ho il tempo.

Intanto mi permetto di farti notare che il mac address di una scheda lo cambi in meno di 3 secondi e se non sbaglio c'è almeno un sw in portage che consente di farlo quindi ti sconsiglio di usarlo come criterio per filtrare

 *fbcyborg wrote:*   

> Sarebbe una buona idea, ma ripensandoci alla fine il discorso è sempre lo stesso: usa un proxy e baypassa il filtro.

 

basta usare whitelist che non contemplino questi proxy o una blacklist in cui li inserisci ...

----------

## fbcyborg

Infatti uso blacklist che bloccano questi proxy, ma non puoi bloccarli tutti, infatti ogni tanto trovo nella lista degli url visitati, un proxy nuovo.

Per quanto riguarda il programma lo so, si chiama macchanger, ma magari su winzozz è più difficile, e magari lo smanettone di turno forse non ci pensa.

----------

## djinnZ

 *Kernel78 wrote:*   

> ti sconsiglio di usarlo come criterio per filtrare

 a meno che non stai parlando di bloccare un router (almeno il mio non è in grado di cambiare mac) il filtro è poco utile e complicato.

Usare l'arp statico, il dhcp per mac, ed arpwatch invece è più utile e costruttivo.

----------

## fbcyborg

Fico arpwatch! Devo capire bene come funziona però, perché l'ho fatto partire come servizio, e poi?

----------

## fbcyborg

Eccomi di nuovo con dei problemi con iptables.

Sul router di alice (192.168.1.1) ho inoltrato tutte le richieste che arrivano sulla 5060 UDP e dalla 10000 alla 10040 UDP verso il server 192.168.1.2 (eth1).

Il server sull'interfaccia eth0 ha l'IP 10.0.0.1. Ora vorrei fare in modo che tutte le richieste che arrivano sul server sulla 5060 UDP e dalla 10000 alla 10040 UDP vengano inoltrate all'IP 10.0.0.10.

Ho provato la seguente regola di iptables ma non c'è verso che funzioni.

```
iptables -t nat -A PREROUTING -i eth1 -p udp -m multiport --dport 5060,10000:10040 -j DNAT --to-destination 10.0.0.10
```

Ho provato anche con "-i eth0", tante volte avessi sbagliato lì, ma non funziona.

Quale può essere il problema?

Grazie

----------

## fbcyborg

Aiuto, 

ho una regola di iptables, nel mio file rules-save come la seguente:

```
[6:288] -A INPUT -s ! 10.0.0.2/32 -d 10.0.0.1/32 -p tcp -m tcp --dport 10000 -j DROP
```

Vorrei fare in modo che anche l'indirizzo 10.0.0.3 possa fare richieste sulla porta 10000. Come posso aggiungere che l'INPUT -s sia diverso da 10.0.0.2 e da 10.0.0.3 ? 

Devo per forza mettere un'altra regola del tipo:

```
iptables -A INPUT -s ! 10.0.0.3/32 -d 10.0.0.1/32 -p tcp -m tcp --dport 10000 -j DROP
```

Ma poi non cozza con quella sopra?

Oppure posso droppare tutte le richieste sulla 10000 (però solo quelle provenienti dalla sottorete 10.0.0.0) e abilitare successivamente dagli IP che voglio.. Ma mi date una mano?

----------

## gutter

Potresti pensare di usare una /30 ... in questo modo includi però anche il .1

Davide

----------

## fbcyborg

Grazie, 

per ora ho trovato questa soluzione:

```
iptables -A INPUT -m iprange --src-range 10.0.0.4-10.0.0.255 -d 10.0.0.1/32 -p tcp -m tcp --dport 10000 -j DROP
```

Mi consente l'accesso sulla 10000 solo da 10.0.0.1 (che è appunto il server) a 10.0.0.3.

Mi va anche bene tutto sommato!  :Smile: 

----------

## gutter

 *fbcyborg wrote:*   

> 
> 
> Mi va anche bene tutto sommato! 

 

Perfetto ... sarebbe interessante vedere se iptables supporta qualcosa in stile wildcard mask ... che in queste situazioni sono più versatili  :Smile: 

----------

## fbcyborg

Non lo conosco, però a prima vista il mio intento era quello di dire: se la richiesta non proviene da 10.0.0.2 oppure da 10.0.0.3 droppa. Quindi volevo mettere un !(10.0.0.2 OR 10.0.0.3) invece che solo ! 10.0.0.2. Strano che non si possa fare, o meglio, mica lo so se è possibile.

----------

## oRDeX

Bhè iptables, in quanto firewall, deve essere il più semplice ed efficiente possibile..ricordiamoci che ogni pacchetto raggiunto dalla macchina attarversa le varie chain...quindi mettersi a valutare espressioni booleane comincerebbe a diventare pesante   :Wink: 

----------

## fbcyborg

Capisco, e soprattutto grazie per la risposta. Con questo ho avuto la conferma che quello che volevo fare io non si può fare!  :Smile: 

----------

## gutter

 *oRDeX wrote:*   

> Bhè iptables, in quanto firewall, deve essere il più semplice ed efficiente possibile..ricordiamoci che ogni pacchetto raggiunto dalla macchina attarversa le varie chain...quindi mettersi a valutare espressioni booleane comincerebbe a diventare pesante  

 

Non penso che il problema sia il costo computazionale ... pensa solo a come viene deciso su quale interfaccia instradare un pacchetto in base all'AND tra indirizzo IP e Netmask   :Wink: 

----------

## devilheart

 *fbcyborg wrote:*   

> Non lo conosco, però a prima vista il mio intento era quello di dire: se la richiesta non proviene da 10.0.0.2 oppure da 10.0.0.3 droppa. Quindi volevo mettere un !(10.0.0.2 OR 10.0.0.3) invece che solo ! 10.0.0.2. Strano che non si possa fare, o meglio, mica lo so se è possibile.

 puoi fare una chain con default policy drop e due regole che accettano il traffico da 10.0.0.2 e 10.0.0.3

----------

