sziasztok! Elegge benazos vagyok, foleg igy az elejen. Szoval, kellene nekem egy mukodo konfig https proxyzasara (belso, privat intranetes szerver elerese kivulrol), ill. ssh proxyzasara (hasonlo, csak itt az fw-t, es a belso szervert is el kene erni a 22-es porton). Meg lehet ezeket csinalni? Nekem egy kicsit bonyolult utana gondolnom, es tartok tole, hogy nem;) 10x tompos
hello,
Elegge benazos vagyok, foleg igy az elejen. sokan vagyunk igy... :)
Szoval, kellene nekem egy mukodo konfig https proxyzasara (belso, privat intranetes szerver elerese kivulrol), ill. ssh proxyzasara (hasonlo, csak itt az fw-t, es a belso szervert is el kene erni a 22-es porton). pontosabban mit szeretnel? pl: a kliens-Zorp https, de utana a Zorp-webszerver ismet https, vagy nativ http?
milyen verzioval probalod? transzparens modban, v annelkul? Mas konfig mar mukodik, vagy egybol ennek ugrottal neki?
Meg lehet ezeket csinalni? Nekem egy kicsit bonyolult utana gondolnom, es tartok tole, hogy nem;) paran mar megcsinaltuk :)
elso korben: https://lists.balabit.hu/pipermail/zorp/2004-January/000186.html http://groups.google.co.hu/group/hun.lists.mlf.linux/browse_frm/thread/1a8b5... a. -- Minden baj forrása az 1/x függvény.
On Tue, Aug 09, 2005 at 09:12:18PM +0200, Hegedüs Ervin wrote:
Szoval, kellene nekem egy mukodo konfig https proxyzasara (belso, privat intranetes szerver elerese kivulrol), ill. ssh proxyzasara (hasonlo, csak itt az fw-t, es a belso szervert is el kene erni a 22-es porton). pontosabban mit szeretnel? pl: a kliens-Zorp https, de utana a Zorp-webszerver ismet https, vagy nativ http?
Akar mehet az utobbi, persze az elobbi lenne a szep.
milyen verzioval probalod?
3.x, bocs, nehany informaciot biza kihagytam.
transzparens modban, v annelkul?
A transzparens mod az, amikor szerver latja a klienst ugyanugy, mintha kozvetlenul beszelgetnenek? Akkor azt. Bocs, volt egy kis nyariszunet, az azota sokminden jobban kavarok, amit azelott is egy kicsit;)
Mas konfig mar mukodik, vagy egybol ennek ugrottal neki?
Egy sima http proxy mukodik.
Meg lehet ezeket csinalni? Nekem egy kicsit bonyolult utana gondolnom, es tartok tole, hogy nem;) paran mar megcsinaltuk :)
Itt azt ertettem, hogy ssh-n pl. az fqdn(?) megszolitasa alapjan el tudja vhogy donteni a proxy, hogy melyik hostra kapcsolodjon tovabb? A https eseten meg el is tudnam kepzelni, vegulis ott benne van a http headerben, de az ssh-t abszolut nem ismerem.
elso korben: https://lists.balabit.hu/pipermail/zorp/2004-January/000186.html
Na, ennel pl. nem ertem, melyik bejegyzes pontosan mit is jelent. Amugy ugyanazokat a certeket kell beadni neki, mint a webszervernek, amit beadtam? De ha tobb ssl-es szerver is van mogotte ertelem szeruen tobb certtel, akkor azt hogyan kell?
http://groups.google.co.hu/group/hun.lists.mlf.linux/browse_frm/thread/1a8b5...
Ja, igen, az egyik helyen (most konkretan 2 kulonbozo helyrol van szo) a webszerverek publikus ip cimen figyelnek. Remelem, ertheto. 10x tompos
hello,
transzparens modban, v annelkul?
A transzparens mod az, amikor szerver latja a klienst ugyanugy, mintha kozvetlenul beszelgetnenek? Akkor azt. en bocs, rosszul tettem fel a kerdest.
term. a transzparens mod ezt jelenti, es ebbol ertelemszeruen kovetkezik, hogy transzparens modban _kell_ mukodnie. (csak megjegyzem, h forditva is ugyanugy mukodik a dolog: tehat a kliens ugyanugy latja a szervert, mintha nem lenne ott a tuzfal, tehat nincs explicit proxy beallitas) tehat a kerdes megegyszer :) tprox-val akarod, v http-fejlec segitsegevel? a tproxy-hoz kell kernelt patchelni, szigoruan modulba a tproxy-t, majd a zorp-nak megmondani ezeket az infokat. http-fejlec alapu host-valogatasnal nem kell semmi hack, a konfigban egyszeruen a 'Host' http header alapjan beallitod a cel-cimet.
Itt azt ertettem, hogy ssh-n pl. az fqdn(?) megszolitasa alapjan el tudja vhogy donteni a proxy, hogy melyik hostra kapcsolodjon tovabb? A https eseten meg el is tudnam kepzelni, vegulis ott benne van a http headerben, de az ssh-t abszolut nem ismerem. az ssh-t en sem tudom, de https-nel egyertelmuen _nem_.
ergo amit az elobb leirtam, csak http-re vonatkozik.
Na, ennel pl. nem ertem, melyik bejegyzes pontosan mit is jelent. igen, a dokumentacio nem az erossege a Zorp-nak... :)
nezd meg a modulokat, abban van nemi komment, pl: /usr/local/share/zorp/pylib/Zorp/Http.py ... ill. a forras egyertelmu (vagy elobb utobb az lesz :))
Amugy ugyanazokat a certeket kell beadni neki, mint a webszervernek, amit beadtam? De ha tobb ssl-es szerver is van mogotte ertelem szeruen tobb certtel, akkor azt hogyan kell?
nem tudsz https-el virtual-hostokat megvalositani (egy IP-n, egy adott porton) http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2
Ja, igen, az egyik helyen (most konkretan 2 kulonbozo helyrol van szo) a webszerverek publikus ip cimen figyelnek. imho ez mindegy.
a. -- Minden baj forrása az 1/x függvény.
On Tue, Aug 09, 2005 at 10:09:14PM +0200, Hegedüs Ervin wrote:
a tproxy-hoz kell kernelt patchelni, szigoruan modulba a tproxy-t, majd a zorp-nak megmondani ezeket az infokat.
Ezt vagom. Miert szukseges, hogy modulban legyen?
az ssh-t en sem tudom, de https-nel egyertelmuen _nem_.
ergo amit az elobb leirtam, csak http-re vonatkozik.
Na, ennel pl. nem ertem, melyik bejegyzes pontosan mit is jelent. igen, a dokumentacio nem az erossege a Zorp-nak... :)
nezd meg a modulokat, abban van nemi komment, pl: /usr/local/share/zorp/pylib/Zorp/Http.py ...
ill. a forras egyertelmu (vagy elobb utobb az lesz :))
Amugy ugyanazokat a certeket kell beadni neki, mint a webszervernek, amit beadtam? De ha tobb ssl-es szerver is van mogotte ertelem szeruen tobb certtel, akkor azt hogyan kell?
nem tudsz https-el virtual-hostokat megvalositani (egy IP-n, egy adott porton) http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2
Felreertesz. Nem a webszerver hostjan akarom megoldani. Ezt vagom. De az miert nem mukodik, hogy a proxy megkapja a kerest, kicsomagolja, az ssl-bol, megvizsgalja az egeszet, aztan az alapjan kapcsolodik a megfelelo szerverhez? Vagy ez ugyanaz a problema? tompos
On Tue, Aug 09, 2005 at 10:19:23PM +0200, Papp Tamas wrote:
Felreertesz. Nem a webszerver hostjan akarom megoldani. Ezt vagom.
De az miert nem mukodik, hogy a proxy megkapja a kerest, kicsomagolja, az ssl-bol, megvizsgalja az egeszet, aztan az alapjan kapcsolodik a megfelelo szerverhez? Vagy ez ugyanaz a problema?
Ja, ez tobbek kozott azert is volt lenyeges, merthogy ahol publikus ip-n vannak a https szerverek, hogy termeszetesen kulonbozo publikus ip-n is.. tompos
On Tue, Aug 09, 2005 at 10:20:55PM +0200, Papp Tamas wrote:
Ja, ez tobbek kozott azert is volt lenyeges, merthogy ahol publikus ip-n vannak a https szerverek, hogy termeszetesen kulonbozo publikus ip-n is..
Ja, vagom, ez tproxyval siman megoldhato. Szoval akkor a masik eset, hogy kulonbozo https keresek proxyval sem oldhatok meg ugyanugy? tompos
On Tue, 2005-08-09 at 22:19 +0200, Papp Tamas wrote:
De az miert nem mukodik, hogy a proxy megkapja a kerest, kicsomagolja, az ssl-bol, megvizsgalja az egeszet, aztan az alapjan kapcsolodik a megfelelo szerverhez? Vagy ez ugyanaz a problema?
Mert mire a zorp kicsomagolja az SSL-t addigra a handshake-et is meg kell ejtenie. Innetol pedig visszavezettuk a szerver problemajara. -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, Aug 09, 2005 at 10:25:40PM +0200, Szalay Attila wrote:
Mert mire a zorp kicsomagolja az SSL-t addigra a handshake-et is meg kell ejtenie. Innetol pedig visszavezettuk a szerver problemajara.
Ja igen, ugyanaz;) Azert koszi, tompos
hello,
a tproxy-hoz kell kernelt patchelni, szigoruan modulba a tproxy-t, majd a zorp-nak megmondani ezeket az infokat.
Ezt vagom. Miert szukseges, hogy modulban legyen? a modul alapjan detektalja annak (a funkcionak) megletet, de majd biztos szol valaki jobban hozzaerto is.
Felreertesz. Nem a webszerver hostjan akarom megoldani. Ezt vagom.
De az miert nem mukodik, hogy a proxy megkapja a kerest, kicsomagolja, az ssl-bol, megvizsgalja az egeszet, aztan az alapjan kapcsolodik a megfelelo szerverhez? Vagy ez ugyanaz a problema? igy valszeg' meg lehet oldani, de az egy kicsit bonyolult konfig lesz.
valami kezd derengeni, h egyszer akartam en is vmi ilyesmit - Bazsi irt nemi tampontot: https://lists.balabit.hu/pipermail/zorp-hu/2004-May/001397.html ez talan segit, a. -- Minden baj forrása az 1/x függvény.
On Tue, Aug 09, 2005 at 10:30:41PM +0200, Hegedüs Ervin wrote:
hello,
a tproxy-hoz kell kernelt patchelni, szigoruan modulba a tproxy-t, majd a zorp-nak megmondani ezeket az infokat.
Ezt vagom. Miert szukseges, hogy modulban legyen? a modul alapjan detektalja annak (a funkcionak) megletet, de majd biztos szol valaki jobban hozzaerto is.
Jo, akkor a https-t kibeszeltuk. Es az ssh-hoz tudna vki nyujtani ne'mi segitseget, peldakonfigot?:) tompos
On Tue, Aug 09, 2005 at 10:30:47PM +0200, Papp Tamas wrote:
Jo, akkor a https-t kibeszeltuk. Es az ssh-hoz tudna vki nyujtani
Kibeszeltetek, csak szerintem nincs igazatok :)
ne'mi segitseget, peldakonfigot?:)
InetZone("akarmi", ["192.168.123.2"], inbound_services=["ip_ssh"], outbound_services=[]) InetZone("internet", "0.0.0.0/0", inbound_services=[], outbound_services=["ip_ssh"]) class IPSsh(PlugpProxy): pass Service("ip_ssh", IPSsh, DirectedRouter(SockAddrInet("192.168.123.2", 22)), snat=ForgeClientSourceNAT()) Listener(SockAddrInet("kulso.ip", 60022), "ip_ssh") -- Udvozlettel Zsiga
On Tue, Aug 09, 2005 at 10:41:48PM +0200, Kosa Attila wrote:
Kibeszeltetek, csak szerintem nincs igazatok :)
Miert?
InetZone("akarmi", ["192.168.123.2"], inbound_services=["ip_ssh"], outbound_services=[])
InetZone("internet", "0.0.0.0/0", inbound_services=[], outbound_services=["ip_ssh"])
class IPSsh(PlugpProxy): pass
Service("ip_ssh", IPSsh, DirectedRouter(SockAddrInet("192.168.123.2", 22)), snat=ForgeClientSourceNAT())
Listener(SockAddrInet("kulso.ip", 60022), "ip_ssh")
10x tompos
On Tue, Aug 09, 2005 at 10:48:03PM +0200, Papp Tamas wrote:
On Tue, Aug 09, 2005 at 10:41:48PM +0200, Kosa Attila wrote:
Kibeszeltetek, csak szerintem nincs igazatok :)
Miert?
Mert meg lehet oldani azt, hogy ha www.ceg.hu-t irsz, akkor az egyik szerverre dobjon tovabb, ha mail.ceg.hu-t irsz, akkor pedig egy masikra. Mindezt https-sel. -- Udvozlettel Zsiga
On Tue, 2005-08-09 at 22:59 +0200, Kosa Attila wrote:
Mert meg lehet oldani azt, hogy ha www.ceg.hu-t irsz, akkor az egyik szerverre dobjon tovabb, ha mail.ceg.hu-t irsz, akkor pedig egy masikra. Mindezt https-sel.
Csak kozben, ha nem jo cert-et valasztassz (vagy nem jo klienst :)), akkor sir, hogy a certificate nem ahhoz a gephez van kiallitva. (Ugyanis letezik olyan cert, ami wildcard-os, azaz pl. *.ceg.hu-s, de azt nem minden kliens szereti tudtommal. Bar lehet, hogy azok a kliensek mar kihaltak. :) -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, Aug 09, 2005 at 11:03:53PM +0200, Szalay Attila wrote:
Csak kozben, ha nem jo cert-et valasztassz (vagy nem jo klienst :)), akkor sir, hogy a certificate nem ahhoz a gephez van kiallitva.
(Ugyanis letezik olyan cert, ami wildcard-os, azaz pl. *.ceg.hu-s, de azt nem minden kliens szereti tudtommal. Bar lehet, hogy azok a kliensek mar kihaltak. :)
Kell ahhoz vmi kulonleges, hogy olyat csinaljak? Persze self-signed. tompos
On Tue, 2005-08-09 at 23:12 +0200, Papp Tamas wrote:
Kell ahhoz vmi kulonleges, hogy olyat csinaljak? Persze self-signed.
Tudtommal nem, de a cerificate/ek ezen oldalaval kapcsolatban nincs tul nagy tudasom. De most gyorsan ragoogle-ztam es ugy tunik, hogy nem kell semmi kulonleges. Csak a hostnev-nek *.domain.tld-t kell megadni. -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, Aug 09, 2005 at 11:03:53PM +0200, Szalay Attila wrote:
On Tue, 2005-08-09 at 22:59 +0200, Kosa Attila wrote:
Mert meg lehet oldani azt, hogy ha www.ceg.hu-t irsz, akkor az egyik szerverre dobjon tovabb, ha mail.ceg.hu-t irsz, akkor pedig egy masikra. Mindezt https-sel.
Csak kozben, ha nem jo cert-et valasztassz (vagy nem jo klienst :)), akkor sir, hogy a certificate nem ahhoz a gephez van kiallitva.
Ez igaz, de ettol a kapcsolat meg titkositott lesz.
(Ugyanis letezik olyan cert, ami wildcard-os, azaz pl. *.ceg.hu-s, de azt nem minden kliens szereti tudtommal. Bar lehet, hogy azok a kliensek mar kihaltak. :)
Meg nem lattam olyan klienst, amely szerette volna :) -- Udvozlettel Zsiga
On Tue, 2005-08-09 at 23:21 +0200, Kosa Attila wrote:
Ez igaz, de ettol a kapcsolat meg titkositott lesz.
Az lehet, hogy titkositott, de hogy nem biztonsagos, az is. Ugyanis raszoktatod a user-eket, hogy a kapcsolodashoz kell egy OK-ot nyomni, a kedves user meg nem fogja ezutan elolvasni, hogy mit is mond neki a bongeszoje (hibas nev vagy nem jo CA), ezaltal a fake-elt certet is ugyanugy el fogja fogadni. -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, Aug 09, 2005 at 11:27:27PM +0200, Szalay Attila wrote:
On Tue, 2005-08-09 at 23:21 +0200, Kosa Attila wrote:
Ez igaz, de ettol a kapcsolat meg titkositott lesz.
Az lehet, hogy titkositott, de hogy nem biztonsagos, az is. Ugyanis raszoktatod a user-eket, hogy a kapcsolodashoz kell egy OK-ot nyomni, a kedves user meg nem fogja ezutan elolvasni, hogy mit is mond neki a bongeszoje (hibas nev vagy nem jo CA), ezaltal a fake-elt certet is ugyanugy el fogja fogadni.
Ha zorp mogott ul, akkor ilyenre nem sok eselye van :) -- Udvozlettel Zsiga
On Tue, 2005-08-09 at 22:30 +0200, Papp Tamas wrote:
Jo, akkor a https-t kibeszeltuk. Es az ssh-hoz tudna vki nyujtani ne'mi segitseget, peldakonfigot?:)
Ha jol sejtem, akkor ssh-val azt kellene megoldani, hogy ugyanazon az IP cimen akar a tuzfal-ra, akar egy mogotte levo gepre lehessen ssh-zni attol fuggoen, hogy az ssh moge tuzfal.ceg.hu-t, vagy www.ceg.hu-t irtam be. Jol ertettem? Ha igen, akkor sajnos el kell, hogy keseritselek, az ssh-ban nem megy at a klienstol a szerver fele, hogy o igazabol hova akart csatlakozni. :( (Legalabbis tudtommal, de max Bazsi kijavit :) Igy erre nem latok tul nagy eselyt. :( (Az ssh proxy forrasanak atturasa utan sem, bar ez sokat nem jelent, mert most latom elosszor :) Persze, ha kulon IP cimre, vagy portra lehet rakni, akkor rendben. -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, 2005-08-09 at 22:55 +0200, Szalay Attila wrote:
On Tue, 2005-08-09 at 22:30 +0200, Papp Tamas wrote:
Jo, akkor a https-t kibeszeltuk. Es az ssh-hoz tudna vki nyujtani ne'mi segitseget, peldakonfigot?:)
Ha jol sejtem, akkor ssh-val azt kellene megoldani, hogy ugyanazon az IP cimen akar a tuzfal-ra, akar egy mogotte levo gepre lehessen ssh-zni attol fuggoen, hogy az ssh moge tuzfal.ceg.hu-t, vagy www.ceg.hu-t irtam be. Jol ertettem?
Ha igen, akkor sajnos el kell, hogy keseritselek, az ssh-ban nem megy at a klienstol a szerver fele, hogy o igazabol hova akart csatlakozni. :( (Legalabbis tudtommal, de max Bazsi kijavit :)
valoban nem megy at, ugyhogy arra vagy kulon portot vagy kulon IP-t kell foglalnod. -- Bazsi
On Tue, Aug 09, 2005 at 10:09:14PM +0200, Hegedüs Ervin wrote:
Itt azt ertettem, hogy ssh-n pl. az fqdn(?) megszolitasa alapjan el tudja vhogy donteni a proxy, hogy melyik hostra kapcsolodjon tovabb? A https eseten meg el is tudnam kepzelni, vegulis ott benne van a http headerben, de az ssh-t abszolut nem ismerem. az ssh-t en sem tudom, de https-nel egyertelmuen _nem_.
Https-nel meg lehet oldani. Ssh-nal nem, mert az ssh-t nem "fejti vissza" a zorp ropteben, csak sima plug-gal lehet atvinni. -- Udvozlettel Zsiga
Hello,
Https-nel meg lehet oldani. Ooooo... most akkor igen vagy nem? Sasa azt irta, h nem.
Vagy igy lehet: kliens -->HTTPS--> Zorp -->HTTP--> szerver igy pedig nem? kliens -->HTTPS--> Zorp -->HTTPS--> szerver ??
Ssh-nal nem, mert az ssh-t nem "fejti vissza" a zorp ropteben, csak sima plug-gal lehet atvinni. csak informativ kerdeskent: csak a GPL-esben van ez igy, vagy amugy letezik nativ SSH proxy?
a. -- Minden baj forrása az 1/x függvény.
On Tue, Aug 09, 2005 at 10:48:34PM +0200, Hegedüs Ervin wrote:
Https-nel meg lehet oldani. Ooooo... most akkor igen vagy nem? Sasa azt irta, h nem.
Vagy igy lehet:
kliens -->HTTPS--> Zorp -->HTTP--> szerver
igy pedig nem?
kliens -->HTTPS--> Zorp -->HTTPS--> szerver
??
Nem ugyanarra reagalt Sasa, mint amire en :) Sasa azt mondta, hogy nem tud kulonbozo kulcsokat adni (ugyanazon a porton erkezo keresek eseten) a Zorp (mikent a webszerver sem). En pedig arrol irtam, hogy a keresben szereplo webszerver cime alapjan el tudja donteni a zorp, hogy melyik webszerverre kell tovabbitania a kerest.
Ssh-nal nem, mert az ssh-t nem "fejti vissza" a zorp ropteben, csak sima plug-gal lehet atvinni. csak informativ kerdeskent: csak a GPL-esben van ez igy, vagy amugy letezik nativ SSH proxy?
Tudtommal nem letezik. -- Udvozlettel Zsiga
On Tue, 2005-08-09 at 22:33 +0200, Kosa Attila wrote:
Https-nel meg lehet oldani. Ssh-nal nem, mert az ssh-t nem "fejti vissza" a zorp ropteben, csak sima plug-gal lehet atvinni.
En inkabb azt mondanam, hogy az a gond, hogy az ssh-ban nem _megy_ _at_ ez az informacio, mig https-ben atmegy, megha kodolva is. Tehat a Zorp hiaba is fejti vissza, nem tud vele mit kezdeni. :( (Persze ez ugy ertendo, hogy tudtommal, de nem talaltam a forrasban erre utalo jeleket, raadasul most azonnal kapcsolodik a szerverhez, mielott a klienstol barmit beolvasna.) -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, Aug 09, 2005 at 10:59:40PM +0200, Szalay Attila wrote:
On Tue, 2005-08-09 at 22:33 +0200, Kosa Attila wrote:
Https-nel meg lehet oldani. Ssh-nal nem, mert az ssh-t nem "fejti vissza" a zorp ropteben, csak sima plug-gal lehet atvinni.
hiaba is fejti vissza, nem tud vele mit kezdeni. :( (Persze ez ugy ertendo, hogy tudtommal, de nem talaltam a forrasban erre utalo jeleket, raadasul most azonnal kapcsolodik a szerverhez, mielott a klienstol barmit beolvasna.)
Jol ertem, hogy letezik ssh proxy? A gpl-es verzioban is, vagy csak a fizetosben? A "tudasarol" lehetne bovebbet hallani? -- Udvozlettel Zsiga
On Tue, 2005-08-09 at 23:04 +0200, Kosa Attila wrote:
Jol ertem, hogy letezik ssh proxy? A gpl-es verzioban is, vagy csak a fizetosben? A "tudasarol" lehetne bovebbet hallani?
Jol erted. (Egyenlore) csak a fizetosben es nem hiszem, hogy a kozeljovoben kikerulne a gpl-be is. A tudasarol szerintem majd nyilatkozik mas illetekesebb, en kb. annyit tudok (merek :) mondani, hogy ugyanugy mint az ssl-nel az ssh proxy is terminalja a protokollt, ezaltal belelat a benne levo adatba. Ez magaba foglalja a kulcscseret, a csatornakat, az azonositast, stb. -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
On Tue, Aug 09, 2005 at 11:17:51PM +0200, Szalay Attila wrote:
On Tue, 2005-08-09 at 23:04 +0200, Kosa Attila wrote:
Jol ertem, hogy letezik ssh proxy? A gpl-es verzioban is, vagy csak a fizetosben? A "tudasarol" lehetne bovebbet hallani?
Jol erted. (Egyenlore) csak a fizetosben es nem hiszem, hogy a kozeljovoben kikerulne a gpl-be is.
Melyik verziotol van benne?
A tudasarol szerintem majd nyilatkozik mas illetekesebb, en kb. annyit tudok (merek :) mondani, hogy ugyanugy mint az ssl-nel az ssh proxy is terminalja a protokollt, ezaltal belelat a benne levo adatba. Ez magaba foglalja a kulcscseret, a csatornakat, az azonositast, stb.
Mennyire eroforras-igenyes a dolog? -- Udvozlettel Zsiga
On Tue, 2005-08-09 at 23:24 +0200, Kosa Attila wrote:
On Tue, Aug 09, 2005 at 11:17:51PM +0200, Szalay Attila wrote:
On Tue, 2005-08-09 at 23:04 +0200, Kosa Attila wrote:
Jol ertem, hogy letezik ssh proxy? A gpl-es verzioban is, vagy csak a fizetosben? A "tudasarol" lehetne bovebbet hallani?
Jol erted. (Egyenlore) csak a fizetosben es nem hiszem, hogy a kozeljovoben kikerulne a gpl-be is.
Melyik verziotol van benne?
3.1-es verziotol lesz benne.
A tudasarol szerintem majd nyilatkozik mas illetekesebb, en kb. annyit tudok (merek :) mondani, hogy ugyanugy mint az ssl-nel az ssh proxy is terminalja a protokollt, ezaltal belelat a benne levo adatba. Ez magaba foglalja a kulcscseret, a csatornakat, az azonositast, stb.
nagyjabol a teljes SSH protokoll stacket ismeri, egy-ket korlat mellett: - binaris authentikaciok, amik tartalmazzak a session_id-t, ilyen peldaul a publickey es a gssapi autentikacio (mar van egy elgondolasunk, ami alapjan bizonyos esetekben mukodni fog ez is) - az SSH csatornakra meg nem lehet stackelni - a kereseket jelenleg nem lehet modositani, egyszeru engedem/nem engedem dontest lehet hozni. (pl. engedem-e az LD_LIBRARY_PATH kornyezeti valtozo beallitasat, vagy nem) Mar most is kepes egy olyan SSH csatorna kialakitasara, amiben csak terminalkapcsolat lehetseges, port, X, agent forwarding illetve parancsfuttatas nem.
Mennyire eroforras-igenyes a dolog?
kb. mint amennyire az SSL proxy, OpenSSL gyorsitokartyak alkalmazasaval ez is gyorsithato. -- Bazsi
On Wed, Aug 10, 2005 at 10:35:42AM +0200, Balazs Scheidler wrote:
nagyjabol a teljes SSH protokoll stacket ismeri, egy-ket korlat mellett:
- binaris authentikaciok, amik tartalmazzak a session_id-t, ilyen peldaul a publickey es a gssapi autentikacio (mar van egy elgondolasunk, ami alapjan bizonyos esetekben mukodni fog ez is)
Jol ertem, hogy kulcsos authentikaciot nem tud atvinni csak jelszavasat? -- Udvozlettel Zsiga
On Wed, 2005-08-10 at 10:57 +0200, Kosa Attila wrote:
On Wed, Aug 10, 2005 at 10:35:42AM +0200, Balazs Scheidler wrote:
nagyjabol a teljes SSH protokoll stacket ismeri, egy-ket korlat mellett:
- binaris authentikaciok, amik tartalmazzak a session_id-t, ilyen peldaul a publickey es a gssapi autentikacio (mar van egy elgondolasunk, ami alapjan bizonyos esetekben mukodni fog ez is)
Jol ertem, hogy kulcsos authentikaciot nem tud atvinni csak jelszavasat?
ha elolvasom a fenti mondatot, akkor en ezt ertem alatta. -- Bazsi
Balazs Scheidler wrote:
kb. mint amennyire az SSL proxy, OpenSSL gyorsitokartyak alkalmazasaval ez is gyorsithato. Van arról valami publikus információ, hogy ezen SSL gyorsítók alkalmazása mennyire "kifizetődő" a mai processzorteljesítmények mellett? (mondjuk 1, v. 2 db. 3,6 GHz-es Xeon, vagy ennek megfelelő Opteron esetében)
Ezért kérdezem: openssl speed aes-256-cbc aes-128-cbc rc4 Xeon 3,6 GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes rc4 176064.24k 193876.99k 194105.58k 195919.11k 195836.49k aes-128 cbc 86799.52k 86508.13k 87871.04k 87909.66k 87499.53k aes-256 cbc 68186.22k 68072.48k 68799.17k 68878.18k 68638.85k Opteron 2,6 GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes rc4 199176.58k 211440.53k 214415.49k 215701.30k 215309.61k aes-128 cbc 116271.85k 121968.38k 124703.97k 124738.94k 125472.10k aes-256 cbc 93523.44k 96341.03k 97944.74k 99193.38k 99214.87k -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
On Thu, 2005-08-11 at 12:35 +0200, Attila Nagy wrote:
Balazs Scheidler wrote:
kb. mint amennyire az SSL proxy, OpenSSL gyorsitokartyak alkalmazasaval ez is gyorsithato. Van arról valami publikus információ, hogy ezen SSL gyorsítók alkalmazása mennyire "kifizetődő" a mai processzorteljesítmények mellett? (mondjuk 1, v. 2 db. 3,6 GHz-es Xeon, vagy ennek megfelelő Opteron esetében)
Ezért kérdezem:
openssl speed aes-256-cbc aes-128-cbc rc4
A kerdes nem ennyire egyszeru, ugyanis a legtobb crypto-t hasznalo alkalmazas nem sima szimmetrikus ciphereket hasznal, sokkal inkabb egyfajta hibrid rendszert, es ha "openssl speed rsa" parancsot adsz ki, akkor lathato, hogy egy mai rendszer 1024 bites kulcsokkal 100% proci terheles mellett bizony kb 250-300 alairas muveletet tud vegrehajtani. tehat a gyorsitas egyik elsodleges celja az RSA muveletek off-loadolasa, igy a processzor egyeb fontos feladatokkal tud foglalkozni. (pl. elemzi a protokoll streamet). szimmetrikus gyorsitokartyaknal nem ennyire egyertelmu a helyzet, gyakran a setup illetve a PCI transfer ideje akkora latencyt okoz, hogy nagyobb atvitel erheto el kizarolag szoftveres crypto alkalmazasaval. itt ezeket kell merlegelni: - a CPU terhelese, vagy a latency a nagyobb problema? lehet, hogy a CPU terhelese mar akkora, hogy az ateresztokepesseg novekedne a gyorsitokartya alkalmazasaval, meg akkor is, ha setup/pci transfer idot visz el. - nagyobb blokkokat titkositva az overhead bytera vetitve csokkentheto -- Bazsi
Balazs Scheidler wrote:
A kerdes nem ennyire egyszeru, ugyanis a legtobb crypto-t hasznalo alkalmazas nem sima szimmetrikus ciphereket hasznal, sokkal inkabb egyfajta hibrid rendszert, es ha "openssl speed rsa" parancsot adsz ki, akkor lathato, hogy egy mai rendszer 1024 bites kulcsokkal 100% proci terheles mellett bizony kb 250-300 alairas muveletet tud vegrehajtani. Xeon 3,6 GHz: sign verify sign/s verify/s rsa 512 bits 0.0003s 0.0000s 3313.1 40031.9 rsa 1024 bits 0.0012s 0.0001s 861.0 15376.7 rsa 2048 bits 0.0066s 0.0002s 150.7 5036.9 rsa 4096 bits 0.0432s 0.0007s 23.1 1355.2
Opteron 2,6 GHz: rsa 512 bits 0.0002s 0.0000s 4748.2 53740.7 rsa 1024 bits 0.0006s 0.0000s 1573.6 24484.7 rsa 2048 bits 0.0033s 0.0001s 303.0 9478.9 rsa 4096 bits 0.0201s 0.0003s 49.8 3028.7 Hogy viszonyulnak ezek a számok a gyorsítókártyákéhoz? Egy nCipher nFast Ultra (nem tudom ez kb. milyen árban lehet) adatlapja 10000 TPS-t ad meg (RSA1024 decrypt, bővebb infót hirtelen nem találtam) 300 Mbps-es (full duplex) áteresztőképesség mellett. Itt némi előny látszik, de ha egy modern processzor képes 1600 műveletre másodpercenként, az (a vélhető árkülönbség miatt) nem tűnik olyan nagy veszteségnek. Gondolom ti is végeztetek mérést ilyen kártyákkal. Mikor ajánljátok? Ajánljátok?
tehat a gyorsitas egyik elsodleges celja az RSA muveletek off-loadolasa, igy a processzor egyeb fontos feladatokkal tud foglalkozni. (pl. elemzi a protokoll streamet). Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két processzoros dual core opteronos gépet, amely a fenti benchmark szerint olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik...
szimmetrikus gyorsitokartyaknal nem ennyire egyertelmu a helyzet, gyakran a setup illetve a PCI transfer ideje akkora latencyt okoz, hogy nagyobb atvitel erheto el kizarolag szoftveres crypto alkalmazasaval. Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő felépítés esetén ez a késleltetés kiiktatható.
itt ezeket kell merlegelni: - a CPU terhelese, vagy a latency a nagyobb problema? lehet, hogy a CPU terhelese mar akkora, hogy az ateresztokepesseg novekedne a gyorsitokartya alkalmazasaval, meg akkor is, ha setup/pci transfer idot visz el. Igen, ilyet én is el tudok képzelni.
Az árakkal nem vagyok tisztában, ezért (is) érdeklődök. Ha mondjuk egy megfelelő kártya a 3-500 ezer forintos kategóriában mozog (a fent említett Ultra elég high-endnek tűnik a cég többi kártyájához képest, de lehet, hogy mellélőttem :), akkor nekem úgy tűnik, hogy a "dobj bele a képletbe még több PC-t" gazdaságosabb és nem utolsósorban hibatűrőbb megoldást ad. Nem beszélve arról, hogy ha feltételezem (feltételezhetem?), hogy a Zorp cache-eli az SSL-es kapcsolatokat, akkor ez az 1500 TPS gyakorlatban sokkal többet jelenthet. Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :) Cache-elhetők ezek az SSL kapcsolatok? Köszönöm! -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
On Thu, Aug 11, 2005 at 03:26:50PM +0200, Attila Nagy wrote:
sign verify sign/s verify/s rsa 512 bits 0.0003s 0.0000s 3313.1 40031.9 rsa 1024 bits 0.0012s 0.0001s 861.0 15376.7 rsa 2048 bits 0.0066s 0.0002s 150.7 5036.9 rsa 4096 bits 0.0432s 0.0007s 23.1 1355.2
Opteron 2,6 GHz: rsa 512 bits 0.0002s 0.0000s 4748.2 53740.7 rsa 1024 bits 0.0006s 0.0000s 1573.6 24484.7 rsa 2048 bits 0.0033s 0.0001s 303.0 9478.9 rsa 4096 bits 0.0201s 0.0003s 49.8 3028.7
Hogy viszonyulnak ezek a számok a gyorsítókártyákéhoz?
ncipher nfast 800 kartya, xeon 3 ghz cpu-s masinaban openssl 0.9.7d # openssl speed -engine ubsec ... ... sign verify sign/s verify/s rsa 512 bits 0.0001s 0.0000s 13567.3 537271.4 rsa 1024 bits 0.0002s 0.0000s 6310.0 85403.8 rsa 2048 bits 0.0005s 0.0000s 1956.0 33750.0 rsa 4096 bits 0.0075s 0.0045s 133.3 224.2 sign verify sign/s verify/s dsa 512 bits 0.0000s 0.0000s 113550.0 512900.0 dsa 1024 bits 0.0000s 0.0000s 268200.0 297300.0 dsa 2048 bits 0.0000s 0.0000s 80000.0 407000.0 kb. 15-20%-os cpu terhelest okoz
Az árakkal nem vagyok tisztában, ezért (is) érdeklődök. Ha mondjuk egy megfelelő kártya a 3-500 ezer forintos kategóriában mozog (a fent nagyjabol ebbe a kategoriaba esik az ara
-- lajjan
Janos Lajos wrote:
ncipher nfast 800 kartya, xeon 3 ghz cpu-s masinaban openssl 0.9.7d # openssl speed -engine ubsec Köszönöm!
sign verify sign/s verify/s rsa 512 bits 0.0001s 0.0000s 13567.3 537271.4 rsa 1024 bits 0.0002s 0.0000s 6310.0 85403.8 rsa 2048 bits 0.0005s 0.0000s 1956.0 33750.0 rsa 4096 bits 0.0075s 0.0045s 133.3 224.2 sign verify sign/s verify/s dsa 512 bits 0.0000s 0.0000s 113550.0 512900.0 dsa 1024 bits 0.0000s 0.0000s 268200.0 297300.0 dsa 2048 bits 0.0000s 0.0000s 80000.0 407000.0 kb. 15-20%-os cpu terhelest okoz
Ezekszerint egy mai szerverprocesszor kb. 20-30%-os teljesítményt tud ehhez a kártyához képest. Az Ultra mennyivel "brutálisabb"?
Az árakkal nem vagyok tisztában, ezért (is) érdeklődök. Ha mondjuk egy megfelelő kártya a 3-500 ezer forintos kategóriában mozog (a fent nagyjabol ebbe a kategoriaba esik az ara És az Ultráé? :)
-- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
On Thu, Aug 11, 2005 at 05:26:08PM +0200, Attila Nagy wrote:
Janos Lajos wrote:
ncipher nfast 800 kartya, xeon 3 ghz cpu-s masinaban openssl 0.9.7d # openssl speed -engine ubsec Köszönöm!
szivesen,
ehhez a kártyához képest. Az Ultra mennyivel "brutálisabb"?
nagyjabol ebbe a kategoriaba esik az ara És az Ultráé? :)
nem tudom sajnos, nfast 800-asokat adtunk el eddig -- lajjan
On Thu, 2005-08-11 at 15:26 +0200, Attila Nagy wrote:
Balazs Scheidler wrote:
A kerdes nem ennyire egyszeru, ugyanis a legtobb crypto-t hasznalo alkalmazas nem sima szimmetrikus ciphereket hasznal, sokkal inkabb egyfajta hibrid rendszert, es ha "openssl speed rsa" parancsot adsz ki, akkor lathato, hogy egy mai rendszer 1024 bites kulcsokkal 100% proci terheles mellett bizony kb 250-300 alairas muveletet tud vegrehajtani. Xeon 3,6 GHz: sign verify sign/s verify/s rsa 512 bits 0.0003s 0.0000s 3313.1 40031.9 rsa 1024 bits 0.0012s 0.0001s 861.0 15376.7 rsa 2048 bits 0.0066s 0.0002s 150.7 5036.9 rsa 4096 bits 0.0432s 0.0007s 23.1 1355.2
Opteron 2,6 GHz: rsa 512 bits 0.0002s 0.0000s 4748.2 53740.7 rsa 1024 bits 0.0006s 0.0000s 1573.6 24484.7 rsa 2048 bits 0.0033s 0.0001s 303.0 9478.9 rsa 4096 bits 0.0201s 0.0003s 49.8 3028.7
Hogy viszonyulnak ezek a számok a gyorsítókártyákéhoz?
ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge): sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1314.0 14458.4 rsa 1024 bits 0.0038s 0.0002s 262.1 4719.6 rsa 2048 bits 0.0232s 0.0007s 43.1 1417.8 rsa 4096 bits 0.1592s 0.0025s 6.3 405.3 Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat.
Egy nCipher nFast Ultra (nem tudom ez kb. milyen árban lehet) adatlapja 10000 TPS-t ad meg (RSA1024 decrypt, bővebb infót hirtelen nem találtam) 300 Mbps-es (full duplex) áteresztőképesség mellett.
Itt némi előny látszik, de ha egy modern processzor képes 1600 műveletre másodpercenként, az (a vélhető árkülönbség miatt) nem tűnik olyan nagy veszteségnek.
Gondolom ti is végeztetek mérést ilyen kártyákkal. Mikor ajánljátok? Ajánljátok?
Nagy mennyisegu SSL kapcsolatoknal igen, a gepnek eppen eleg dolga van a forgalom kezelesevel.
tehat a gyorsitas egyik elsodleges celja az RSA muveletek off-loadolasa, igy a processzor egyeb fontos feladatokkal tud foglalkozni. (pl. elemzi a protokoll streamet). Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két processzoros dual core opteronos gépet, amely a fenti benchmark szerint olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik...
Azert altalanos celu op.rendszerekben nehez linearis skalazodast elerni tobb processzorra. Igazad lenne, ha a masodik processzor csak szamolna, ha viszont betolod egy Linux ala, akkor a processzorok kozti context switcheknek egy ido utan eleg nagy az overheadje.
szimmetrikus gyorsitokartyaknal nem ennyire egyertelmu a helyzet, gyakran a setup illetve a PCI transfer ideje akkora latencyt okoz, hogy nagyobb atvitel erheto el kizarolag szoftveres crypto alkalmazasaval. Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő felépítés esetén ez a késleltetés kiiktatható.
Nincs sajnos, de ez SSL-hez valoszinuleg nem illesztheto, csak IPSec-hez, ahol mar egy osszerakott csomagot kell titkositani. Az SSL meg nagyon "messze" van a halokartyatol. Az SSL adatreteg tobb csomagba tordelodhet, mire az IP szintre kerul, nem is beszelve az esetleges (bar ritkan valos) IP fragmentation-tol, illetve a retransmittalt csomagokrol, amit SSL eseten ugyanazzal az IV-vel kell kezdeni. Az IPSec ezzel szemben csomagszinten talalhato, egy osszerakott csomag bizonyos reszenek titkositasat konnyen lehet offloadolni.
Az árakkal nem vagyok tisztában, ezért (is) érdeklődök. Ha mondjuk egy megfelelő kártya a 3-500 ezer forintos kategóriában mozog (a fent említett Ultra elég high-endnek tűnik a cég többi kártyájához képest, de lehet, hogy mellélőttem :), akkor nekem úgy tűnik, hogy a "dobj bele a képletbe még több PC-t" gazdaságosabb és nem utolsósorban hibatűrőbb megoldást ad.
Az nForce 800-as az 100k forintos nagysagrend (max 200k, nem emlekszem pontosan), Ultra-t meg nem hasznaltunk.
Nem beszélve arról, hogy ha feltételezem (feltételezhetem?), hogy a Zorp cache-eli az SSL-es kapcsolatokat, akkor ez az 1500 TPS gyakorlatban sokkal többet jelenthet.
Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :)
Cache-elhetők ezek az SSL kapcsolatok?
Elvileg igen. -- Bazsi
On Thu, 2005-08-11 at 16:01 +0200, Balazs Scheidler wrote:
ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge):
sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1314.0 14458.4 rsa 1024 bits 0.0038s 0.0002s 262.1 4719.6 rsa 2048 bits 0.0232s 0.0007s 43.1 1417.8 rsa 4096 bits 0.1592s 0.0025s 6.3 405.3
Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat.
Hazon belul mar volt errol szo, a kulonbseg nagyreszt abbol adodik (szerintem), hogy az openssl a 0.9.7f-tol kezdodoen jobban van optimalizalva. A debian sarge sajna 0.9.7e-vel kerult kiadasra... Ugyanazon a gepen, ugyanazzal a gcc-vel forditott OpenSSL 0.9.8 (ZorpOS 3.1) vs OpenSSL 0.9.7e (debian sarge): hapci:/# openssl speed rsa Doing 512 bit private rsa's for 10s: 11367 512 bit private RSA's in 10.00s Doing 512 bit public rsa's for 10s: 146747 512 bit public RSA's in 10.00s Doing 1024 bit private rsa's for 10s: 2603 1024 bit private RSA's in 9.99s Doing 1024 bit public rsa's for 10s: 56380 1024 bit public RSA's in 9.99s Doing 2048 bit private rsa's for 10s: 486 2048 bit private RSA's in 10.01s Doing 2048 bit public rsa's for 10s: 19234 2048 bit public RSA's in 10.00s Doing 4096 bit private rsa's for 10s: 82 4096 bit private RSA's in 10.10s Doing 4096 bit public rsa's for 10s: 5704 4096 bit public RSA's in 10.00s OpenSSL 0.9.8 05 Jul 2005 built on: Thu Jul 14 11:42:27 CEST 2005 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times sign verify sign/s verify/s rsa 512 bits 0.000880s 0.000068s 1136.7 14674.7 rsa 1024 bits 0.003838s 0.000177s 260.6 5643.6 rsa 2048 bits 0.020597s 0.000520s 48.6 1923.4 rsa 4096 bits 0.123171s 0.001753s 8.1 570.4 hapci:~# openssl speed rsa Doing 512 bit private rsa's for 10s: 10938 512 bit private RSA's in 9.99s Doing 512 bit public rsa's for 10s: 104334 512 bit public RSA's in 8.41s Doing 1024 bit private rsa's for 10s: 1311 1024 bit private RSA's in 5.96s Doing 1024 bit public rsa's for 10s: 39929 1024 bit public RSA's in 10.00s Doing 2048 bit private rsa's for 10s: 346 2048 bit private RSA's in 9.50s Doing 2048 bit public rsa's for 10s: 11491 2048 bit public RSA's in 9.50s Doing 4096 bit private rsa's for 10s: 54 4096 bit private RSA's in 10.11s Doing 4096 bit public rsa's for 10s: 3418 4096 bit public RSA's in 10.00s OpenSSL 0.9.7e 25 Oct 2004 built on: Fri Dec 17 08:45:11 UTC 2004 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DL_ENDIAN -DTERMIO -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times sign verify sign/s verify/s rsa 512 bits 0.0009s 0.0001s 1094.9 12405.9 rsa 1024 bits 0.0045s 0.0003s 220.0 3992.9 rsa 2048 bits 0.0275s 0.0008s 36.4 1209.6 rsa 4096 bits 0.1872s 0.0029s 5.3 341.8 Mindez egy Intel(R) Pentium(R) 4 CPU 2.53GHz procin, terhelt rendszeren. -- Geller Sandor wildy@balabit.hu
Sandor Geller wrote:
Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat. Hazon belul mar volt errol szo, a kulonbseg nagyreszt abbol adodik (szerintem), hogy az openssl a 0.9.7f-tol kezdodoen jobban van optimalizalva. A debian sarge sajna 0.9.7e-vel kerult kiadasra... Hmm. Úgy tűnik inkább a 64 bites mód dob rajta (dupláz). Gondolom a több regiszter és a 64 bit előnyei...
Ugyanazon a gepen, ugyanazzal a gcc-vel forditott OpenSSL 0.9.8 (ZorpOS 3.1) vs OpenSSL 0.9.7e (debian sarge): [...] Mindez egy Intel(R) Pentium(R) 4 CPU 2.53GHz procin, terhelt rendszeren. Lássuk. Csak az opteronos cuccot nézem.
Opteron 2,6 GHz FreeBSD/AMD64 6.0: OpenSSL 0.9.7e 25 Oct 2004 (system openssl) sign verify sign/s verify/s rsa 512 bits 0.0002s 0.0000s 4744.5 52892.1 rsa 1024 bits 0.0006s 0.0000s 1593.8 24855.7 rsa 2048 bits 0.0033s 0.0001s 304.8 9444.6 rsa 4096 bits 0.0200s 0.0003s 49.9 3042.5 OpenSSL 0.9.7g 11 Apr 2005 (port) sign verify sign/s verify/s rsa 512 bits 0.0003s 0.0000s 3977.8 45649.6 rsa 1024 bits 0.0009s 0.0001s 1142.2 19069.1 rsa 2048 bits 0.0050s 0.0002s 201.9 6488.0 rsa 4096 bits 0.0321s 0.0005s 31.2 1932.2 OpenSSL 0.9.8 05 Jul 2005 (port) sign verify sign/s verify/s rsa 512 bits 0.000218s 0.000017s 4592.1 58040.5 rsa 1024 bits 0.000707s 0.000038s 1414.5 26070.9 rsa 2048 bits 0.003594s 0.000103s 278.2 9743.3 rsa 4096 bits 0.021389s 0.000326s 46.8 3070.2 BTW, ugyanaz a gép 32, illetve 64 bites módban (Xeon 3,6 GHz): uname -m i386 sign verify sign/s verify/s rsa 512 bits 0.0007s 0.0001s 1425.9 15478.6 rsa 1024 bits 0.0034s 0.0002s 291.7 5471.6 rsa 2048 bits 0.0207s 0.0006s 48.4 1677.0 rsa 4096 bits 0.1369s 0.0021s 7.3 474.1 uname -m amd64 sign verify sign/s verify/s rsa 512 bits 0.0003s 0.0000s 3311.8 39559.3 rsa 1024 bits 0.0012s 0.0001s 861.7 15464.6 rsa 2048 bits 0.0067s 0.0002s 149.6 5009.6 rsa 4096 bits 0.0435s 0.0007s 23.0 1357.6 -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
Attila Nagy wrote:
BTW, ugyanaz a gép 32, illetve 64 bites módban (Xeon 3,6 GHz): i386 rsa 512 bits 0.0007s 0.0001s 1425.9 15478.6 amd64 rsa 512 bits 0.0003s 0.0000s 3311.8 39559.3 Tervezitek a ZorpOS AMD64-es verzióját? :)
-- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
Balazs Scheidler wrote:
ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge): Xeon: FreeBSD 5.4 OpenSSL 0.9.7e 25 Oct 2004 gcc version 3.4.2 [FreeBSD] 20040728
Opteron: FreeBSD 6.0 OpenSSL 0.9.7e 25 Oct 2004 gcc version 3.4.4 [FreeBSD] 20050518 Mindkét gép AMD64-es üzemmódban megy (azaz a Xeon EM64T, ahogy az Intel szeretné hívni).
sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1314.0 14458.4 rsa 1024 bits 0.0038s 0.0002s 262.1 4719.6 rsa 2048 bits 0.0232s 0.0007s 43.1 1417.8 rsa 4096 bits 0.1592s 0.0025s 6.3 405.3
Az asztali gépem (2,8 GHz P4) is hasonlót tud: sign verify sign/s verify/s rsa 512 bits 0.0009s 0.0001s 1140.6 12345.8 rsa 1024 bits 0.0042s 0.0002s 236.6 4348.8 rsa 2048 bits 0.0254s 0.0008s 39.4 1325.1 rsa 4096 bits 0.1704s 0.0026s 5.9 378.1
Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat. 512 kB cache-sel rendelkező 3,06 GHz-es Xeon: sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1268.6 13669.1 rsa 1024 bits 0.0039s 0.0002s 258.5 4820.7 rsa 2048 bits 0.0232s 0.0007s 43.1 1476.1 rsa 4096 bits 0.1563s 0.0024s 6.4 416.5
A te géped megveri (lehet, hogy FSB, vagy valami chipset mágia, vagy csak a FreeBSD ilyen gagyi? :).
Gondolom ti is végeztetek mérést ilyen kártyákkal. Mikor ajánljátok? Ajánljátok? Nagy mennyisegu SSL kapcsolatoknal igen, a gepnek eppen eleg dolga van a forgalom kezelesevel. Az eddigi számok alapján nekem úgy tűnik, hogy alternatívája lehet a sok olcsó gép a sok olcsó gép+kriptokártya felállásnak.
Persze itt is a terhelési minta a meghatározó. Ahol sok kapcsolatfelépítés van, jó lehet a kártya, de ahol inkább adatmozgatás, azt kilapátolja a PC is.
Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két processzoros dual core opteronos gépet, amely a fenti benchmark szerint olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik... Azert altalanos celu op.rendszerekben nehez linearis skalazodast elerni tobb processzorra. Igazad lenne, ha a masodik processzor csak szamolna, ha viszont betolod egy Linux ala, akkor a processzorok kozti context switcheknek egy ido utan eleg nagy az overheadje. Persze, a processzek közötti környezetváltás is rengeteg idő, főleg ha másik processzorra migrálja az OS. :)
A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön thread/processz végezné, nem? Ebben az esetben gyakorlatilag megvalósítható lenne az is, hogy ezeket a processzeket egyes processzorra dedikálja a user, azokból pedig load balance-olt poolt építsen. Végeztetek esetleg mérést arra nézve, hogy egy ilyen lehetőség mennyit segítene (a fentiekből azt feltételezem, hogy most a zorp nem külön végzi ezeket a műveleteket, így nem is lehet procit dedikálni alá)? Ha jelentős lenne a különbség, sokat dobhatna a teljesítményen, főleg a mostani multicore-os CPU-k esetében.
Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő felépítés esetén ez a késleltetés kiiktatható. Nincs sajnos, de ez SSL-hez valoszinuleg nem illesztheto, csak IPSec-hez, ahol mar egy osszerakott csomagot kell titkositani. Az SSL Persze, azt hiszem ezt már csak durva firmware hackkel lehetne megoldani. De erre is volt már példa. :)
Az nForce 800-as az 100k forintos nagysagrend (max 200k, nem emlekszem pontosan), Ultra-t meg nem hasznaltunk. Köszi.
Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :) Cache-elhetők ezek az SSL kapcsolatok? Elvileg igen. Az mit jelent? Az apache-ban például van SSL session cache. Van ilyen a zorpban?
Jobbat kérdezek (ha van): van lehetőség arra, hogy mondjuk memcached-del ezt a session store-t több gépen is használhatóvá tegyük? Teszemazt ha valódi load balancingot szeretnénk, nem pedig IP alapú stickys megoldást. (minden új kapcsolat mehet más zorpra, még ugyanarról az IP-ről is) Lehet, hogy inkább doksit kellene olvasnom, de ha már így belejöttem, megkérdezem azt is, hogy a többi (ha van) session jellegű infó közös tárolására vizsgáltátok-e már egy ilyen elosztott tudás jellegű megoldás előnyeit? Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye vagyok a zorphoz, na. :) -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
On Thu, 2005-08-11 at 18:04 +0200, Attila Nagy wrote:
Balazs Scheidler wrote:
ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge): Xeon: FreeBSD 5.4 OpenSSL 0.9.7e 25 Oct 2004 gcc version 3.4.2 [FreeBSD] 20040728
Opteron: FreeBSD 6.0 OpenSSL 0.9.7e 25 Oct 2004 gcc version 3.4.4 [FreeBSD] 20050518
Mindkét gép AMD64-es üzemmódban megy (azaz a Xeon EM64T, ahogy az Intel szeretné hívni).
aha, ez indokolhatja a kulonbseget.
Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat. 512 kB cache-sel rendelkező 3,06 GHz-es Xeon: sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1268.6 13669.1 rsa 1024 bits 0.0039s 0.0002s 258.5 4820.7 rsa 2048 bits 0.0232s 0.0007s 43.1 1476.1 rsa 4096 bits 0.1563s 0.0024s 6.4 416.5
A te géped megveri (lehet, hogy FSB, vagy valami chipset mágia, vagy csak a FreeBSD ilyen gagyi? :).
nem tudom :) azt nem is mondtam, hogy notebook-rol van szo, ahhoz kepest nem is rossz.
Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két processzoros dual core opteronos gépet, amely a fenti benchmark szerint olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik... Azert altalanos celu op.rendszerekben nehez linearis skalazodast elerni tobb processzorra. Igazad lenne, ha a masodik processzor csak szamolna, ha viszont betolod egy Linux ala, akkor a processzorok kozti context switcheknek egy ido utan eleg nagy az overheadje. Persze, a processzek közötti környezetváltás is rengeteg idő, főleg ha másik processzorra migrálja az OS. :)
A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön thread/processz végezné, nem? Ebben az esetben gyakorlatilag megvalósítható lenne az is, hogy ezeket a processzeket egyes processzorra dedikálja a user, azokból pedig load balance-olt poolt építsen. Végeztetek esetleg mérést arra nézve, hogy egy ilyen lehetőség mennyit segítene (a fentiekből azt feltételezem, hogy most a zorp nem külön végzi ezeket a műveleteket, így nem is lehet procit dedikálni alá)?
Nem vegeztunk, pedig erdekes lenne. Jobban vegig gondolva nem hiszem, hogy jobb megoldas out-of-line vegezni a kripto muveleteket a masodik processzoron, ez mindenkeppen latency-t ad hozza. Inkabb arra kell figyelni, hogy az emlitett kripto kodok lehetoleg lockolas nelkul fussanak.
Ha jelentős lenne a különbség, sokat dobhatna a teljesítményen, főleg a mostani multicore-os CPU-k esetében.
Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő felépítés esetén ez a késleltetés kiiktatható. Nincs sajnos, de ez SSL-hez valoszinuleg nem illesztheto, csak IPSec-hez, ahol mar egy osszerakott csomagot kell titkositani. Az SSL Persze, azt hiszem ezt már csak durva firmware hackkel lehetne megoldani. De erre is volt már példa. :)
naja, ha az openssl magan a kartyan futna es lenne ott egy kulon TCP/IP stack.
Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :) Cache-elhetők ezek az SSL kapcsolatok? Elvileg igen. Az mit jelent? Az apache-ban például van SSL session cache. Van ilyen a zorpban?
1) az openssl-ben van processzen beluli session cache, ezt kulon implementalni nem kell 2) megneztem kozelebbrol, es sajnos ahogy a Zorp hasznalja az SSL-t, ugy ez a cache nem mukodik. fel is vettem egy hibajegyet ezzel kapcsolatban.
Jobbat kérdezek (ha van): van lehetőség arra, hogy mondjuk memcached-del ezt a session store-t több gépen is használhatóvá tegyük?
bar a memcached-t nem ismerem, de az OpenSSL lehetove teszi un. "external session id cache" letrehozasat, ezt hasznalja az apache is a fork()-olt processzek kotzi adatmegosztashoz.
Teszemazt ha valódi load balancingot szeretnénk, nem pedig IP alapú stickys megoldást. (minden új kapcsolat mehet más zorpra, még ugyanarról az IP-ről is)
lehet ilyet, bar nem tudom milyen gyakorlati elonnyel jarna. nyilvan a kiesett node miatt a kliens atkerulhet egy masik gepre, de ott is max egy kulcs-cseret kell vegrehajtania, es utana mar ott is cachelt a kapcsolata.
Lehet, hogy inkább doksit kellene olvasnom, de ha már így belejöttem, megkérdezem azt is, hogy a többi (ha van) session jellegű infó közös tárolására vizsgáltátok-e már egy ilyen elosztott tudás jellegű megoldás előnyeit?
meg nem :)
Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye vagyok a zorphoz, na. :)
jelenleg session informaciot csak a peldanyon belul lehet megtartani, ott viszont eleg egyszeru. (azaz azt meg lehet oldani kizarolag Zorp-bol, hogy a sikeres POP3 authentikacio utan mukodik az SMTP, bar ugye ezt mar tulhaladta a kor az SMTP auth miatt). -- Bazsi
Balazs Scheidler wrote:
A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön thread/processz végezné, nem? Ebben az esetben gyakorlatilag Nem vegeztunk, pedig erdekes lenne. Jobban vegig gondolva nem hiszem, hogy jobb megoldas out-of-line vegezni a kripto muveleteket a masodik processzoron, ez mindenkeppen latency-t ad hozza. Inkabb arra kell figyelni, hogy az emlitett kripto kodok lehetoleg lockolas nelkul fussanak. Ezt kifejtenéd kicsit? Hogyhogy lockolás nélkül? Ha jól sejtem, jelenleg minden openssl-t használó része a Zorpnak külön forkolt processzben fut és nem többszálú. Hol jön itt képbe a lockolás?
Latency... Gyanítom, hogy a memóriasávszélesség (legrosszabb esetben) azért nagyobb, mint a legnagyobb PCI buszé. :) Arról nem is beszélve, hogy a kernel egy processzt futásidőben is áttehet másik processzorra és mivel a kripto nincs szétválasztva mondjuk a protokollelemzéstől, így viszonylag rossz ötletnek tűnik az erre forkolt processzt processzorhoz kötni. De lehet, hogy teljesen hülyeség, ehhez tényleg meg kellene nézni valami életszerű környezetben.
Persze, azt hiszem ezt már csak durva firmware hackkel lehetne megoldani. De erre is volt már példa. :) naja, ha az openssl magan a kartyan futna es lenne ott egy kulon TCP/IP stack. Semmi sem lehetetlen. :)
1) az openssl-ben van processzen beluli session cache, ezt kulon implementalni nem kell 2) megneztem kozelebbrol, es sajnos ahogy a Zorp hasznalja az SSL-t, ugy ez a cache nem mukodik. fel is vettem egy hibajegyet ezzel kapcsolatban. Nagyszerűen hangzik, köszönöm. :)
Jobbat kérdezek (ha van): van lehetőség arra, hogy mondjuk memcached-del ezt a session store-t több gépen is használhatóvá tegyük? bar a memcached-t nem ismerem, de az OpenSSL lehetove teszi un. "external session id cache" letrehozasat, ezt hasznalja az apache is a fork()-olt processzek kotzi adatmegosztashoz. Gondolom ez működik TCP/UDP socketen is.
Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye vagyok a zorphoz, na. :) jelenleg session informaciot csak a peldanyon belul lehet megtartani, ott viszont eleg egyszeru. (azaz azt meg lehet oldani kizarolag Zorp-bol, hogy a sikeres POP3 authentikacio utan mukodik az SMTP, bar ugye ezt mar tulhaladta a kor az SMTP auth miatt). Az igaz, de az, hogy a lehetőséget biztosítja a Zorp azért jelent valamit. :)
-- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
On Mon, 2005-08-15 at 12:14 +0200, Attila Nagy wrote:
Balazs Scheidler wrote:
A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön thread/processz végezné, nem? Ebben az esetben gyakorlatilag Nem vegeztunk, pedig erdekes lenne. Jobban vegig gondolva nem hiszem, hogy jobb megoldas out-of-line vegezni a kripto muveleteket a masodik processzoron, ez mindenkeppen latency-t ad hozza. Inkabb arra kell figyelni, hogy az emlitett kripto kodok lehetoleg lockolas nelkul fussanak. Ezt kifejtenéd kicsit? Hogyhogy lockolás nélkül? Ha jól sejtem, jelenleg minden openssl-t használó része a Zorpnak külön forkolt processzben fut és nem többszálú. Hol jön itt képbe a lockolás?
A Zorp tobbszalu, nem hasznal fork()-t. Szoval sejtesem szerint meg mindig erdemesebb inline hasznalni a kripto muveletet, ha azokat nem vedi lock, akkor valoszinuleg viszonylag jol fog skalazodni, es nem keletkezik latency. (ld. lentebb)
Latency... Gyanítom, hogy a memóriasávszélesség (legrosszabb esetben) azért nagyobb, mint a legnagyobb PCI buszé. :)
Ez igaz, de azert meg mindig meg kell varnod azt, hogy a masik processzoron elinduljon az adott muvelet, azaz felebredjen az ott futo szal.
Arról nem is beszélve, hogy a kernel egy processzt futásidőben is áttehet másik processzorra és mivel a kripto nincs szétválasztva mondjuk a protokollelemzéstől, így viszonylag rossz ötletnek tűnik az erre forkolt processzt processzorhoz kötni.
De lehet, hogy teljesen hülyeség, ehhez tényleg meg kellene nézni valami életszerű környezetben.
Szerintem is merni kell ehhez, de en inkabb arra fogadnek, hogy az inline futo kripto jobb lesz (nagy mennyisegu szal eseten O(1)-es utemezovel) -- Bazsi
Balazs Scheidler wrote:
Ezt kifejtenéd kicsit? Hogyhogy lockolás nélkül? Ha jól sejtem, jelenleg minden openssl-t használó része a Zorpnak külön forkolt processzben fut és nem többszálú. Hol jön itt képbe a lockolás? A Zorp tobbszalu, nem hasznal fork()-t. Szoval sejtesem szerint meg mindig erdemesebb inline hasznalni a kripto muveletet, ha azokat nem vedi lock, akkor valoszinuleg viszonylag jol fog skalazodni, es nem keletkezik latency. (ld. lentebb) Ez számomra teljesen új információ, mert annak ellenére, hogy életemben nem használtam Zorpot, szentül meg voltam róla győződve, hogy forkol. :) Pedig még a FAQ-ban is benne van: http://www.balabit.com/products/zorp/faq/#question22 Apropó: "supports more the one connection." than?
És akkor már lejjebb is: "Which ICMP pachet types" packet? Sorry, így már értem a lockot. Köszönöm a türelmed, ma is okosabb lettem. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
On Tue, 2005-08-16 at 10:29 +0200, Attila Nagy wrote:
Balazs Scheidler wrote:
Ezt kifejtenéd kicsit? Hogyhogy lockolás nélkül? Ha jól sejtem, jelenleg minden openssl-t használó része a Zorpnak külön forkolt processzben fut és nem többszálú. Hol jön itt képbe a lockolás? A Zorp tobbszalu, nem hasznal fork()-t. Szoval sejtesem szerint meg mindig erdemesebb inline hasznalni a kripto muveletet, ha azokat nem vedi lock, akkor valoszinuleg viszonylag jol fog skalazodni, es nem keletkezik latency. (ld. lentebb) Ez számomra teljesen új információ, mert annak ellenére, hogy életemben nem használtam Zorpot, szentül meg voltam róla győződve, hogy forkol. :) Pedig még a FAQ-ban is benne van: http://www.balabit.com/products/zorp/faq/#question22 Apropó: "supports more the one connection." than?
more than one. koszi, kijavitottam mindket typo-t. elvileg holnapra ki is szinkronizalodik. -- Bazsi
"az SSH csatornakra meg nem lehet stackelni" Az a "még", az várhatóan meddig tart? :o) Krisz Balazs Scheidler wrote:
On Tue, 2005-08-09 at 23:24 +0200, Kosa Attila wrote:
nagyjabol a teljes SSH protokoll stacket ismeri, egy-ket korlat mellett:
- binaris authentikaciok, amik tartalmazzak a session_id-t, ilyen peldaul a publickey es a gssapi autentikacio (mar van egy elgondolasunk, ami alapjan bizonyos esetekben mukodni fog ez is) - az SSH csatornakra meg nem lehet stackelni - a kereseket jelenleg nem lehet modositani, egyszeru engedem/nem engedem dontest lehet hozni. (pl. engedem-e az LD_LIBRARY_PATH kornyezeti valtozo beallitasat, vagy nem)
Mar most is kepes egy olyan SSH csatorna kialakitasara, amiben csak terminalkapcsolat lehetseges, port, X, agent forwarding illetve parancsfuttatas nem.
On Thu, 2005-08-18 at 16:14 +0200, Eyssen Krisztián wrote:
"az SSH csatornakra meg nem lehet stackelni" Az a "még", az várhatóan meddig tart? :o)
Egyenlore igazabol nem lattam olyan helyzetet, ahol kimondottan ugyfelek altal igenyelt megoldas lenne. Port forwardot leginkabb a rendszergazda hasznal, amikor az SSH-n belul eri el a leveleit. Ezt onmagaban kevesnek erzem, valos, uzleti folyamatokba illeszkedoen hasznalt port forwardot meg nem nagyon lattam, de meggyozheto vagyok. Ettol fuggetlenul valoszinuleg bele fog kerulni egy kesobbi verzioba. -- Bazsi
Bocsanat hogy beleszolok, de nalam egy 2.1-es fizetos verzio mukodik es hire-hamva sincs ssh proxynak...de meg a a 3.0-as termekleirasban sem latok ilyet...ez valami uj dolog ? Szalay Attila wrote:
On Tue, 2005-08-09 at 23:04 +0200, Kosa Attila wrote:
Jol ertem, hogy letezik ssh proxy? A gpl-es verzioban is, vagy csak a fizetosben? A "tudasarol" lehetne bovebbet hallani?
Jol erted. (Egyenlore) csak a fizetosben es nem hiszem, hogy a kozeljovoben kikerulne a gpl-be is.
A tudasarol szerintem majd nyilatkozik mas illetekesebb, en kb. annyit tudok (merek :) mondani, hogy ugyanugy mint az ssl-nel az ssh proxy is terminalja a protokollt, ezaltal belelat a benne levo adatba. Ez magaba foglalja a kulcscseret, a csatornakat, az azonositast, stb.
-- Zelei Tamas ELGI.HU NETWORK ADMINISTRATOR Magyar Allami Eotvos Lorand Geofizikai Intezet 1145. Budapest, Kolumbusz u. 17-23. Tel:252-4999/137,290. Fax: 363-7256 E-mail: zelei@elgi.hu
On Tue, 2005-08-09 at 23:26 +0200, Zelei Tamas ELGI.HU NETWORK ADMINISTRATOR wrote:
Bocsanat hogy beleszolok, de nalam egy 2.1-es fizetos verzio mukodik es hire-hamva sincs ssh proxynak...de meg a a 3.0-as termekleirasban sem latok ilyet...ez valami uj dolog ?
Igen ez uj dolog. De felek, hogy mar ezert is leveszik a fejemet a marketingesek. :) -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
Jolvan, akkor nem faggatunk, gondolom karacsonyra meglepeteskent akartatok a kov frissitesbe betenni...koszonjuk elore is :) Szalay Attila wrote:
On Tue, 2005-08-09 at 23:26 +0200, Zelei Tamas ELGI.HU NETWORK ADMINISTRATOR wrote:
Bocsanat hogy beleszolok, de nalam egy 2.1-es fizetos verzio mukodik es hire-hamva sincs ssh proxynak...de meg a a 3.0-as termekleirasban sem latok ilyet...ez valami uj dolog ?
Igen ez uj dolog. De felek, hogy mar ezert is leveszik a fejemet a marketingesek. :)
-- Zelei Tamas ELGI.HU NETWORK ADMINISTRATOR Magyar Allami Eotvos Lorand Geofizikai Intezet 1145. Budapest, Kolumbusz u. 17-23. Tel:252-4999/137,290. Fax: 363-7256 E-mail: zelei@elgi.hu
Szalay Attila wrote:
On Tue, 2005-08-09 at 23:26 +0200, Zelei Tamas ELGI.HU NETWORK ADMINISTRATOR wrote:
Bocsanat hogy beleszolok, de nalam egy 2.1-es fizetos verzio mukodik es hire-hamva sincs ssh proxynak...de meg a a 3.0-as termekleirasban sem latok ilyet...ez valami uj dolog ?
Igen ez uj dolog. De felek, hogy mar ezert is leveszik a fejemet a marketingesek. :)
miért? Szerintem frankó gerillamarketing. Egyébknét bárki-bármit mond, a Zorp elterjedésében nagy szerepe volt a személyes ismeretségnek, az ilyen irányú információáramlásnak is. Nem tudott a Balabit akkor 100 millát belenyomni egy évre, amiben csak ismertetők, előadások, saját konfok és napok, meg reklámanyagok stb vannak. Most nem múlik semmi azon, hogy megtudtuk, a belső teszteken már megy a dolog. üdv, A
participants (11)
-
Attila Nagy
-
Balazs Scheidler
-
Deim Ágoston
-
Eyssen Krisztián
-
Hegedüs Ervin
-
Janos Lajos
-
Kosa Attila
-
Papp Tamas
-
Sandor Geller
-
Szalay Attila
-
Zelei Tamas ELGI.HU NETWORK ADMINISTRATOR