A palesztin fura egy nép, állandóan piszkálják a békés Izraelt, pedig ez utóbbiak még a saját területükre is beengedik néha őket. Checkpointokon keresztül.

De mi is az a Check Point? Egy izraeli cég, amely tűzfalakat gyárt. Olyanokat, amelyek jól megvizsgálják a rajtuk áthaladó csomagokat, és ha úgy gondolják, nem engedik őket tovább.

Sokan abban a hitben élnek, hogy a biztonsági cégek aztán húdenagyon ott vannak a szeren, álmukból felkeltve mormolják az RFC-ket, meg hibátlan szoftvereket írnak. Hát nem. CP-ék tűzfala egy rakás protokollt ért, amely azt jelenti, hogy ha ez a funkció be van kapcsolva, belenéz a csomagba, és azt mélyen értelmezi (deep inspection). Néha olyan mélyre süllyed, hogy nem csak értelmezi, de módosítja is azt. Egy ilyen esetről lesz most szó.

Bent ülünk tehát a gépteremben a szerverünkkel, amely unottan bámulja az izraeli nagy falat a maga négy méter magas szürke pompájában. Néha azonban ennél többre is szükség van, beszélni kéne a külvilággal, most éppen a zsidó területen át. Küldünk tehát egy DNS kérést, olyan palesztinosat.

A tűzfal tehát gyanúsan tekint a csomagunkra, kibontás előtt egy nagy téren harckocsival palacsinta vastagságúra nyújtja (hátha bomba), kemencében kisüti (hátha vegyi fegyver), sterilizálja, majd miután atomjaira hullott, a lényeget kiszedi belőle, majd újból összerakja, és ha megfelelőnek találja, átküldi a héber oldalra.

Mit lehet a DNS csomagokkal csinálni? Például randomizálni a forrásportot, és a tranzakciós azonosítót. Tűzfalunk ezt elvégzi, közben pedig még egy NAT-ot is csinál.

A csomag kimegy, majd rövidesen visszajön a válasz. Minek is kellene történnie? Hát a tranzakció-azonosítónak, a most már célportnak és IP-nek a tűzfal állapottáblája szerint vissza kellene változnia az eredeti értékekre, hogy a host felismerje, hogy a kérésére jött a válasz.

Mi történik valójában? Jön egy format erroros DNS válasz, ráadásul rossz tranzakciós azonosítóval, amelyet így a host resolvere automatikusan eldob.

Mindez csak bizonyos célpontoknál fordul elő, jellemzően azoknál, amelyeket a főnökség hirtelen és überfontosan el akar érni. Persze a fentiek miatt nem megy.

Rövid debugolás után a megoldás a tűzfal DNS scramblingjának kikapcsolása, miután minden rendben működik.

Összefoglalva tehát a szopást:

  • DNS scramblingnál a Check Point néha elkefél valamit a kimenő DNS csomagokban, és emiatt némely névszerver format errort dob vissza
  • az idióta tűzfala ilyen esetekben elfelejti visszacserélni a TXN ID-t, így a host (alkalmazás szinten) észre sem veszi, hogy jött válasz, így legfeljebb timeout hibát tud a képünkbe dobni
  • mellesleg ha poolos NAT van, a csoffadt tűzfal a forrásport randomizáció helyett szekvenciálissá alakítja őket, azaz ahelyett, hogy segítene, ront a biztonságon

A bejegyzés trackback címe:

https://suckit.blog.hu/api/trackback/id/tr221154043

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

yeo 2009.06.08. 19:18:07

melyik verzió ? remélem azért NGX R60 feletti:) hogy kicsit megvédjem a csekkpojntot:

A scramblinget igazából a a gateway mögötti DNS szerverek védelmére találták ki, gondolom viszont az SD profile-t az összes DNS forgalomra ráhúztátok, ami néha gáz tud lenni. Javaslom inkább definiáljátok a saját DNS szervereiteket és arra assignoljátok a profilt. Ha van ilyen.

Még egyvalami, az is lehet hogy a delete_on_reply kavart be, mégpedig a resolver baszott randomizálni és több queryt is azonos porton küldött ki, namármost az első replynál a tűzfal kitörölte a connectiont a táblából mondván a reply megjött, viszont a te resolvered még lehet hogy várt x másik tranzakcióra.

Bár csak tipp, mivel irtad hogy debuggoltál sokkal több infod van mint amit leírtál:-)
süti beállítások módosítása