Hlavní navigace

Vlákno názorů k článku High Performance SSH/SCP: rychlé přenosy souborů bezpečným kanálem od Vít Šesták - Čéká to na ACK na úrovni TCP/IP? Teoreticky...

  • Článek je starý, nové názory již nelze přidávat.
  • 7. 12. 2017 15:21

    Vít Šesták

    Čéká to na ACK na úrovni TCP/IP? Teoreticky by to šlo urychlit hackem, kdy by nějaká blízká proxy posílala zpět ACKy a bufferovala výstup. Možná by se dalo použít i něco jako nc.

    Samozřejmě je to ohack a použil bych to spíše ve chvíli, když by bylo problematické použít zmíněný patch.

  • 8. 12. 2017 22:03

    . . (neregistrovaný)

    a kolik dat se vejde do bufferu proxy? Pokud se vše nepovede doručit na první dobrou, kdo se bude starat o retrans?

  • 8. 12. 2017 22:58

    Vít Šesták

    > a kolik dat se vejde do bufferu proxy?

    Podle toho, co by kdo použil, jak by si to nastavil atd. Možná by se takováto jednoduchá proxyna dala vyrobit i z nc, ale netuším moc, jak se tento nástroj chová.

    > Pokud se vše nepovede doručit na první dobrou, kdo se bude starat o retrans?

    Ta proxy, aspoň na úrovni TCP. Pokud ale například umře spojení, je nutné udělat novou session, s tím proxyna už nic nenadělá.

  • 9. 12. 2017 19:42

    . . (neregistrovaný)

    mně připadá, že to je škrábání se špatnou nohou za špatným uchem.

    To raději to ssh co nejdříve ukončit a na dané "proxy" si mountnout FS vhodnějším protokolem, což mimochodem se také často dělá.

    Z těhle obcházení limitů vznikají hodně zákeřné problémy a je lepší ty technologie používat tak, jak jsou testované.

  • 9. 12. 2017 21:14

    Vít Šesták

    Uznávám, že je to ohack, ale proxyna na této vrstvě nemá jiné možnosti než útočník. Ten taky může poslat falešný ACK po TCP a mělo by to způsobit přinejhorším DoS. Stejnětak tento hack.

    Jinak řečeno, budou-li problémy s tímto hackem, máme něco špatně zabezpečeno.

    Co se týče použití jiného protokolu, je to samozřejmě taky cesta, otázkou ale zůstává, který protokol použít, abychom dostali odpovídající zabezpečení, stejnou funkcionalitu a podporu na druhé straně. To záleží na situaci.

  • 9. 12. 2017 23:03

    . . (neregistrovaný)

    tenhle hack může zlobit tehdy, když síť má příliš vysoké latence nebo se vnější vinou sníží propustnost, proxy nebude mít neomezený buffer a jednou jí dojde, client bude mít falešné informace o tom co je již posláno a může dojít ke ztrátě dat, v zajištění integrity bych viděl velký problém. Pokud mi někdo posílá falešná ACK, neměl bych to řešit na téhle úrovni, ale o trochu níže.

    nfsv4 se používá se kerberosem, iscsi s ipsecem, pokud data tečou přímo na pásky, je tady několik nativní rozšíření pro iscsi (v praxi jsem potkal t10 s ibm storage system).

    Podpora na druhé straně je problém, pokdu se jedná o nějaký enterprise storage system, moc na výběr často není, vždy je možnost to protlouct hrubou silou a multiplikovat ssh spojení tak abych měl odpovídající průtok. Rozhodně bych se ale nepouštět do tebou navrhnovaného hacku, raději bych zajistit integrační server, který na jedné straně bude mít blízké ssh klienty a na druhé nějaký vhodnější protokol, viz odstavec hore.

  • 9. 12. 2017 23:19

    Vít Šesták

    Opakuju, pokud falešné ACKy mohou způsobit problém jako ztrátu integrity, je to zranitelnost, protože totéž může udělat útočník na síti. Neznám všechny detaily SSH, ale není to úplně noname záležitost, a předpokládám, že se TCP ACK bere jen jako taková první aproximace. Tzn. pokud ACK dorazí, víme, že data nemusíme posílat znovu, ale nevíme, co vlastně dorazilo druhé straně.

    Spoléhání se na ACK mimochodem není dobré ani pokud síti věřím. Pokud na druhé straně třeba spadne aplikace, dojde místo nebo něco podobného, ACK nejspíš dorazí, ale data se nezpracují, jak bych chtěl. Takže stejně nemohu na aplikační vrstvě rozhodnout o provedení akce jen podle ACKu, ale potřebuju i něco jako ACK na aplikační vrstvě. Tedy na vyšší vrstvě, ne na nižší.

    Ad co se stane, když se proxyně zaplní buffer: Pak by měla přestat posílat další ACKy zpátky.