Newsgroup: it.comp.os.linux.sys
Titolo: Accedere a differenti server ftp in DMZ

Buongiorno a tutti, nell'azienda in cui lavoro ho la necessità di accedere dall'esterno via FTP a tre diversi server posti in DMZ. Due server sono con OS Windows 2008 R2 mentre uno è con Debian. Per ora avevo la necessità di accedere solo al Debian e con due regole nel firewall avevo sistemato la cosa, ora però non riesco a trovare un modo per accedere anche agli altri due.
 
Io accedo i vari server "web" con lighttp come proxy utilizzando i nomi di dominio come filtri, ma per l'FTP non so come fare.
 
C'è una soluzione?
Grazie

 Grazie
Usando un proxy ftp cosi come fai con il web ?
 
Ciaps.


Io non ho capito bene cosa vuoi fare. Qual'è il problema ad accedere via ftp 
a dei server in dmz? Il problema forse e dentro la tua rete, ovvero sei tu 
che non esci dalla tua rete in ftp oppure è il server remoto che non ti 
lascia entrare?
 
Nicola.
 
-- 
chi va pian va san e va lontan

 Io non ho capito bene cosa vuoi fare. Qual'è il problema ad accedere via ftp 
 
La butto lì: carenza di IP esposti?
Ha un solo IP pubblico e non sa come smistare l'accesso?
Quella frase: "utilizzando i nomi di dominio come filtro" me lo fa
pensare sempre più.
Aspettiamo chiarimenti.
 
-- 
    Ciao   |Save our planet!             Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@bofhland.org
 

 pensare sempre più.
 
Ci metto il mio +1, vuole fare demuxing.


wrote:

Mi par di capire che tu abbia un IP disponibile, a cui e' collegata la
macchina Debian e dove gira lighttpd.
 
Allora, soluzioni ce n'ho di divelse qualita'.
 
1) Reverse Proxy FTP (
http://www.ftpproxy.org
)
 
Dopodiche' ti logghi su 
ftp://ip.macchina.debian
 e usi come utente:
 
	- utente1@debian, password aaa, per collegarti al primo FTP
	  come utente1 con password aaa
	- utente2@win2000, password bbb, per etc. etc.
 
2) Port knocking
 
Sistema brutalissimo: se fai telnet sulla porta 20120,20130 e 20140
in sequenza, ftp ip.macchina.debian ti porta sulla Debian. Se pero'
usi 20141 invece di 20140, finisci su Windows 2000. Eccetera. Ha il
grosso svantaggio che siccome lo switch lo fa via FW, se qualcuno -
per disgrazia - e' attaccato a una macchina diversa, lo tronchi.
 
3) Mounting via SMB
 
Esporti FTPDIRECTORY1 di Windows2000 su debian:/media/win2000, come
share Samba. Poi crei l'utente user2000 su debian e lo chrooti come
FTP nella share /media/win2000. Cosi' non ti serve neanche di avere
il server FTP su Windows 2000.
 
4) Porte diverse
 
Configuri il fw di debian per ridirigere la porta 10021 sulla porta
21 del W2000, la porta 20021 sulla porta 21 del W2008, e dopodiche'
da fuori ti colleghi a 
ftp://ip.debian:10021
 e sei lesto.
 
Ricordati che in tutti i casi tranne il (3) (e forse il (2)) potrai
usare solo FTP in modalita' passiva (PASV) perche' deve passare dal
canale ridiretto ogni cosa, o si perde per strada.
 
Io comincerei col sistema (1) che e' abbastanza pulito, se no (3) e
se no (4), che non funziona con tutti i provider. Il (2) e' se vuoi
farti del male fisico veramente :-)
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 1) Reverse Proxy FTP (
http://www.ftpproxy.org
)
 
Mi sembra la più pulita, le altre vanno bene per casa


Concordo, anche se ti potrei nominare [1] $BIGFIRM che usa il metodo (3).
 
(rectius: che HA USATO il metodo (3) per sei mesi intanto che veniva fatta
la migrazione da un contratto mal consigliato a uno con piu' IP).
 
Lato client, la differenza e' inavvertibile; potrebbero succedere cose non
belle se un server secondario non va su in riavvio (e.g. blackout e guasto
all'UPS di primo intervento), il server primario non monta la share, e uno
si trova ad accedere al mount point nudo e vuoto. Ma bisogna avere sfiga.
 
Leonardo
 
[1] beh, no, in realta' no


 Lato client, la differenza e' inavvertibile;
 
Penso anche all'aspetto sicurezza: per esportare una share SMB devi aprire in DMZ diverse porte dei servizi M$; se ti bucano il server FTP possono fare dei giochini non molto carini verso i server Windows.

Penso anche all'aspetto sicurezza: per esportare una share SMB devi aprire in DMZ diverse porte dei servizi M$; se ti bucano il server FTP possono fare dei giochini non molto carini verso i server Windows.
 
Be' - se le macchine sono installate come si deve, riescono ad autenticarsi
da remoto sul solo file sharing, solo come utente ftpuser, e solo su quelle
share; su macchine comunque in DMZ.
 
Tieni conto che mentre in modalita' "FTP+share" potresti entrare su un solo
vsftpd di una macchina debian, in modalita' "ftp proxy" entri sul ftp della
macchina debian "e" su due FTP di macchine Windows, attraverso un programma
che, senza offesa per nessuno, ma oggettivamente non e' stato testato tanto
quanto un vsftpd (ftpproxy: ultima stabile 1.2.3, 2004).
 
A proposito, non avevo citato un'altra possibilita' tipo ftpproxy, ossia il
leggermente piu' recente (almeno in stable) frox.
 
 
http://frox.sourceforge.net/
 
 
Leonardo


Il 24/10/12 08.05, Mauro D. ha scritto:

Soluzioni ce ne sono un infinità si tratta di capire quale sia la
migliore in base alle proprie esigenze, si va dalla più semplice come
mettere in listen i server ftp su altre porte e nattarle dal router
principale a trasferire il tutto su AWS S3.
 
Ma per capire quale sia la migliore soluzione bisogna avere qualche info
in +, per esempio se si tratta di un applicazione o di una persona
fisica che deve accedere ai dati, nel primo caso se l'app supporta
esclusivamente l'ftp o anche altro, la tipologia di dato in questione
file piccoli o grandi, la frequenza di accesso e la banda in upload
dell'azienda e se i dati debbano essere in sola lettura o anche in
scrittura.