Palesztin DNS csomagok, Izrael tűz alatt!
2009.05.30. 23:13
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:
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
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:-)