Домэйны IP солих туршлага

Хэд хоногийн өмнө www.xyyp.mn вэб маань байрлаж буй серверийг Magicnet дээрээс Gemnet рүү зөөсөн юм. Мэдээж серверийн IP хаяг солигдоно, тэгээд www.xyyp.mn болон бусад туслах домэйнуудыг өөрчлөх хэрэгтэй болов. Харин яаж зогсолт багатай буюу бараг байхгүй, хэрэглэгчдэд анзаарагдахгүй хийх талаар жаал туршлага судалсан, өөрөө хэрэгжүүлсэн туршлагаас хуваалцах гэсэн юм.

Домэйний асуудлууд...

Сервер дээр үйлчилгээ хийхтэй холбоотой хийсэн нэг зүйл бол домэйн нэр. Домэйн домэйндээ компаний маань үндсэн сервер болох ns1.adsolux.com-ийн байрлах хаягийг солив. Залхуугаас бас илүү найдвартай байх үүднээс adsolux.com-ийг GoDaddy дээрээс удирдан зохион байгуулахаар шийдсэн минь өнөөдөр томоохон асуудалд унагав.

DNS нь интернэтийн тулгуур үйлчилгээний нэг бөгөөд тархсан байдалтай зохион байгуулагдсан байдаг. Өөрөөр хэлбэл аль нэг төвлөрсөн систем бүхнийг хариуцах биш, маш олон серверүүд өөрийн гэсэн домэйнүүдийг хариуцан ажиллуулж байдаг. Ингэхдээ NS төрлийн бичлэгийг ашиглах бөгөөд жишээ нь dulmandakh.com домэйнийг аль сервер хариуцдагийг үзэхийн тулд dig dulmandakh.com NS гэсэн командыг ашиглана. Та ямар нэг вэб үзэхээр домэйн нэрийг бичихэд таны тооцоолуураас хүсэлт гараад тохируулсан байгаа домэйн серверт очно. Хүсэлтийг хүлээж авсан сервер маань юуны өмнө домэйнийг хариуцан ажилладаг серверийг олно, олсныхоо дараа тухайн серверээс хариуг аваад түр хугацаанд өөр дээрээ хадгалж аваад (cache) танд эргээд хариуг нь өгснөөр та вэбийг үзэх боломжтой болж байгаа юм. Зүгээр хадгалаад авчихгүй SOA бичлэг дээрх зүйлсийг харгалзан үзнэ. SOA бичлэг дээр тухайн утгуудыг хэр удаан хадгалахаас эхлээд асуудал гарвал хэнтэй холбоо барих зэрэг олон мэдээлэл байна. Гэвч serial буюу цувралын дугаар бас их чухал. Хэрэв та домэйний аль нэг бичлэгт өөрчлөлт хийсэн бол цувралын дугаарыг ямар нэг байдлаар өөрчлөх хэрэгтэй. Энэ нь домэйний бичлэг өөрчлөгдсөн шүү, хадгалагдаж буй бичлэг чинь хуучирсан байна шүү гэсэн дохиог бусад серверүүдэд өгнө. Өөрчлөхгүй бол домэйнд өөрчлөлт орсныг бусад серверүүд мэдэж чадахгүй гэдгийг анхаараарай.

Гэтэл GoDaddy дээр байгаа домэйнд өөрчлөлт оруулсан чинь цувралын дугаар нь өөрчлөгдөхгүй юм. Үүнээс болоод бусад серверүүд манай хуучин хаяг өөрчлөгдсөн талаар мэдэхгүй, хуучин хаягийг нь тэр чигээр нь хадгалаад асуудал үүсгэсэн байх юм. Бичлэгийн утгыг сольж үзлээ, бичлэг нэмж бас устгаж үзлээ. Нэмэр алга. Тэдний техникийн алба руу нь мэдэгдчихээд одоо хариу хүлээж сууна. Энэ хоорондоо ахиж асуудал гаргахгүйн тулд шинэ болон хуучин хаяг дээр нь давхар ажиллуулж байх шив дээ. Домэйн ч бас ярвигтай эд шүү...

Responsible disclosure

Өнөөдөрхөн хэн нэгний үлдээсэн сэтгэгдэл миний эмзэглэж явдаг нэг зүйлийг хөндөж орхив. Энэ нь responsible disclosure буюу хариуцлагатайгаар мэдээллийг задлах тухай асуудал юм. Хэрэв та нэг програм хангамжид эсвэл системд аюулгүй байдлын алдаа эсвэл цоорхой илрүүлбэл яах ёстой вэ? Ер нь энэ тухай нь мэдэгдэх хэрэгтэй юу эсвэл нууцлах ёстой юу? Хэрэв мэдэгдэхээр бол яаж мэдэгдэх вэ? Хэрэв мэдэгдвэл та гэмт хэрэгтэн болохгүй байгаа? Энэ мэт асуултууд миний болон бусад аюулгүй байдлыг чухалд тооцдог хүмүүсийн санааг ихээр чилээдэг нь харагддаг.

Ажиглаад байхад аюулгүй байдлын мэдээллийг хэрхэн ил болгох талаар шилдэг гэх (дэлхийн) аюулгүй байдлын мэргэжилтнүүд олон янзын үзэл баримтлалтай байх ч бараг бүгд "responsible disclosure" байх хэрэгтэй гэж үздэг. Нэг жишээ авъя л даа. Сүүлд бидний мэдэх нөгөө нэг ноцтой DNS цоорхойг Dan Kaminsky гэх залуу илрүүлсэн. Тэрээр цоорхойг үнэхээр байгаа эсэхийг баттай мэдэж авсныхаа дараагаар шууд програм хангамж үйлдвэрлэгч компаниуд руу холбоо тогтоож цоорхойн талаар мэдээллэсэн. Засвар гарсан. Бүр сүүлд нь олон нийтэд зарласан. Хэрэв тэрээр илрүүлмэгцээ сэтгэл хөдлөлдөө автаад ч юм уу цоорхойн талаар олон нийтэд зарласан бол өнөөдөр юу болох байсныг хэн ч мэдэхгүй. Цоорхой засагдаагүй байна, янз бүрийн хүмүүс цоорхойн талаар мэдээлэлтэй болно, зарим нэг атгаг санаатан нь буруугаар ашиглана. Хэрэв Dan атгаг санаатан байсан бол цоорхойн талаар мэдээллийг дарж, өөрийн хорт үйл ажиллагаандаа ашиглах боломжтой байсан. Гэвч зөвхөн Dan үүнийг илрүүлж чадна гэсэн үг биш, маш олон авъяаслаг мэргэжилтнүүд байгаа. Яг үнэндээ энэ цоорхой бусдын адилаар санамсаргүй байдлаар л илэрсэн шүү дээ. Энэ бол ямар нэг хууль эрх зүйгээр биш харин ёс зүйгээр зохицуулагдаж хэвшсэн зүйл. Үүнд бас нэг дутагдал байдаг нь хэрэв компани мэдчихээд засвар хийхдээ хойрго хандвал яах вэ гэдэг асуудал. Зарим нэг компаниуд цоорхойг мэдчихээд хэдэн сар жилээр засахгүй явдаг, сонгодог жишээ нь Microsoft. Бас заримдаа програм хангамж үйлдвэрлэгчид мэдэгдэхгүй, эсвэл засвар гарахаас өмнө олонд мэдээлэх, цоорхойг ашиглах тохиолдол гардаг ба үүнийг zero day гэж нэрлэдэг.

Манай нөхцөлд яах вэ? Миний бодлоор бид "responsible disclosure" зарчмыг мөрдөх нь илүү оновчтой мэт санагддаг. Би өөрөө ч ямар нэг асуудал олвол түүнийгээ бататгаад, дараа нь түүнийг мэдээлэх, засварлах тал дээр хамтран ажиллахыг эрмэлздэг. Зарим тохиолдолд тухайн компанитай хэрхэн холбоо барих, тэр компани нь аюулгүй байдлын талаар ямар бодлоготой талаар мэдээлэл олох бараг боломжгүй байдаг. Жишээ нь, бидний сайн мэдэх Google компани өөрийн гэсэн аюулгүй байдлын бодлоготой бөгөөд түүнийгээ олон нийтэд нээлттэй байлгадаг. Үүндээ хэрхэн холбоо барих талаар маш ойлгомжтой оруулж өгсөн байдаг. Болдог бол манайхан ийм зүйлтэй болмоор байгаа юм. Бас дээрээс нь цоорхой илрүүлсэн хүний хөдөлмөрийг үнэлдэг, урамшуулдаг систем маш чухал. Эцэст нь манайхны аль дээрээс дуншаад байгаа CERT гэдэг байгууллага нь байгуулагдаад, ном журмынхаа дагуу үйл ажиллагаагаа явуулаад, мэдээллийн аюулгүй байдлын талаар олон нийтэд таниулах, мэргэжилтнүүдэд сургалт, зөвлөлгөө өгөх ажлаа хурдан эхлүүлчихвэл ч манай мэдээллийн аюулгүй байдлын асуудал арай өөр түвшинд гарах болов уу гэж найдах юм.

BIND дээр анхаарах зүйлс

Манай админууд DNS цоорхойн талаар нэлээн сайн мэдээлэлтэй байгаа бололтой бас тэгээд ихэнх нь сүүлийн шинэчлэлийг суулгасан гэдэгт итгэж байна. Зарим нэг үйл ойлголцох асуудлууд байгаа тул өөрийн хэмжээгээр багахан тайлбар өгөхийг хичээлээ.

Юуны өмнө сүүлд илэрсэн цоорхойг BIND-ын 9.2.8-P1, 9.3.4-P1, 9.4.1-P1 болон 9.5.0-P2 хувилбарууд дээр тус тус зассан байна. Та өөрийн сервер дээр ажиллаж байгаа хувилбарыг шалгахдаа named -v тушаалыг ашиглаарай. Хэрэв та эдгээр болон түүнээс хойшхи хувилбаруудыг ашигладаг бол "нөгөө" цоорхой засагдсан гэдэгт итгэж болно. Жишээ нь, миний нэг ашигладаг Ubuntu дээр BIND 9.4.2-P1 гэж харуулж байна, өөрөөр хэлбэл шинэчлэлтийг хийсэн гэсэн үг. Бас нэг FreeBSD дээр BIND 9.4.2 гэж гарч байна, гэхдээ сүүлд би энд байгаа зааврын дагуу засварыг нь хийсэн болохоор гайгүй байх. Гэхдээ ихэнх юникс болон линукс тархацууд нь нэгэнт гаргасан хувилбартаа аюулгүй байдлын засвар хийхээс шинэ боломж болон шинэлэг хувилбарыг оруулдаггүй. Тийм болохоор ихэнх тохиолдолд хуучин хувилбар дээр нь аюулгүй байдлын засварыг нь оруулаад хувилбарыг өсгөдөггүй. Үүнээс болж хуучин хувилбар харуулж болох ч хэрэв таны линукс тархац цоорхойг зассан талаар мэдэгдэл гаргасан бас та хамгийн сүүлийн шинэчлэлтүүдийг суулгасан бол бас санаа амар байж болно.

Бас нэг тохиргооны асуудал байгаа нь, хэрэв та query-source address * port 53; гэсэн тохиргоог идэвхижүүлсэн бол таных хэддүгээр хувилбар ч бай халдлагад өртөх бүрэн боломжтой. Учир нь халдлагаас сэргийлэх зорилготой системийг нь та дээрх тохиргоогоор хааж орхисонтой холбоотой. Миний хувьд гэвэл би PowerDNS гээд програмыг MySQL-тэй хослуулан хэрэглэдэг ба PowerDNS-д маань цоорхой илрээгүй. За амжилт залуусаа.

DNS хадлагууд нэмэгдэж байна

Шуугиан дэгдээсээр байгаа DNS-ийн маань цоорхой жинхэнэ утгаараа ашиглагдаж, энэ нь улам бүр нэмэгдэх шинжтэй байгаа талаар аюулгүй байдлын мэргэжилтнүүд энд бас энд мэдээлсэн байна. Хэдийгээр сүүлд Kaminsky-ийн илрүүлсэн цоорхойг ихэнх томоохон компаниуд зассан боловч ихэнх серверүүд огт шинэчлэлт хийгээгүй байна гэсэн судалгаа гарсан байна лээ. Бас засвар орсон гээд байгаа BIND програмын хамгийн сүүлийн хувилбар дээрч cache poisoning халдлага хийж болж байгаа талаар мэдээлэл цацагдаад байна. Хэдийгээр нэг цоорхойг нь зассан боловч DNS маань дизайны хувьд алдаатай байгаа болохоор одоогийн байдлаар дээрх төрлийн халдлагаас бүрэн хамгаалах шийдэл олдоогүй байгаа бололтой. Сүүлд авсан мэдээгээр Мобинэт лав засвар оруулсан, Мэйжикнэт засвар хийж байгаа гэсэн мэдээлэл авсан. Харин бусадтай нь төдийлөн харилцаа байхгүй тул одоогоор мэдээлэл алга.

DNS-ийн алдаа ба сэтгэл зовинол

Энэ бүхэн хагас жилийн өмнө Dan Kaminsky гэх аюулгүй байдлын мэргэжилтэн санамсаргүй байдлаар DNS сервер дээр cache poisoning төрлийн халдлагыг хялбар бөгөөд үр дүнтэй хийх арга олсон тэр цагаас эхэлсэн. Мань нөхөр эхлээд өөртөө төдийлөн итгээгүй бас ийм амархан байна гэж санаагүй юм шиг байгаам. Үүнийхээ дараагаар хэдэн аюулгүй байдлыг мэргэжилтнүүдтэй зөвлөлдөж, жинхэнэ халдлага хийж болох эсэхийг шалгасныхаа дараагаар энэхүү цоорхой нь ямар их хор хохирол авчирч болохыг олгоод DNS серверийн програм хийдэг томоохон компаниудтай уулзалт зохион байгуулсан. Дүнд нь алдааны талаар олонд зарлагдаагүй байхад тэдгээр компаниуд сар гаруйн өмнө програм хангамжиндаа засвар оруулж, түгээх сүлжээгээрээ тараасан. Томоохон програм хангамжийн компаниудын засварыг хийснийхаа дараахан тэрээр хэвлэлийн бага хурал хийлгэж ноцтой алдаа илрүүлсэн, засагдсан болохыг зарласан. Мөн Black Hat дээр цоорхойн талаар дэлгэрэнгүй мэдээллийг задлахаа ч нуусангүй. Харин бусад аюулгүй байдлыг мэргэжилтнүүд энэхүү алдаа чухам юу байв, хэрхэн хадлага үйлдэх гэх мэт техникийн асуудлуудаас гадна цоорхойны талаар мэдээллийг ийнхүү нуух нь зүйд хэр нийцэх гээд ёс зүйн асуудлуудыг хүртэл хөндөөд амжив. Зарим хүмүүс ийнхүү нууцлаж байгаад програм хангамжийн компаниудаас засуулсны дараа задлах нь зөв, ингэснээр их хэмжээний хор хохирол учрахгүй гэж үзэж байхад ингэж нуух нь хүмүүсийг төөрөгдөл, хүлээлтэнд оруулж энэ хойгуур нь атгаг санаатнууд энэхүү цоорхойг аль хэдийнээ мэдээд ашиглах боломжтой гэж зарим хэсэг нь үзэж байх юм. Аль алинд нь сайн болоод сул тал бий. Аюулгүй байдлыг мэргэжилтнүүд цоорхойн талаар илүү ихийг мэдэхээр эрэлхийлж байх хойгуур нэгэн reverse engineering-ийн мэргэжилтэн хийгдсэн засварыг задалж, тайлж уншсанаар энэхүү оньсого мэт цоорхойн талаар дэлгэрэнгүй мэдээлэл олон нийтэд цацагдав. Ингээд Dan Kaminsky үнэнээ хүлээж, цоорхойн талаар мэдээллийг олон нийтэд цацав.

Энэ яг ямар алдаа байв? DNS буюу домэйн нь бид ойлгож, цээжлэхэд хялбар www.dulmandakh.com гэж интернэтийн хаягийг компьютерт ойлгогдох 202.131.4.20 гэсэн IP хаяг руу хөрвүүлдэг систем юм. Өөрөөр хэлбэл интернэт хэрэглэгчид өөрийн мэдэлгүй алхам тутамдаа ашиглаж байдаг юм. Харин эдгээр домэйн нэр нь маш олон домэйн серверт тархан байрласан байдаг ба асуусан домэйн нь аль нэг серверт байхгүй бол бусад серверүүдээсээ хайн олоод тухайн хариултыг тодорхой хугацаагаар өөрт хадгалж байдаг. Өөрөөр хэлбэл бид компьютер дээрээ домэйн серверээ 202.131.0.10 гэж тохируулсан байсан бол энэхүү сервер маань надад хэрэгтэй мэдээллийг олох хүртлээ хайж олоод, дараа ахин хайхгүйн тулд тодорхой хугацаанд өөр дээрээ хадгалдаг буюу cache хийдэг. Харин dns cache poisoning халдлагыг гол зорилго нь тэрхүү сервер дээр түр хадгалагдсан байгаа мэдээллийг өөрчлөх, хордуулах замаар www.dulmandakh.com руу орох гэсэн хүнийг шал өөр сервер, вэб руу оруулахад оршино. Өөрөөр хэлбэл та өөрийн банкны вэб рүү нэвтрээд нууц үгээ хийж байна гэж бодож байхад үнэн хэрэгтээ шал өөр "хорт санаатны" вэб рүү орчихсон өөрийн санхүүгийн мэдээллээ алдаж байх аюултай юм. Сүүлд илэрсэн алдаа нь энэхүү ажиллагааг маш хялбархан, бас илүү үр дүнтэй хийх боломжийг олгож байснаас гадна зөвхөн аль нэг компаний програм хангамжийн бүтээгдэхүүнд бус маш олон програм хангамжийн бүтээгдэхүүнд илэрсэн нь томоохон аюул дагуулж байсан юм. Бидний мэдэх ISC Bind, Microsoft DNS, Cisco гээд бүгд л алдаатай, засвар хийсэн. Өөрөөр хэлбэл интернэтийн бараг бүх хэрэглэгчдэд аюул учирч байгаа юм. Бараг гэж хэлдэг нь djb dns, powerdns гэх програм хангамжууд өртөөгүй.

DNS cache poisoning гэдэг алдаа цоо шинэ эд биш. Энэ талаар өмнө нь хүмүүс ярьдаг, бичдэг, ижил төрлийн алдааг илрүүлж, засч л байсан. Гэхдээ энэ төрлийн алдаанаас хэрхэн сэргийлж болох талаар бидний сайн мэдэх qmail програмын зохиогч D. J. Bernstein олж нээгээд өөрийн djbdns програмд хэрэгжүүлсэ байдаг. Харин энэхүү djbdns нь сүүлд илэрсэн цоорхойд өртөөгүй. Үүнээс үүдэн олон асуулт, асуудлууд урган гарсан. Бид алдааг илэрхлээр нь тухай бүрт нь засч байх уу? Эсвэл дизайны алдааг илрүүлж, үүнээс болж гарсан болон цаашид гарах цоорхойнуудаас сэргийлж байх уу? Хэрэв Bernstein-ы зөвлөлгөөг дагасан бол өнөөдөр ийм хүнд нөхцөл үүсэхгүй л байсан байх.

Хамгийн сонирхолтой нь энэхүү алдааны талаар цуурхал бас засвар нь гараад сар гаран болсон, ямар их аюул дагуулж болох талаар бүгд мэдээд долоо хоног гаран болсон. Энэ хугацаанд бүр Metaspoit дээрх exploit буюу халдлага үйлдэх програм нь гарчихаад байхад монголын ихэнх интернэтийн үйлчилгээ үзүүлдэг компаниуд програмаа шинэчлээгүй байгаа нь гайхалтай. Өөрөөр хэлбэл та үнэхээр өөрийн үзэх гэсэн вэбээ үзэж байгаа юу гэдэг сонин асуулт урган гарч байна. Энэ мэт олныг хамарсан алдааг илүү богино хугацаанд засварлах, аюулыг эдгээр хариуцлагатай хүмүүст таниулах ажлыг хэрхэн зохион байгуулбал зүгээр вэ? Ямар арга хэмжээ авбал зохих вэ? Энэ асуултын хариуг хамтдаа хайцгаая. Сэтгэгдэл үлдээгээрэй.