Discussion:
iptables conntrack_ftp: tlsv1-el titkositott kontroll kapcsolatban PASV parancs atirasa.
Éliás Tamás István
2004-08-08 19:48:05 UTC
Permalink
Sziasztok! Par napja irtam vsftpd-s gondot. Az megoldodott, koszonom. Az
LD_LIBRARY_PATH valamint egy keves forrashaxolas (nem a dummyinc-t kellett
hasznalni hanem az openssl-es includot, meg at kellett irni .h-k eleresi
utjat) megoldotta a dolgot, viszont a kovetkezo problema lepett fel: A
kapcsolatot TLSv1-el titkositom, a server passziv modban dolgozik, viszont
a gep tuzfal mogott van. a tuzfal ipatforditast is csinal. Tehat az ftp
kontrollkapcsolat felepul, es az ftp server kikuldi a PASV
192,168,2,3,211,24 parancsot. Ugye a gep belso ipcime 192.168.2.3. A
tuzfalnak, meghozza az iptables conntrack_ftp moduljanak kene ezt a PASV
parancsot atirnia az o IPcimere, ugyanis jelenlegi formajaban a kliens
oldal a kapott belsohalos ipcimen akarja megnyitni az adatfolyamot az
(211*256)+24=54040es porton. Csomo keresgeles utan rajottem, h ez a
conntrack_ftp ugy mukodik, h a kontrol kapcsolatban csomagjaiban a PASV
(ill PORT aktiv modban) parancsot keresi a tuzfal es ugy modositja. Namost
mivel itt az egesz kontroll es adatkapcsolat is DES-kulccsal van
titkositva, igy nem talalja meg.

Sun Aug 8 19:54:06 2004 [pid 24587] FTP command: Client "ipcim", "AUTH TLS"
Sun Aug 8 19:54:06 2004 [pid 24587] FTP response: Client "ipcim", "234
Proceed with negotiation."

Talalkozott valaki hasonlo problemaval? Meg lehet e ezt oldani valahogy?
(Olyan modul ami (az ismert) certificate alapjan kibontja, modositja, majd
visszakodolja a csomagot?) En jelenleg egyetlen megoldasat latom az
ugynek: Mivel a tuzfal ipje fix, es a belso halos ip is fix, modositom a
vsftpd forrasat, h barmely kiadott PASV parancs helyen ne a local gep
ipje, hanem a tuzfal ismert kulso ipje jelenjen meg. (A servren levo
tuzfallal sajnos nem tudok conntrack-et vegezni, mert ugye nem ott megy a
forgalom elosztasa, igy nem is tudna mire atirni a csomagot...) A tuzfal
meg ugysem foglalkozik a csomagok tartalmaval, leven titkositva vannak...
Nem tudom h ez igy mukodne e, mindenesetre kiprobalom, ha nem jon jobb
otlet...
Ha valakinek van otlete erre, kerem jelezze. Hajlamos vagyok
tulbonyolitani a dolgokat, lehet h most is ez tortent... :( Bocs a hosszu
levelert...
Elore is koszi a segitseget.
Sickboy
2004-08-08 20:55:53 UTC
Permalink
Post by Éliás Tamás István
(Olyan modul ami (az ismert) certificate alapjan kibontja, modositja, majd
visszakodolja a csomagot?)
Zorp tud ilyet http-n, biztos ftp-n is.


.SiCk of IT.
Éliás Tamás István
2004-08-10 15:20:07 UTC
Permalink
Udv!
Post by Sickboy
Zorp tud ilyet http-n, biztos ftp-n is.
Koszi a tippet, elkepzelheto h alkalmazni is fogom, de egyenlore egy apro
haxolassal sikerult a conntrack problemat megoldanom. Emlitettem, h
modositanam a vsftpd-t, hogy a PASV parancs utan ne a gep belso ipcimet,
hanem az (altalam ismert) kulso ipcimet kuldje el, onnantol kezdve a
kliens a kulso ipcimen akar majd csatlakozni (ami termeszetesen azutan
atirodik a tuzfalon). Ha esetleg valaki nem akar szorakozni zorp-al, es
hasonlo problemaja van (a belso ipcimu ftp server tuzfalon megy ki (pl DMZ
halozaton van) es a tuzfal rendeli hozza a belso cimekhez a publikus
cimeket, es kenytelen ssl-el titkositott adatforgalmat bonyolitani) akkor
a vsftpd tokeletes valasztas.

A postlogin.c

handle_pasv(struct vsf_session* p_sess, int is_epsv)

funkciojat kell modositani, ahol is a

str_alloc_text(&s_pasv_res_str, "Entering Passive Mode (");
if (!is_ipv6)
{
str_append_text(&s_pasv_res_str, vsf_sysutil_inet_ntop(s_p_sockaddr));
}

sorokat kell modositani a kovetkezo keppen:
str_alloc_text(&s_pasv_res_str, "Entering Passive Mode (");
if (!is_ipv6)
{
str_append_text(&s_pasv_res_str, "xxx.xxx.xxx.xxx");
}

Ahol xxx.xxx.xxx.xxx az ipcim. Ennek hatasara a tuzfalon nem kell
kibontogatni a csomagot, es nem kell conntrack_ftp sem.
Balazs Scheidler
2004-08-15 14:40:42 UTC
Permalink
Post by Sickboy
Post by Éliás Tamás István
(Olyan modul ami (az ismert) certificate alapjan kibontja, modositja, majd
visszakodolja a csomagot?)
Zorp tud ilyet http-n, biztos ftp-n is.
egyenlore a starttls jellegu TLS/SSL tamogatast nem tudja a Zorp.
Szerintem ftps helyett hasznalj SSH fele sftp-t, mar ha a klienst is
tudod befolyasolni (bar szerintem tobb sftp kliens van, mint ftps-t tudo
ftp kliens)
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
KORN Andras
2004-08-08 21:32:24 UTC
Permalink
Post by Éliás Tamás István
tuzfalnak, meghozza az iptables conntrack_ftp moduljanak kene ezt a PASV
parancsot atirnia az o IPcimere, ugyanis jelenlegi formajaban a kliens
oldal a kapott belsohalos ipcimen akarja megnyitni az adatfolyamot az
(211*256)+24=54040es porton. Csomo keresgeles utan rajottem, h ez a
conntrack_ftp ugy mukodik, h a kontrol kapcsolatban csomagjaiban a PASV
(ill PORT aktiv modban) parancsot keresi a tuzfal es ugy modositja. Namost
mivel itt az egesz kontroll es adatkapcsolat is DES-kulccsal van
titkositva, igy nem talalja meg.
Sun Aug 8 19:54:06 2004 [pid 24587] FTP command: Client "ipcim", "AUTH TLS"
Sun Aug 8 19:54:06 2004 [pid 24587] FTP response: Client "ipcim", "234
Proceed with negotiation."
Talalkozott valaki hasonlo problemaval? Meg lehet e ezt oldani valahogy?
Elmeletileg igen, gyakorlatilag nem tudok letezo implementaciorol.

Mi a feladat, amit meg akarsz oldani? (Az ftp nem a feladat, hanem mar az
altalad kitalalt megoldas resze.)

Guy
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
I'm not bald - I just have a rather wide parting.
Loading...