Discussioni sul sistema operativo Linux
 

NAT e stream

sunoz 28 Ott 2015 10:41
[ This is a repost of the following article: ]
[ From: sunoz <nomail@nospam.invalid> ]
[ Subject: NAT e stream ]
[ Newsgroups: it.comp.reti.locali ]
[ Message-ID: <n02siu$1kk$1@speranza.aioe.org> ]


Ho un raspberrypi che mi fa a comando (on/off) nat per una ipcam o nessun nat
abilitando il web server integrato:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to $IP *******
iptables -t nat -A POSTROUTING -d $IP ******* -p tcp --dport 80 -j SNAT --to
$RASPY

Attivo il nat ad ipcam, e mi collego da remoto al mio ip pubblico sulla porta 80
e vedo le immagini della ipcam.

Resetto il nat (cancello tabella nat di iptables), e dovrei aspettarmi che il
flusso di immagini si blocchi...
Invece, nonostante la tabella nat sia vuota e la porta 80 sia ritornata al
server
web integrato, il flusso immagini continua.
Si blocca solo se faccio da browser (firefox) il refresh della pagina!!!

E' normale?


--
Una password si puo' cambiare.
Un dato biometrico e' rubato per sempre!
Medita!
Giulia 28 Ott 2015 11:00
> E' normale?

Probabilmente tiene l' informazione sulla la sessione tcp da qualche altra parte
e
una volta che la sessione e' cominciata non puoi smettere, non mi preoccuperei
non mi sembra un problema di sicurezza.

Giulia
sunoz 28 Ott 2015 13:33
Giulia <far5893@iperbole.bologna.it> wrote:
> Probabilmente tiene l' informazione sulla la sessione tcp da qualche altra
parte e
> una volta che la sessione e' cominciata non puoi smettere, non mi preoccuperei
> non mi sembra un problema di sicurezza.

Se la connessione è mia, mi farebbe anche comodo.
Una volta instaurata, faccio flush della tabella nat, e nessun altro si può
collegare.
Se invece, mentre sono connesso io, si collega qualcun'altro e volessi
stopparlo....

--
Una password si puo' cambiare.
Un dato biometrico e' rubato per sempre!
Medita!
Max_Adamo 28 Ott 2015 21:08
Il Wed, 28 Oct 2015 12:33:34 +0000, sunoz ha scritto:

> Se invece, mentre sono connesso io, si collega qualcun'altro e volessi
> stopparlo....

1. puoi disabilitare ipforwarding, o bloccheresti altri servizi? Funziona?

2. ho gugolato al posto tuo: tcpkill -i eth0 -9 port 80
però, resta in ascolto, quindi dovresti killarlo a sua volta dopo qualche
secondo.

--
Massimiliano Adamo
Max_Adamo 28 Ott 2015 21:10
Il Wed, 28 Oct 2015 20:08:37 +0000, Max_Adamo ha scritto:

> 2. ho gugolato al posto tuo: tcpkill -i eth0 -9 port 80 però, resta in

tcpkill fa parte di un pacchetto che si chiama dsniff

--
Massimiliano Adamo
sunoz 29 Ott 2015 14:52
Max_Adamo <maxadamo@usenet.cnntp.org> wrote:
> tcpkill fa parte di un pacchetto che si chiama dsniff

Il pacchetto dsniff lo avevo già installato tempo fa.
Ti ricordi dove avevi trovato quel giochetto col tcpdump?
O almeno, con che chiave lo avevi cercato?
In effetti, funziona...

Mi piacerebbe capire il perchè del comportamento e se è possibile
bloccarlo.


--
Una password si puo' cambiare.
Un dato biometrico e' rubato per sempre!
Medita!
Skull 29 Ott 2015 15:18
On 28/10/15 13:33, sunoz wrote:
> Giulia <far5893@iperbole.bologna.it> wrote:
>> Probabilmente tiene l' informazione sulla la sessione tcp da qualche altra
parte e
>> una volta che la sessione e' cominciata non puoi smettere, non mi
preoccuperei
>> non mi sembra un problema di sicurezza.
>
> Se la connessione è mia, mi farebbe anche comodo.
> Una volta instaurata, faccio flush della tabella nat, e nessun altro si può
collegare.
> Se invece, mentre sono connesso io, si collega qualcun'altro e volessi
stopparlo....

Il "problema" è semplicemente una conseguenza del fatto che eliminare la
regola di NAT non ne elimina lo stato associato nella tabella di conntrack.

Per maneggiare quella iptables da solo non basta, ti servono i
conntrack-tools.
MaxAdamo 29 Ott 2015 16:01
Il giorno giovedì 29 ottobre 2015 14:52:57 UTC+1, sunoz ha scritto:
> Max_Adamo <maxadamo@usenet.cnntp.org> wrote:
>> tcpkill fa parte di un pacchetto che si chiama dsniff
>
> Il pacchetto dsniff lo avevo già installato tempo fa.
> Ti ricordi dove avevi trovato quel giochetto col tcpdump?
> O almeno, con che chiave lo avevi cercato?


intendi dire la ricerca su google o.O ? boooh
close tcp connection, kill tcp connection... non ricordo.

> In effetti, funziona...

quindi:
while lsof -nPi|grep ':80->'; do
tcpkill -i eth0 -9 port 80 &
sleep 1
pkill -9 -f tcpkill
done


> Mi piacerebbe capire il perchè del comportamento e se è possibile
> bloccarlo.

ti ha risposto maestro Skull, ma secondo me per il tuo uso (che mi pare che
sia domestico) le tre righe che ti ho scritto sopra bastano e avanzano.
sunoz 31 Ott 2015 14:40
MaxAdamo <maxadamo@gmail.com> wrote:
> quindi:
> while lsof -nPi|grep ':80->'; do
> tcpkill -i eth0 -9 port 80 &
> sleep 1
> pkill -9 -f tcpkill
> done


> ti ha risposto maestro Skull, ma secondo me per il tuo uso (che mi pare che
> sia domestico) le tre righe che ti ho scritto sopra bastano e avanzano.

Mmmmh! Idea buona... NoBuono.

Non funziona in quanto (e Skull lo ha spiegato) una volta instaurata una
deviazione nat, non c'è un processo fisico locale in ascolto.

O meglio: il server web (nginx) lo stoppo ed instauro il nat (inutile tenerlo
attivo). Dopo la chiusura del nat lo riavvio.

La riga lsof, non vede un processo (in quanto i pacchetti transitano in modo
trasparente) e quindi esce senza killare.

Se anche tenessi nginx avviato, suppongo non ci sarebbero comunque pacchetti
in transito, in quanto il nat li devia prima (e nginx non saprebbe neppure
della loro esistenza, trovandosi in stato comatoso)...

Usando invece i conntrack-tools ( conntrack -D -g ), viene chiusa la
connessione.

Quindi, ho dato:
iptables -t nat --flush
conntrack -D -g
wait 1
conntrack -D -g

Due volte, in quanto la prima, mi svuota il flusso, e la seconda (paranoid
mode on) mi conferma che il flusso dati sia effettivamente terminato (paranoid
mode off).

:)

--
Una password si puo' cambiare.
Un dato biometrico e' rubato per sempre!
Medita!
Max_Adamo 1 Nov 2015 13:25
Il Sat, 31 Oct 2015 13:40:39 +0000, sunoz ha scritto:

> MaxAdamo <maxadamo@gmail.com> wrote:
>> quindi:
>> while lsof -nPi|grep ':80->'; do
>> tcpkill -i eth0 -9 port 80 &
>> sleep 1 pkill -9 -f tcpkill
>> done
>
>
>> ti ha risposto maestro Skull, ma secondo me per il tuo uso (che mi pare
>> che sia domestico) le tre righe che ti ho scritto sopra bastano e
>> avanzano.
>
> Mmmmh! Idea buona... NoBuono.
>
> Non funziona in quanto (e Skull lo ha spiegato) una volta instaurata una
> deviazione nat, non c'è un processo fisico locale in ascolto.

ok, mi cospargo il capo di cenere.

> Quindi, ho dato:
> iptables -t nat --flush
> conntrack -D -g
> wait 1
> conntrack -D -g

beh si, è decisamente più pulito.

--
Massimiliano Adamo
sunoz 1 Nov 2015 14:15
Max_Adamo <maxadamo@usenet.cnntp.org> wrote:
> ok, mi cospargo il capo di cenere.

Poi il pavimento chi lo pulisce ? :))))
Dai, non ti abbattere....
Ciao. :)


--
Una password si puo' cambiare.
Un dato biometrico e' rubato per sempre!
Medita!

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sul sistema operativo Linux | Tutti i gruppi | it.comp.os.linux.sys | Notizie e discussioni linux | Linux Mobile | Servizio di consultazione news.