IP Tunelre titkosítás szükséges pluszban?

Hálózatok általános

Helló,

Két lokáció között van IP tunnel. Minden ami a tunelben van eleve titkosított (SSH, HTTPS-en, stb), így szükséges/érdemes e a tunel fölé titkosítást (IPsec) rakni, vagy tökmindegy?

A fő ok amiatt kérdezem, mivel mikrotikben nem lehet fastpath a tunnelen ha ipsec van, nem tudom ez mennyit lassit majd a dolgon.

( mauzi v | 2019. 11. 12., k – 15:10 )

Szerkesztve: 2019. 11. 12., k – 15:13

> Minden ami a tunnelben van eleve titkosított...

Egészen addig, amíg véletlenül arra nem küldesz valamit, ami nem titkosított...
Egyébként, Te tudod, hogy az egyes IP fejléceidet, SNI csomagokat, stb. mennyire akarod elrejteni a külvilágtól...

BTW, az ipsec erőforrás-igénye mellett a fastpath hiánya lesz a legkisebb bajod.

HW-ből megy az ipsec titkosítás, így ez nem okoz gondot.

A véletlen dologra, hát ennyi erővel a neten is kimehet titkosítatlanul. Ezt nem tartom reális veszélynek.

node a lényeges rész, akkor ezek az ip fejléc stb dolog. Ez mennyire valós veszély? Mire lehet használni?

Domain, tárhely és webes megoldások: aWh

Köszi az infot, csináltam egy kis tesztet. RouterOS 6.45.7, KVM-ben, 2 vCPU (X5650), 1 GB RAM. Az egyik routernek csak 1 GBit-es uplinkje van.

IPIP tunnel titkosítás nélkül:

              status: done
      time-remaining: 0s
    ping-min-avg-max: 1.07ms / 1.30ms / 1.76ms
  jitter-min-avg-max: 0s / 81us / 477us
                loss: 0% (0/200)
        tcp-download: 928Mbps local-cpu-load:75%
          tcp-upload: 929Mbps local-cpu-load:67% remote-cpu-load:77%
        udp-download: 955Mbps local-cpu-load:34% remote-cpu-load:24%
          udp-upload: 962Mbps local-cpu-load:30% remote-cpu-load:59%

Kikapcsolt fast-path-val titkosítás nélkül:

              status: done
      time-remaining: 0s
    ping-min-avg-max: 1.06ms / 1.27ms / 1.47ms
  jitter-min-avg-max: 0s / 78us / 270us
                loss: 0% (0/200)
        tcp-download: 924Mbps local-cpu-load:77%
          tcp-upload: 929Mbps local-cpu-load:62% remote-cpu-load:78%
        udp-download: 953Mbps local-cpu-load:37% remote-cpu-load:27%
          udp-upload: 962Mbps local-cpu-load:36% remote-cpu-load:66%

Bekapcsolt IPSec-vel:

              status: done
      time-remaining: 0s
    ping-min-avg-max: 1ms / 1.26ms / 1.64ms
  jitter-min-avg-max: 0s / 88us / 353us
                loss: 0% (0/200)
        tcp-download: 404Mbps local-cpu-load:68%
          tcp-upload: 386Mbps local-cpu-load:55% remote-cpu-load:75%
        udp-download: 589Mbps local-cpu-load:40% remote-cpu-load:53%
          udp-upload: 600Mbps local-cpu-load:54% remote-cpu-load:58%

Iroda felé az 1 GBipes uplinkes routerről (60/10-es internet van), ahol hEX PoE van lerakva routerként:

IPsec bekapcsolva:

                  ;;; results can be limited by cpu, note that traffic generation/termination performance might 
                      not be representative of forwarding performance
              status: done
      time-remaining: 0s
    ping-min-avg-max: 11.9ms / 13.4ms / 17.3ms
  jitter-min-avg-max: 2us / 516us / 4.24ms
                loss: 0% (0/200)
        tcp-download: 9.21Mbps local-cpu-load:3%
          tcp-upload: 24.2Mbps local-cpu-load:6% remote-cpu-load:99%
        udp-download: 9.50Mbps local-cpu-load:3% remote-cpu-load:37%
          udp-upload: 32.8Mbps local-cpu-load:7% remote-cpu-load:100%

IPsec kikapcsolva:

              status: done
      time-remaining: 0s
    ping-min-avg-max: 11.2ms / 13.4ms / 21.2ms
  jitter-min-avg-max: 3us / 790us / 8.74ms
                loss: 0% (0/200)
        tcp-download: 9.55Mbps local-cpu-load:4%
          tcp-upload: 58.8Mbps local-cpu-load:9% remote-cpu-load:67%
        udp-download: 9.87Mbps local-cpu-load:1% remote-cpu-load:5%
          udp-upload: 60.6Mbps local-cpu-load:2% remote-cpu-load:14%

Domain, tárhely és webes megoldások: aWh

( lcsaszar v | 2019. 11. 12., k – 19:02 )

A nem titkosított (nem IPSec) tunnel nem véd a Man-in-the-Middle támadás ellen.

Én mondjuk pályafutásom során elég kevés olyan helyet (beleértve a bankokat és nagyvállalatokat) láttam, ahol nem lehetett könnyedén MitM támadást végrehajtani, mert:

- SSH host kulcsok nem voltak dokumentálva, sőt upgrade során random cserélődhettek

- HTTPS esetén self signed certek, vagy csak simán IP-vel használva.

- lejárt, és/vagy rossz névre szóló tanúsítványok, és úgy általában totál csőd PKI szinten.

- ősrégi telefonos appok, ezeréve elavult "titkosítással" mentek,

- menet közben csak kiderültek olyanok, mint jaaa:

  * az FTP-n megy, és kurva fontos.

  * az egy direkt adatbázis kapcsolat, a vastag kliensek miatt,

  * az xy vackok management interface-ei is "látszódnak"

  * az NFS v3-at használ.

  * de az "out of scope" :)

  * az csak egy teszt rendszer

  * azt épp leszereljük

  * stb

de persze a fejlesztő már nem elérhető, (vagy csak simán nincs rá pénz) nem lehet változtatni

 

 

És akkor még az olyan bugokról nem is beszéltünk, amik az egyes protokolok titkosítását érintették, mint:

 

Szóval elméletben, egy optimális világban :igen "felesleges" a + titkosítási réteg.

Gyakorlatban viszont bizony van értelme, és hozzáad(hat) a teljes megoldásod biztonságához.

 

szerintem.

zrubi.hu

( juhasz.jozsef | 2019. 11. 13., sze – 09:50 )

Én tennék titkosítást a tunnelre is, mivel akkor a DNS kéréseid valamint a routing információk is védve lennének...

A DNS kéréseket a helyi router szolgálja ki, ilyesmi semmikép nem menne a tunelen. A routing információ alatt mit értesz? Sajnos a teszt azt mutatja, hogy jelentős sebesség csökkenést kellene elszenvedni a titkosítás miatt.

Domain, tárhely és webes megoldások: aWh

( zither | 2019. 11. 13., sze – 22:52 )

Ha nem akarod a világnak kihirdetni a belső infrastruktúrádat, akkor hasznos lehet. Titkosítás nélkül lehallgatható a két telep közötti forgalom, illetve mitm támadással injektálható a belső hálózatodba csomag. Persze, ha eleve egy honeypot a végcél, akkor nem szóltam.

Zavard össze a világot: mosolyogj hétfőn.