[Gfoss] Aprire postgres verso l'esterno con indirizzo IP statico.

Andrea Peri aperi2007 a gmail.com
Ven 14 Maggio 2010 08:30:33 CEST


Mmh.. niente di particolare.

Salvo che forse quello che non si e' percepito nei precedenti messaggi e'
che quando parlo di livello di sicurezza non parlo solo di protezione da
intrusi ma anche sicurezza di ricevere quello che si e' spedito.
Che e' un "pochino" piu' importante :)

Tornando al tuo caso:
te ipotizzi una comunicazione fisica senza uno strato sovrastante.
Ovvero fare viaggiare su internet direttamente il pacchetto destinato al
dbms.

E' come spedire un vaso di vetro per corriere senza imballarlo in una
scatola. Puo' arrivare anche rotto. Questo nessuno te lo garantisce.
Ma se arriva proprio in briciole allora almeno ci si accorge che e' rotto.
pazienza, ma se arriva con qualche piccola "incrinatura" magari te ne
accorgi solo se lo guardi con attenzione.

Se poi la percentuale di vasi rotti e' bassissima, hai risparmiato , se e'
elevata ci rimetti.

Far viaggiare pacchetti su interne te' la medesima cosa.

Infatti far viaggiare su internet pacchetti di dati progettati per viaggiare
su una rete sicura e con dei fail-over bassissimi (una rete interna),
comporta che viaggiano con un supporto di sicurezza ridotto perche' nato per
viaggiare su una rete affidabile (la rete interna).
Volendo scendere ancora di piu' sulla matematica che ci sta' dietro (la
parte che mi piaceva di piu').
I pacchetti che transitano sulle reti (tutte le reti nessuna esclusa) hanno
dei meccanismi di rilevamento errore (crc) che sono capaci di rilevare un
certo numero di bit errati e in tal caso chiedono la ritrasmissione.
Contrariamente a quello che si crede, l'evento "bit errato" avviene in
continuazione anche su una rete interna. La differenza è che su una rete
affidabile avviene di rado (ma avviene) su una rete poco affidabile avviene
con una frequenza molto maggiore.
Questo e'uno dei motivi piu' frequenti di quello che si chiama sovraccarico
della rete (parlo di rete interna).
Ovvero Se per qualche ragione un router o una scheda comincia a funzionare
male, manda a giro dei pacchetti errati, gli altri client chiedono la
ritrasmissione in continuazione ed ecco che la rete si satura con una ondata
di richieste che finiscono per rallentare tutti e riempire completamente la
banda.

Tornando al discorso originale:
Le capacita' di rilevamento degli errori sono commisurate al sistema su cui
opereranno.
Anche perche' per fare il controllo si deve sprecare spazio. Tieni presente
che si parla di pacchettini che hanno dimensioni di 1500 bytes. Fai il conto
di quanti ce ne vogliono per spedire (o anche leggere) 1 Mbytes capisci che
cosa questo comporta su una rete.
Nel momento in cui li fai passare su un sistema a bassa affidabilità senza
aumentarne la capacità di controllo e quindi di rilevazione degli errori, ti
esponi al rischio che chi riceve non si accorga che un pacchetto e' arrivato
errato.

Tutto questo per dire.
Che per far funzionare il sistema di colloquio diretto.
Conviene, se postgres lo consente (ma credo di si') di impostarlo con dei
parametri o scegliere dei protocolli piu' adeguati per il colloquio su
internet.
Cio' comportera' una lentezza maggiore rispetto a quello che potresti avere
se vai con i protocolli per rete interna, ma almeno sei piu' sicuro che i
dati non subiranno errori che poi ti ritrovi sotto forma di dati errati nel
db (se ti va bene) oppure cose incomprensibili per chiunque (molto piu'
probabile).

Poi ci sarebbe il discorso della sicurezza da intrusi, ovvero da
interferenze esterne sul singolo pacchetto che transita su internet, ma
quello e' piu' soggettivo. Voglio dire che il rischio e' ben presente ,
molto piu' elevato di quanto tu passa immaginare, ma se non ti importa
questo lo decidi te.

Tieni comunque presente che e' solo teoria.
Poi serve la pratica.

L'unica strada e' provare. Quantomeno ti levi il dubbio.

Ciao,


Il giorno 13 maggio 2010 14.55, Luca Mandolesi <mandoluca a gmail.com> ha
scritto:

> La cura migliore in questi casi e' batterci la testa direttamente.
>>
>> Concordo pienamente!!!! 8 )
>
> Anche perchè francamente non saprei da dove partire per riscrivere il
> plugin. Suggerimenti?
>
>


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100514/4b12be86/attachment.htm>


Maggiori informazioni sulla lista Gfoss