Дуугүй байя гэсэн ёстой хэл загатнаад байж болдоггүйээ... Уг нь хүмүүсийн хөдөлмөрийг доош нь хиймээргүй л байна, гэхдээ л энэ оны шилдэгүүдийг шалгаруулсан нь гэж IT-д зүтгэдэг хүмүүсийг дэндүү басамжилсан хэрэг болжээ... Номинацууд нь ч гэж үнэн шогийн, тоо нь гүйцэхгүй болохоор нь нэмээд байсан юмуу даа...
Номинацууд:
1. Интернетийн шилдэг үйлчилгээ
2. Холбооны багцийн шилдэг үйлчилгээ
3. МХХТ-н шилдэг сургалт
4. Шилдэг програм хангамж
5. Шилдэг веб
6. Борлуулалтын дараах шилдэг үйлчилгээ
7. МХХТ-н зээлийн шилдэг үйлчилгээ
8. Шилдэг компьютер
9. Шилдэг хэвлэх төхөөрөмж
10. Шилдэг хувилах төхөөрөмж
11. Шилдэг гар утас
12. Хамгийн олон нэр төрлийн цахилгаан бараа борлуулагч
13. Хамгийн олон нэр төрлийн МХХТ-н бүтээгдэхүүн борлуулагч
14. Дэвшилтэт технологийн бүтээгдэхүүнийг анхлан нэвтрүүлэгч
15. МХХТ-н шилдэг реклам
Зээ нэг иймэрхүү, хараад байхад бас ч гэж боломжийн ч юм шиг. Тэгсэн "MXXT-н зээлийн шилдэг үйлчилгээ" гэдгийг ёстой толгой хүлээж авахгүй байна. Зээлийн шилдэг үйлчилгээ нь IT-д одоо ямар хамаа байдын бол доо. Хараад байхад IT гэдгийг computer гэдэг төмөр хайрцагтай холбоотой гэж ойлгоод байх шиг байгаан. Тэрийг худалдаж авахад зээл олгохоор "IT-н шилдэг зээлийн үйлчилгээ" болчдийн байна. За тэгсэн "МХХТ-н шилдэг сургалт" гэдэгт нь "Best төв - компьютерийн анхан шатны сургалт" гэжийнэ. Анхан шатны сургалт гэдэг нь одоо Word, Excel заадаг санагдаад байхын, эсвэл 10 хуруугаар бичихийг ч заадаг билүү... Яадахад Datacom-c зохиосон APNIC-н сургалтыг оруулчихгүй яасан юм бол доо гээд энүүхэндээ ярилцаад амжтал, "өөрөө нэрээ дэмшүүлж тэрнийхээ хойноос гүйж байж шалгардаг" гэнэ гэж тайлбарлацгаах юм.
За тэгээд гадны баахан электрон барааг шалгаруулснаа ард нь компаны нэрийг нь бичиж, албан ёсны гэрээт борлуулагчийг нь хэлж байгаан байхаа. Юуг шалгаруулаад байгааг нь нэг их ойлгосонгүй... Өчигдөрхөн MCS шилдэг брэнд компьютерээр шалгаруулсан Athena-гаа рекламдаад л байна лээ... "MIDAS/Monita-г шалгаруулсан оны шилдэг компьютер" гээд л...
"Интернетийн шилдэг үйлчилгээ", "Холбооны багцийн шилдэг үйлчилгээ", "Шилдэг програм хангамж" гэдэг нь бол чихэнд арай чимэгтэй сонсогдож байна.
Энэ байгууллагаас шалгаруулсан энэ сонголтууд чинь үнэхээр ядмаг юм байна ш дээ. Бид нар үүнээс дээрхэн шалгаруулалт хийчиж чадахгүй гэжүү залуусаа...
Monday, December 25, 2006
RBL гэж юу вэ?
RBL-г тойрсон асуудлуудтай нилээд олон тулгарч байсан, мөн хүмүүс ч нилээд асуудаг тул энэ талаар ярилцъя.
RBL гэж юу вэ? хэрхэн ажиллах вэ?
RBL гэдэг нь Realtime Blackhole List гэсэн үгийн товчлол бөгөөд спам, вирус тарааж буй IP болон домэйн нэрүүдийг бүртгэж байдаг систем юм. Хамгаалалт муутай серверээр spam trap буюу занга тавьж, түүгээр дамжуулан спам, вирус явуулахыг оролдож байгаа IP/домэйнуудыг бүртгээд сууж байна гэсэн үг юм. Ийм төрлийн нийтэд зориулагдсан нилээд олон системүүд байх ба ихэнх нь судалгаа шинжилгээний ажилд зориулагдсан байдаг. Yahoo зэрэг өргөн цар хүрээтэй мэйл системтэй газар гадны зүйлд найдалгүйгээр өөрийн RBL-тэй байх нь бий.
Мэйл серверүүд гаднаас SMTP холболт үүсэх тоолонд RBL-үүдрүү асуулга явуулж шалгана гэсэн үг юм. Хэрэв энэ мэйл серверийн асуусан аль нэг RBL-д тухайн IP бүртгэгдсэн байвал, сервер холболт үүсгэхээс татгалзаж, энэ талаар товч тодорхой хариу өгнө. Аль RBL-үүдээс асуух вэ гэдгийг админ урьдчилж зааж өгсөн байх ба олон найдвартай RBL-с асууснаар спамтай тэмцэж чадна.
RBL-д орсон тохиолдолд ямар шинж тэмдэг илрэх вэ?
Мэдээж мэйл явахгүй буцаж ирэх асуудлууд гарна(яваад таг болно гэсэн үг биш шүү!). Хүлээн авч байгаа талын SMTP мэйл сервер холболт үүсгэхээс татгалзах тул та энэ талаар тодорхой дурдсан мэйлийг хүлээн авах болно.
Миний IP RBL-д орчихсон юм болвуу?
http://www.robtex.com/rbls.html энэ хаягаар орж шалгаж үзээрэй. Хоосон цонхонд IP хаягаа бичээд GO товчин дээр дарна. 100 орчим RBL-д хайлт хийн үр дүнг танд үзүүлэх болно. Улаан мөрүүд гарч ирвэл таны IP тухайн RBL-д бүртгэгдсэн гэсэн үг юм.
Яагаад RBL-д бүртгэгддэг вэ?
Шалтгаан нь: галтхана, router зэрэг сүлжээний төхөөрөмжийн хувьд түүний цаана байгаа NAT хийгдсэн дотоод сүлжээний Windows PC-нүүд вирүстсэний улмааc сүлжээний төхөөрөмжийн гадаад IP-г ашиглан спамдаж байна гэсэн үг юм. Мэйл серверийн хувьд харин та гадны спамыг өөрөөрөө дамжуулж байна гэсэн үг дээ. Энэ нь таны мэйл сервер openrelay маягаар ажиллаж байна(хаа хамаагүй газрын мэйлийг relay хийх буюу дамжуулж байна), эсвэл таны спам/вирус филтер муу байна гэсэн үг юм. Мөн зарим тохиолдолд мэйл серверийн Reverse DNS бичлэг байхгүй бол бусад серверүүд SMTP холболт үүсгэхээс татгалздаг тул Reverse DNS бичлэг хийлгэхээ мартуузай!
Миний галтхана, router, мэйл сервер RBL-д орчиж, одоо яах вэ?
Таны галтхана, эсвэл router-н IP RBL-д оржээ. Мэдээж бүртгэгдсэн RBL-үүдийн бүртгэлээс өөрийн IP-г хасуулах арга хэмжээ авна. Хасах процесс RBL-үүдээс шалтгаалан янз янз байна. Зарим нь онлайн форм бөглүүлээд хялбархан хасчихдаг байхад, зарим нь зохисгүй зүйл хийсэн түвшинээс шалтгаалан мөнгө төлөхийг шаардана. Мөнгө төлөх шаардлагагүй ч нилээд хүнд шаардлага тавьж байж бүртгэлээс хасдаг газрууд байна. Тавигдах шаардлагууд: тухайн галтханаар NAT хийгдэн гарч буй бүх PC-ны вирусыг цэвэрлэх, хэрэв мэйл сервер бол openrelay хийхгүй байх, спам болон вирус филтерээ сайжруулах гэх зэрэг... За би ингэж, тэгэж системээ сайжрууллаа гэж мэйл бичээд хариуг нь хүлээн авах хүртэл 7-10 хоног лав шаардана. Гэтэл мэйл ажиллахгүй доголдоод байдаг...
Яаралтай арга хэмжээ авах шаардлагатай бол галтхана, router-н хувьд IP-г нь солиод хэсэгхэн хугацаанд аргалж болох юм. Харин вирусээ цэвэрлэхгүй бол дахиад л BL-д орно. Хэрэв PC-г хэрэглэж байгаа хүмүүс энэ талаар ямар ч ойлголтгүй, байгууллагa дотроо чанга дүрэм мөрддөггүй бол вирусыг цэвэрлэж дуусна гэж байхгүй. Тиймээс галтханынхаа 25-р портыг хаан, зөвхөн зөвшөөрөгдсөн ганц мэйл серверээр(дээр нь спам/вирус филтер ажиллаж байгаа) мэйл трафикийг дамжуулах арга байж болно. Энэ нь ISP зэрэг үйлчилгээ үзүүлдэг газруудад илүү тохиромжтой.
Мэйл серверийн хувьд IP-г солино гэдэг хүндрэлтэй асуудал, DNS бичлэг шинэчлэгдэхэд дор хаяж нэг өдөр шаардагдах тул тэр хооронд мэйл хүлээн авах боломжгүй болно. Мэйл серверийнхээ спам/вирус филтерийг сайжруулахаас гадна, өөрийн болон гадны RBL-г ашиглах, relay хийх IP Zone, IP хаягуудыг нарийвчлан тогтоож шаардлагагүй бол relay хийхгүй байх нь хамгийн үр дүнтэй болохыг анхаараарай.
RBL гэж юу вэ? хэрхэн ажиллах вэ?
RBL гэдэг нь Realtime Blackhole List гэсэн үгийн товчлол бөгөөд спам, вирус тарааж буй IP болон домэйн нэрүүдийг бүртгэж байдаг систем юм. Хамгаалалт муутай серверээр spam trap буюу занга тавьж, түүгээр дамжуулан спам, вирус явуулахыг оролдож байгаа IP/домэйнуудыг бүртгээд сууж байна гэсэн үг юм. Ийм төрлийн нийтэд зориулагдсан нилээд олон системүүд байх ба ихэнх нь судалгаа шинжилгээний ажилд зориулагдсан байдаг. Yahoo зэрэг өргөн цар хүрээтэй мэйл системтэй газар гадны зүйлд найдалгүйгээр өөрийн RBL-тэй байх нь бий.
Мэйл серверүүд гаднаас SMTP холболт үүсэх тоолонд RBL-үүдрүү асуулга явуулж шалгана гэсэн үг юм. Хэрэв энэ мэйл серверийн асуусан аль нэг RBL-д тухайн IP бүртгэгдсэн байвал, сервер холболт үүсгэхээс татгалзаж, энэ талаар товч тодорхой хариу өгнө. Аль RBL-үүдээс асуух вэ гэдгийг админ урьдчилж зааж өгсөн байх ба олон найдвартай RBL-с асууснаар спамтай тэмцэж чадна.
RBL-д орсон тохиолдолд ямар шинж тэмдэг илрэх вэ?
Мэдээж мэйл явахгүй буцаж ирэх асуудлууд гарна(яваад таг болно гэсэн үг биш шүү!). Хүлээн авч байгаа талын SMTP мэйл сервер холболт үүсгэхээс татгалзах тул та энэ талаар тодорхой дурдсан мэйлийг хүлээн авах болно.
Миний IP RBL-д орчихсон юм болвуу?
http://www.robtex.com/rbls.html энэ хаягаар орж шалгаж үзээрэй. Хоосон цонхонд IP хаягаа бичээд GO товчин дээр дарна. 100 орчим RBL-д хайлт хийн үр дүнг танд үзүүлэх болно. Улаан мөрүүд гарч ирвэл таны IP тухайн RBL-д бүртгэгдсэн гэсэн үг юм.
Яагаад RBL-д бүртгэгддэг вэ?
Шалтгаан нь: галтхана, router зэрэг сүлжээний төхөөрөмжийн хувьд түүний цаана байгаа NAT хийгдсэн дотоод сүлжээний Windows PC-нүүд вирүстсэний улмааc сүлжээний төхөөрөмжийн гадаад IP-г ашиглан спамдаж байна гэсэн үг юм. Мэйл серверийн хувьд харин та гадны спамыг өөрөөрөө дамжуулж байна гэсэн үг дээ. Энэ нь таны мэйл сервер openrelay маягаар ажиллаж байна(хаа хамаагүй газрын мэйлийг relay хийх буюу дамжуулж байна), эсвэл таны спам/вирус филтер муу байна гэсэн үг юм. Мөн зарим тохиолдолд мэйл серверийн Reverse DNS бичлэг байхгүй бол бусад серверүүд SMTP холболт үүсгэхээс татгалздаг тул Reverse DNS бичлэг хийлгэхээ мартуузай!
Миний галтхана, router, мэйл сервер RBL-д орчиж, одоо яах вэ?
Таны галтхана, эсвэл router-н IP RBL-д оржээ. Мэдээж бүртгэгдсэн RBL-үүдийн бүртгэлээс өөрийн IP-г хасуулах арга хэмжээ авна. Хасах процесс RBL-үүдээс шалтгаалан янз янз байна. Зарим нь онлайн форм бөглүүлээд хялбархан хасчихдаг байхад, зарим нь зохисгүй зүйл хийсэн түвшинээс шалтгаалан мөнгө төлөхийг шаардана. Мөнгө төлөх шаардлагагүй ч нилээд хүнд шаардлага тавьж байж бүртгэлээс хасдаг газрууд байна. Тавигдах шаардлагууд: тухайн галтханаар NAT хийгдэн гарч буй бүх PC-ны вирусыг цэвэрлэх, хэрэв мэйл сервер бол openrelay хийхгүй байх, спам болон вирус филтерээ сайжруулах гэх зэрэг... За би ингэж, тэгэж системээ сайжрууллаа гэж мэйл бичээд хариуг нь хүлээн авах хүртэл 7-10 хоног лав шаардана. Гэтэл мэйл ажиллахгүй доголдоод байдаг...
Яаралтай арга хэмжээ авах шаардлагатай бол галтхана, router-н хувьд IP-г нь солиод хэсэгхэн хугацаанд аргалж болох юм. Харин вирусээ цэвэрлэхгүй бол дахиад л BL-д орно. Хэрэв PC-г хэрэглэж байгаа хүмүүс энэ талаар ямар ч ойлголтгүй, байгууллагa дотроо чанга дүрэм мөрддөггүй бол вирусыг цэвэрлэж дуусна гэж байхгүй. Тиймээс галтханынхаа 25-р портыг хаан, зөвхөн зөвшөөрөгдсөн ганц мэйл серверээр(дээр нь спам/вирус филтер ажиллаж байгаа) мэйл трафикийг дамжуулах арга байж болно. Энэ нь ISP зэрэг үйлчилгээ үзүүлдэг газруудад илүү тохиромжтой.
Мэйл серверийн хувьд IP-г солино гэдэг хүндрэлтэй асуудал, DNS бичлэг шинэчлэгдэхэд дор хаяж нэг өдөр шаардагдах тул тэр хооронд мэйл хүлээн авах боломжгүй болно. Мэйл серверийнхээ спам/вирус филтерийг сайжруулахаас гадна, өөрийн болон гадны RBL-г ашиглах, relay хийх IP Zone, IP хаягуудыг нарийвчлан тогтоож шаардлагагүй бол relay хийхгүй байх нь хамгийн үр дүнтэй болохыг анхаараарай.
Friday, December 22, 2006
UBP 12 сар
Өчигдөр уламжлалт 12-р сарын Unix Beer Party болж өнгөрлөө. Байнга уулздаг газар болох "Их Монгол" шинэ жилийн тарифтаа шилжээд өөр болчиж, ойрхон Dublin гээд газар орцгоолоо. Байнга ирдэг хүмүүсээс Энхбаяр, Номин, Даваасүрэн ирсэн байсан. Шинэ хүмүүс гэвэл ЭМШУИС-с Баянмөнх, Ivanhoe Mines-c Баттөр гээд 2 залуу ирсэн байсан. Дөлөө, Нүүнээ хоёрын холын сониноос сонсохын дээр, шинэ хоёр залуу маань нилээд сонирхолтой яриа өрнүүллээ. Хол явсан хүнээс үг сонс гэдэг дээ, манай хоёр ч их юм сонсож мэдэж ирсэн байна. Явахаасаа өмнө LPI(Linux Professional Institue)-г Монголдоо байгуулна гэж ярьж байсан бол одоо тэр талаараа нилээд ажил хэрэгч төлөвлөгөөтэй байгаа бололтой. Бээжин дэхь LPI-н төвөөр зочилсон хийгээд сургалтынхаа талаар өөрсдөө блог дээрээ бичих байх, тэр үед нь та бүхэн сонсоно биз.
Орчуулгын талаар нилээд ярилцлаа... Мэдээллийн технологын нэр томъёог орчуулах хэрэг байна, байхгүй гэхчлэн нилээд маргалдлаа. FreeBSD Handbook-н орчуулагдсан бүлгүүдээс уншиж, ажилдаа нэмэр болж байгаа талаар Баянмөнх анд маань хэлж байсан нь нилээд урам нэмлээ.
Мөн "IT чиг хандлага" нэрийн дор болох лекцийн талаар, Их Дээд сургуулиудын мэргэжлийн ангийн хичээлийн хөтөлбөрт юникс төрлийн системийг заах талаар, за тэгээд дээрхэн ict.mn mailinglist-р тараагдсан Ерөнхийлөгчөөс эхлээд манай бүх Улсын Их Хурлын гишүүд, Яам Газрын дарга нарын мэйл хаягын жагсаалтын талаар ярилцаж баахан инээлдэв... Учир юув гэхээр миний санаж буйгаар boogii...@yahoo.com гэсэн мэйл хаягтай төрийн нарийн бичгийн дарга байвал яахуу?
Уржигдар болоод өнгөрсөн MIDAS/Monita-с зохион байгуулсан IT-н шинэ жилийн талаар нилээд шүүмжлэнгүй яриа сонслоо. "Электрон бараа шалгаруулдаг IT-н шинэ жил" гэсэн яриа гараад байгаа бололтой шүү хүмүүсээ.
За тэгээд миний хувьд хамгийн сүүлийн UBP-даа оролцоод сэтгэл өндөр байноо. Надад амжилт хүсэж, гаргаж өгсөн хүмүүстээ баярлалаа.
Орчуулгын талаар нилээд ярилцлаа... Мэдээллийн технологын нэр томъёог орчуулах хэрэг байна, байхгүй гэхчлэн нилээд маргалдлаа. FreeBSD Handbook-н орчуулагдсан бүлгүүдээс уншиж, ажилдаа нэмэр болж байгаа талаар Баянмөнх анд маань хэлж байсан нь нилээд урам нэмлээ.
Мөн "IT чиг хандлага" нэрийн дор болох лекцийн талаар, Их Дээд сургуулиудын мэргэжлийн ангийн хичээлийн хөтөлбөрт юникс төрлийн системийг заах талаар, за тэгээд дээрхэн ict.mn mailinglist-р тараагдсан Ерөнхийлөгчөөс эхлээд манай бүх Улсын Их Хурлын гишүүд, Яам Газрын дарга нарын мэйл хаягын жагсаалтын талаар ярилцаж баахан инээлдэв... Учир юув гэхээр миний санаж буйгаар boogii...@yahoo.com гэсэн мэйл хаягтай төрийн нарийн бичгийн дарга байвал яахуу?
Уржигдар болоод өнгөрсөн MIDAS/Monita-с зохион байгуулсан IT-н шинэ жилийн талаар нилээд шүүмжлэнгүй яриа сонслоо. "Электрон бараа шалгаруулдаг IT-н шинэ жил" гэсэн яриа гараад байгаа бололтой шүү хүмүүсээ.
За тэгээд миний хувьд хамгийн сүүлийн UBP-даа оролцоод сэтгэл өндөр байноо. Надад амжилт хүсэж, гаргаж өгсөн хүмүүстээ баярлалаа.
Thursday, December 21, 2006
Locking user accounts
Саяхан MUG-н хэлэлцүүлэг дээр нэг гишүүн хэрэглэгчийн эрхийг яаж түр хугацаанд хаах вэ? гэж асуусан байсан. Түүний хариултыг энд товчхон өгье.
Хэрэглэгчийн эрхийг идэвхгүй болгохын тулд 1-рт түүний нэвтрэх үгийг, 2-рт түүний ажиллах бүрхүүлийг идэвхгүй болгох хэрэгтэй.
Fedora болон Redhat дээр usermod тушаал дээрхийг хоёуланг давхар гүйцэтгэж чадна. Үүний тулд дараах тушаалыг өгнө:
# usermod -L -s /dev/null username
Энэ тушаалыг өгснөөр /etc/passwd файл доторх тухайн хэрэглэгчийн бүрхүүл /bin/bash эсвэл /bin/sh-с /dev/null болон өөрчлөгдөнө. Харин /etc/shadow файл доторх түүний кодлогдсон нэвтрэх үгийн урд "!" тэмдэг нэмэгдсэнээр энэ нэвтрэх үг хүчингүй болж, улмаар энэ хэрэглэгч системд нэвтрэх боломжгүй болно.
Solaris-н хувьд хэрэглэгчийн нэвтрэх үгийг идэвхгүй болгохын тулд:
# passwd -l username
бүрхүүлийг идэвхгүй болгохын тулд:
# passmgmt -m -s /dev/null username
тушаалыг өгнө. Администратор /dev/null-н оронд TITAN-ы noshell програмыг ашиглаж болох юм. noshell програм нь бүх амжилтгүй нэвтрэх оролдогыг syslog-руу бүртгэдэг онцлогтой.
Хэрэглэгчийн эрхийг идэвхгүй болгохын тулд 1-рт түүний нэвтрэх үгийг, 2-рт түүний ажиллах бүрхүүлийг идэвхгүй болгох хэрэгтэй.
Fedora болон Redhat дээр usermod тушаал дээрхийг хоёуланг давхар гүйцэтгэж чадна. Үүний тулд дараах тушаалыг өгнө:
# usermod -L -s /dev/null username
Энэ тушаалыг өгснөөр /etc/passwd файл доторх тухайн хэрэглэгчийн бүрхүүл /bin/bash эсвэл /bin/sh-с /dev/null болон өөрчлөгдөнө. Харин /etc/shadow файл доторх түүний кодлогдсон нэвтрэх үгийн урд "!" тэмдэг нэмэгдсэнээр энэ нэвтрэх үг хүчингүй болж, улмаар энэ хэрэглэгч системд нэвтрэх боломжгүй болно.
Solaris-н хувьд хэрэглэгчийн нэвтрэх үгийг идэвхгүй болгохын тулд:
# passwd -l username
бүрхүүлийг идэвхгүй болгохын тулд:
# passmgmt -m -s /dev/null username
тушаалыг өгнө. Администратор /dev/null-н оронд TITAN-ы noshell програмыг ашиглаж болох юм. noshell програм нь бүх амжилтгүй нэвтрэх оролдогыг syslog-руу бүртгэдэг онцлогтой.
Буцааж сэргээхдээ:
# usermod -U -s /bin/bash username
# passwd -u username
# passmgmt -m -s /bin/bash username
PS: /etc/passwd болон /etc/shadow файлуудыг гараар засаж болохгүй!
Monday, December 11, 2006
Мэдээллийн Технологын орчуулгын талаар ...
Ойрд орчуулгын ажилтай зууралдаад тэрүү энэ асуудлаар дотроо бодож явлаа. Дөлөө энэ талаар блог бичнэ гэж байсан, тэрийгээ бичжээ. Ерөнхий санааг нь гаргасан байна, дээр нь бага сага зүйл нэмье.
MUG-н зүгээс "FreeBSD Гарын Авлага"-г орчуулж эхлээд байгаа билээ. Би хувьдаа энэ орчуулгын ажилд оролцож, нэг бүлгийг нь орчуулж эхлээд байна. Зөвхөн номыг орчуулахаас гадна, Мэдээллийн Технологын нэр томъёог орчуулах ажил давхар явагдаж байгаа болохоор энэ ажил жаахан удаан явж байгаа талтай. Ер нь орчуулга хийнэ гэдэг санасан шиг амархан ажил биш юм байна гэдгийг нилээд ойлгож авсан. Хүмүүст ойлгомжтой байхын дээр, чанартай сайн орчуулга хийхийн тулд их хөдөлмөр шаардана.
Тухайн нэг өгүүлбэрийг орчуулахын тулд эхлээд англи хэлний эх өгүүлбэрийг өмнөх өгүүлбэр, бүлгийн утга санаатай авцалдуулан сайтар ойлгож авна. Өгүүлбэрийг ойлгохын тулд мэдээж мэргэжлийн дадлага туршлага их хэрэгтэй санагдсан. Хичнээн хэл мэддэг байгаад сайн орчуулга хийж чадахгүй... Нэгэнт ойлгож авсан тул монгол өгүүлбэр болгоод буулгачихна. Дараа нь нэр томъёо, үгийн сонголт гэж нилээд том асуудал тулгарнаа... Нэр томъёог орчуулахын тулд англи хэлний тайлбар толь болон тухайн нэр томъёоны мэргэжлийн тайлбарыг уншина. Жишээ нь: "stateful firewall" гэдгийг орчуулах гэж нилээд бодсон. Гаднаас үүссэн холболтууд "state" буюу ямар нэг "төлөв"-т байдаг талаар ойлголттой байсан тул "төлөвт галтхана" гэж орчуулахаар шийдсэн. Мөн "firewall" гэдгийг хоёр үг нийлж нэг шинэ үг үүсгэж байгаа тул "галт хана" биш, "галтхана" гэж бичих нь зүйтэй санагдсан тул нийлүүлж бичиж байгаа... Мөн "source IP address" гэдгийг "эхлэл IP хаяг" гээд эвтэйхэн хэлчихэж болж байхад "destination IP address" гэдгийн destination-д оноочих нэр үг олж чадалгүй "очих IP хаяг" гээд орчуулчихсан байдаг...
Зарим үг яг сайхан таарсан үг олдож байхад, заримыг үнэхээр чадахгүй тул хамгийн дөхөм үгийг сонгож тавих байдлаар одоогийн байдлаар орчуулгаа хийж байна даа. Яваандаа бүх бүлгүүдийг орчуулж дууссаны дараа нэр томъёогоо эргэж нэг харъя гэж g0mb0 ахтай ярилцсан байгаа.
Гэх мэтчилэн орчуулгын талаар нилээд олон асуултууд тулгарсан тул Галаарид гуайн блогоос "Залуу орчуулагчид өгөх зөвлөгөө-1,2"-г уншсаны дараа Мэдээллийн Технологын орчуулгын талаар зөвлөгөө өгөөч гэж гуйсан билээ. Бодвол түүний хариу байх Галаарид гуай шинэ нийлэлдээ IT-н орчуулгын талаар нилээд дурдсан байна лээ. Ер нь мэргэжлийн бус хүмүүс "үг болгоныг орчуулаад яах юм бэ? жишээ нь компьютер гэдгийг орчуулж яахийн, хүн болгон ойлгож байхад" гэсэн байр сууринаас ханддаг. Галаарид ах энэ талаар:
"Түгээмэл бөгөөд тогтвортой нэр томъёо, тухайлбал IT-гийн нэр томъёонуудыг орчуулалгүй хэрэглэх нь аль ч утгаараа зүйтэй байх. Мэргэжлийн нарийн нэр томъёонуудыг орчуулах гэж оролдон орчуулга биш, тайлбар хийчихсэн байх нь олон тохиолддог. Ингэхийн оронд тэр хэвээр нь, зарим тохиолдолд монгол дуудлагаар ашиглаж хэвших нь дээр ч юм шиг..."
гэжээ. Би хувьдаа эхний өгүүлбэртэй 100% санал нийлэхгүй байна. Би хувьдаа:
"...огт шинээр, зохиомлоор үүсгэсэн үгнээс бусдыг орчуулах боломжтой гэж боддог. Энэ салбарт ажилладаг болоод ч тэрүү, ер нь IT-н нэр томъёог орчуулах зайлшгүй шаардлагатай гэж боддог. Яахав орчуулга муу, эсвэл тухайн үг дэндүү тогтвортой байвал хүмүүс хэрэглэхгүй үлдэнэ л биз. Мөн орчуулга шаардаад байгаа үгсийг хүмүүс сайн дураараа янз янзаар орчуулж байгаагаас энэ талын хэлшил зүгширч өгөхгүй байх шиг санагддаг. Стандарт гаргаад хэвшчихвэл бүгд хэрэглээд эхлэнэ гэж боддог. Өөрөө орчуулга хийж байгаа болохоор тэр юмуу монгол үгээ хэрэглээд ирэхээр сэтгэлд ойрхон буугаад байх болсон."
Үнэхээр сүүлийн үед мэргэжлийнхээ нэр томъёог монголоороо хэрэглэх үнэхээр таалагдаад байгаа. Орчуулганд оролцож байгаа Нацаг, дээр чатлахдаа "install" гэдгийн оронд "суулгац" гэж хэрэглэсэн нь надад сайхан санагдсан... Мөн энд жишээ дурдахад "build" гэдгийг би "үүсгэх" гэж орчуулаад байсан бол g0mb0 ах "бүтээх" гэж орчуулсан байсан нь илүү оновчтой санагдаад зассан байгаа.
Юутай ч энэ орчуулгын ажил дуусвал нилээд гайгүй үгсийн сан үүсэх байх гэж найдаж байгаа. IT-гийнхан хэдий завгүй ч орчуулгын ажилд идэвхтэй оролцоно гэж найдаж байгаа шүү.
MUG-н зүгээс "FreeBSD Гарын Авлага"-г орчуулж эхлээд байгаа билээ. Би хувьдаа энэ орчуулгын ажилд оролцож, нэг бүлгийг нь орчуулж эхлээд байна. Зөвхөн номыг орчуулахаас гадна, Мэдээллийн Технологын нэр томъёог орчуулах ажил давхар явагдаж байгаа болохоор энэ ажил жаахан удаан явж байгаа талтай. Ер нь орчуулга хийнэ гэдэг санасан шиг амархан ажил биш юм байна гэдгийг нилээд ойлгож авсан. Хүмүүст ойлгомжтой байхын дээр, чанартай сайн орчуулга хийхийн тулд их хөдөлмөр шаардана.
Тухайн нэг өгүүлбэрийг орчуулахын тулд эхлээд англи хэлний эх өгүүлбэрийг өмнөх өгүүлбэр, бүлгийн утга санаатай авцалдуулан сайтар ойлгож авна. Өгүүлбэрийг ойлгохын тулд мэдээж мэргэжлийн дадлага туршлага их хэрэгтэй санагдсан. Хичнээн хэл мэддэг байгаад сайн орчуулга хийж чадахгүй... Нэгэнт ойлгож авсан тул монгол өгүүлбэр болгоод буулгачихна. Дараа нь нэр томъёо, үгийн сонголт гэж нилээд том асуудал тулгарнаа... Нэр томъёог орчуулахын тулд англи хэлний тайлбар толь болон тухайн нэр томъёоны мэргэжлийн тайлбарыг уншина. Жишээ нь: "stateful firewall" гэдгийг орчуулах гэж нилээд бодсон. Гаднаас үүссэн холболтууд "state" буюу ямар нэг "төлөв"-т байдаг талаар ойлголттой байсан тул "төлөвт галтхана" гэж орчуулахаар шийдсэн. Мөн "firewall" гэдгийг хоёр үг нийлж нэг шинэ үг үүсгэж байгаа тул "галт хана" биш, "галтхана" гэж бичих нь зүйтэй санагдсан тул нийлүүлж бичиж байгаа... Мөн "source IP address" гэдгийг "эхлэл IP хаяг" гээд эвтэйхэн хэлчихэж болж байхад "destination IP address" гэдгийн destination-д оноочих нэр үг олж чадалгүй "очих IP хаяг" гээд орчуулчихсан байдаг...
Зарим үг яг сайхан таарсан үг олдож байхад, заримыг үнэхээр чадахгүй тул хамгийн дөхөм үгийг сонгож тавих байдлаар одоогийн байдлаар орчуулгаа хийж байна даа. Яваандаа бүх бүлгүүдийг орчуулж дууссаны дараа нэр томъёогоо эргэж нэг харъя гэж g0mb0 ахтай ярилцсан байгаа.
Гэх мэтчилэн орчуулгын талаар нилээд олон асуултууд тулгарсан тул Галаарид гуайн блогоос "Залуу орчуулагчид өгөх зөвлөгөө-1,2"-г уншсаны дараа Мэдээллийн Технологын орчуулгын талаар зөвлөгөө өгөөч гэж гуйсан билээ. Бодвол түүний хариу байх Галаарид гуай шинэ нийлэлдээ IT-н орчуулгын талаар нилээд дурдсан байна лээ. Ер нь мэргэжлийн бус хүмүүс "үг болгоныг орчуулаад яах юм бэ? жишээ нь компьютер гэдгийг орчуулж яахийн, хүн болгон ойлгож байхад" гэсэн байр сууринаас ханддаг. Галаарид ах энэ талаар:
"Түгээмэл бөгөөд тогтвортой нэр томъёо, тухайлбал IT-гийн нэр томъёонуудыг орчуулалгүй хэрэглэх нь аль ч утгаараа зүйтэй байх. Мэргэжлийн нарийн нэр томъёонуудыг орчуулах гэж оролдон орчуулга биш, тайлбар хийчихсэн байх нь олон тохиолддог. Ингэхийн оронд тэр хэвээр нь, зарим тохиолдолд монгол дуудлагаар ашиглаж хэвших нь дээр ч юм шиг..."
гэжээ. Би хувьдаа эхний өгүүлбэртэй 100% санал нийлэхгүй байна. Би хувьдаа:
"...огт шинээр, зохиомлоор үүсгэсэн үгнээс бусдыг орчуулах боломжтой гэж боддог. Энэ салбарт ажилладаг болоод ч тэрүү, ер нь IT-н нэр томъёог орчуулах зайлшгүй шаардлагатай гэж боддог. Яахав орчуулга муу, эсвэл тухайн үг дэндүү тогтвортой байвал хүмүүс хэрэглэхгүй үлдэнэ л биз. Мөн орчуулга шаардаад байгаа үгсийг хүмүүс сайн дураараа янз янзаар орчуулж байгаагаас энэ талын хэлшил зүгширч өгөхгүй байх шиг санагддаг. Стандарт гаргаад хэвшчихвэл бүгд хэрэглээд эхлэнэ гэж боддог. Өөрөө орчуулга хийж байгаа болохоор тэр юмуу монгол үгээ хэрэглээд ирэхээр сэтгэлд ойрхон буугаад байх болсон."
Үнэхээр сүүлийн үед мэргэжлийнхээ нэр томъёог монголоороо хэрэглэх үнэхээр таалагдаад байгаа. Орчуулганд оролцож байгаа Нацаг, дээр чатлахдаа "install" гэдгийн оронд "суулгац" гэж хэрэглэсэн нь надад сайхан санагдсан... Мөн энд жишээ дурдахад "build" гэдгийг би "үүсгэх" гэж орчуулаад байсан бол g0mb0 ах "бүтээх" гэж орчуулсан байсан нь илүү оновчтой санагдаад зассан байгаа.
Юутай ч энэ орчуулгын ажил дуусвал нилээд гайгүй үгсийн сан үүсэх байх гэж найдаж байгаа. IT-гийнхан хэдий завгүй ч орчуулгын ажилд идэвхтэй оролцоно гэж найдаж байгаа шүү.
Wednesday, December 06, 2006
Centralized Logging буюу SyslogNG-н талаар товчхон
Central Logging Server буюу Төвлөрсөн Бүртгэлийн Серверийг SyslogNG буюу Syslog New Generation-ий тусламжтай хэрхэн зохион байгуулах талаар товчхон танилцуулъя.
Ач холбогдол: Хүмүүс ийм юм болохгүй байна, тэр нь сонин ажиллаад байна гэхэд миний хэлдэг ганц үг бол "Логоо шалга!". Системийнхээ логыг уншина гэдэг нь өвчтэй хүнээс таны юу өвдөж байна? гэж асуусантай яг адилхан санагддаг. Ихэнх тохиолдолд системийн яг юу нь болохгүй байгаа нь лог дээр дурайтал бичээтэй байдаг. Гэхдээ... лог уншина гэдэг цаг авсан ажил... хэрвээ олон сервертэй бол логыг уншаад дуусна гэж байхгүй юм болно. Тэгэхээр нэг арга зам бол бүх серверүүдийн логыг нэг сервер дээр цуглуулж, түүнийгээ өгөгдлийн баазруу хийгээд түүн дээрээ хайлт шүүлт хийх арга юм. Мэдээж веб интерфэйс байвал бүр сайн хэрэг... Тэгвэл энэ бүхнийг "SyslogNG + MySQL + php-syslog-ng"-н тусламжтай хийж болно.
Ажилллах зарчим: Тэгэхээр бүх логыг цуглуулж байх нэг сервер байна. Түүн дээр SyslogNG, MySQL суусан байх ба веб интерфэйс байдлаар php-syslog-ng ажиллана(мэдээж Apache+PHP суусан байх ёстой).
- Бусад серверүүд(client) логоо энэ серверрүү шиддэг байхаар тохируулагдсан байна.
- SyslogNG TCP/UDP 514-р портон дээр логуудыг хүлээн авч энгийн файлруу эсвэл pipe файлруу SQL Insert query байдлаар бичнэ.
- Бид энэ pipe файлыг аван цааш MySQL баазруу бичнэ.
- Хэрэглэгч php-syslog-ng веб интерфэйсээр бааз дээр хайлт шүүлт хийх боломжтой болох юм.
1. Client машиныг тохируулах
Ер нь бол бүх л сервер машин, сүлжээний төхөөрөмжүүд системийн логыг өөр дээрээ бүртгэж байдаг бөгөөд түүнийгээ syslog гэсэн програмын тусламжтай гүйцэлдүүлж байдаг. Client дээр зарчмын хувьд syslog болон syslog-ng аль нь ажиллаж болно. Гэхдээ syslog-ng-г шинээр суулгаж ажил удаж байснаас бэлэн суучихсан syslog-г ашиглах нь хялбар тул syslog-г хэрхэн тохируулах жишээг харуулав.
Ач холбогдол: Хүмүүс ийм юм болохгүй байна, тэр нь сонин ажиллаад байна гэхэд миний хэлдэг ганц үг бол "Логоо шалга!". Системийнхээ логыг уншина гэдэг нь өвчтэй хүнээс таны юу өвдөж байна? гэж асуусантай яг адилхан санагддаг. Ихэнх тохиолдолд системийн яг юу нь болохгүй байгаа нь лог дээр дурайтал бичээтэй байдаг. Гэхдээ... лог уншина гэдэг цаг авсан ажил... хэрвээ олон сервертэй бол логыг уншаад дуусна гэж байхгүй юм болно. Тэгэхээр нэг арга зам бол бүх серверүүдийн логыг нэг сервер дээр цуглуулж, түүнийгээ өгөгдлийн баазруу хийгээд түүн дээрээ хайлт шүүлт хийх арга юм. Мэдээж веб интерфэйс байвал бүр сайн хэрэг... Тэгвэл энэ бүхнийг "SyslogNG + MySQL + php-syslog-ng"-н тусламжтай хийж болно.
Ажилллах зарчим: Тэгэхээр бүх логыг цуглуулж байх нэг сервер байна. Түүн дээр SyslogNG, MySQL суусан байх ба веб интерфэйс байдлаар php-syslog-ng ажиллана(мэдээж Apache+PHP суусан байх ёстой).
- Бусад серверүүд(client) логоо энэ серверрүү шиддэг байхаар тохируулагдсан байна.
- SyslogNG TCP/UDP 514-р портон дээр логуудыг хүлээн авч энгийн файлруу эсвэл pipe файлруу SQL Insert query байдлаар бичнэ.
- Бид энэ pipe файлыг аван цааш MySQL баазруу бичнэ.
- Хэрэглэгч php-syslog-ng веб интерфэйсээр бааз дээр хайлт шүүлт хийх боломжтой болох юм.
1. Client машиныг тохируулах
Ер нь бол бүх л сервер машин, сүлжээний төхөөрөмжүүд системийн логыг өөр дээрээ бүртгэж байдаг бөгөөд түүнийгээ syslog гэсэн програмын тусламжтай гүйцэлдүүлж байдаг. Client дээр зарчмын хувьд syslog болон syslog-ng аль нь ажиллаж болно. Гэхдээ syslog-ng-г шинээр суулгаж ажил удаж байснаас бэлэн суучихсан syslog-г ашиглах нь хялбар тул syslog-г хэрхэн тохируулах жишээг харуулав.
Жишээ нь: /etc/syslog.conf файл дотор байгаа:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* /var/log/maillog
гэсэн мөрүүдийг:
*.info;mail.none;authpriv.none;cron.none /var/log/messagesauthpriv
*.info;mail.none;authpriv.none;cron.none @xxx.xxx.xxx.xxx
.* /var/log/secure
.* @xxx.xxx.xxx.xxx
mail.* /var/log/maillog
mail.* @xxx.xxx.xxx.xxx
PS: xxx.xxx.xxx.xxx оронд лог цуглуулах серверийн хаягыг бичнэ.
болгон өөрчилнө. Syslog-н level, facility-н талаар болон хэрхэн тохируулах талаар дэлгэрэнгүй мэдээллийг интернетээс аваарай.
2. SyslogNG серверийг суулгах болон тохируулах
Интернетээс нэг аятайхан заавар олсон юм. Энэ нь "Implementation of Central Logging Server using syslog-ng" гээд Энэтхэгийн CERT-с гаргасан гарын авлага байгаан. Syslog-ng серверийг суулгах тохируулах талаар маш дэлгэрэнгүй ойлгомжтой бичсэн байгаа тул энд нуршаад хэрэггүй биз. Та бүхэн
6.1 Installation
6.2 Configuring Server
6.4 Filter syslog messages
хэсгүүдийг уншаарай. Суулгахад libol багцийг заавал суулгах хэрэгтэй болно. Тохируулга хийхийн тулд syslog-ng.conf файлыг шинээр үүсгэх хэрэгтэй байгаа. Мөн хэрэггүй логуудыг шүүж хадгалахын тулд filter{} директивийг ашиглах хэрэгтэй болно. За тэгээд жишээ тохиргооны файлыг харвал бүх юм ойлгогдох байх.
Pipe файлыг дараах байдалтай үүсгэнэ:
# mkfifo /tmp/mysql.pipe
# chmod 660 /tmp/mysql.pipe
Бүх тохиргоог зөв хийсэн бол та логуудыг Insert query байдлаа /tmp/mysql.pipe файд дотор харах болно. Мөн энэ файл томорсоор байх ёстой.
3. pipe файлыг MySQL баазруу бичих
Юуны түрүүнд MySQL сервер дээрээ logs нэртэй өгөгдлийн сан үүсгэх хэрэгтэй. Ямар талбартай үүсгэхийг "Implementation of Central Logging Server using syslog-ng" зааврын 11-р хуудаснаас үзнэ үү.
Үүний дараа дараах командыг өгч pipe файлыг өгөгдлийн санруу оруулах процессыг эхлүүлнэ:
# mysql syslog < /tmp/mysql.pipe &
4. php-syslog-ng ажиллуулах
php-syslog-ng нь энгийн php файлууд тул source tarball-г задлан веб серверийнхээ document root дотор байрлуулна. Үүний дараа эдгээр php скриптээс өгөгдлийн санруу хандах эрхтэй хэрэглэгчийн эрхийг MySQL сервер дээр үүсгэн, нууц үгийн хамт config/config.php файл дотор кодлож өгнө.
Одоо та вебээр хандан admin/admin гэсэн хэрэглэгчийн нэр нууц үгийг оруулан хайлт шүүлтийг хийх боломжтой болно. Бүх зүйл ажиллаж байвал таны лог дараах байдалтай харагдах болвуу.
Та анх удаа логин хийж орсны дараа нууц үгээ солихоо мартуузай. Мөн хязгаарлагдмал эрхтэй өөр хэрэглэгчдийн эрхийг нээж өгөх боломжтой санаарай.
NOTE: syslog-ng-н нэг давуу тал гэвэл UDP-с гадна(syslog зөвхөн UDP протоколыг дэмждэг) TCP протоколыг дэмждэг болсон явдал юм. Ингэснээр галтханын цаана наанаас SSH Tunneling ашиглан логыг аюулгүйгээр бүртгэх боломжтой болдог.
Monday, December 04, 2006
Ubuntu -i hack
Unix төрлийн системүүдийн хамгийн сонгодог хэлбэрийн хайк/hack-н нэг бол "shell escape" буюу бүрхүүлийн цоорхойг ашиглан бага эрхтэй хэрэглэгчээс root бүрхүүлрүү орох явдал юм. Олон арга хэлбэрээр "shell escape" хийж болно. Нэг жишээ бол бүрхүүлийг "-i" тохируулга/option-тайгаар дуудах юм. Өөрөөр хэлбэл "/bin/sh -i" командын тусламжтай "interactive shell"-рүү орох боломжтой. За тийм байдаг байж, тэгээд юу нь тийм сонин байна?... Тэгвэл root эрхтэй бүрхүүлрүү орчихвол асуудал их сонирхолтой болоод ирнэ.
Жишээ нь: test.pl гэсэн setIUD скрипт байлаа гэж бодъё.
% ln -s /home/baynaa/test.pl -i
% -i
#
Гэхдээ энэ hack бүр 1989 онд анх бүртгэгдсэн бөгөөд орчин үеийн Unix систем дээр ажиллахгүй! "-i: Command not found." гэх байх шүү, гэхдээ итгэхгүй байвал туршаад үзээрэй л дээ.
Гэтэл нэг сонин зүйл олж мэдсэн маань гэвэл Ubuntu сервер дээр sudo-тэй хамт "-i" тохируулга ажилладийн байна... ёстой гайхсан. "-i" тохируулгыг иймэрхүү hack-д хэрэглэхээ аль эрт болисон байх гэж бодож байсан. Ubuntu Server дээр:
% sudo -i
#
гэнгүүт шууд л root бүрхүүлрүү орчих юм(гэхдээ мэдээж sudoers дотор идэвхжүүлсэн хэрэглэгчийн хувьд). Redhat, FreeBSD хоёр дээр туршаад үзсэн чинь хоёулан дээр нь "sudo: Illegal option -i" гэж гарч ирж байна.
Жишээ нь: test.pl гэсэн setIUD скрипт байлаа гэж бодъё.
% ln -s /home/baynaa/test.pl -i
% -i
#
Гэхдээ энэ hack бүр 1989 онд анх бүртгэгдсэн бөгөөд орчин үеийн Unix систем дээр ажиллахгүй! "-i: Command not found." гэх байх шүү, гэхдээ итгэхгүй байвал туршаад үзээрэй л дээ.
Гэтэл нэг сонин зүйл олж мэдсэн маань гэвэл Ubuntu сервер дээр sudo-тэй хамт "-i" тохируулга ажилладийн байна... ёстой гайхсан. "-i" тохируулгыг иймэрхүү hack-д хэрэглэхээ аль эрт болисон байх гэж бодож байсан. Ubuntu Server дээр:
% sudo -i
#
гэнгүүт шууд л root бүрхүүлрүү орчих юм(гэхдээ мэдээж sudoers дотор идэвхжүүлсэн хэрэглэгчийн хувьд). Redhat, FreeBSD хоёр дээр туршаад үзсэн чинь хоёулан дээр нь "sudo: Illegal option -i" гэж гарч ирж байна.
Friday, December 01, 2006
lsof командын талаар товчхон
lsof гэдэг нь "LiSt Open Files" гэдгийн товчлол юм. Тэгэхээр нээлттэй файлуудын жагсаалтыг харуулдаг байх нь. good!
Файл гэдэгт юу юу орох вэ? Unix систем дээр бараг бүх зүйлийг файл гэж үзэж болно. Файл бол файл, директор бас нэг төрлийн онцгой файл, төхөөрөмжүүд мөн файл, /proc файлсистемийг аваад үзэх юм бол санах ой, процесс, сүлжээний холболтыг бүгдийг файлаар илэрхийлж болно. Файлыг процессууд хэрэглэх ба ихэвчлэн "нээлттэй" эсвэл "хаалттай" гэсэн хоёрхон төлөвт байдаг. Ер нь бол санах ойд ачаалагдан ажиллаж байгаа ямар нэг процессын хувьд холбогдох хоёртын файл, өгөгдөл эсвэл тохиргооны файлууд, цаашилбал түүнийг ашиглаж буй hardware төхөөрөмж "нээлттэй" төлөвт байна.
lsof-н энэ чадварыг ашиглан системийн хаана ямар үйл явц болж байгааг илрүүлэхэд хялбар болдог. Тиймээс ч lsof-г гадны халдлагыг илрүүлэхэд хэрэглэдэг байна. lsof-н тусламжтай ажиллаж байгаа процессын жагсаалтыг харж болно, үүгээрээ ps-г орлож чадна. Мөн сүлжээний холболтуудыг харж болно, үүгээрээ netstat-г орлож чадна. Дээр нь бид эдгээр процесс болон сүлжээний холболтуудын хэрэглэж байгаа бүх "нээлттэй" файлуудыг харж чадна.
нээлттэй портууд болон үүссэн сесс/session-ууд
-i тугын тусламжтай интернет холболттой холбоотой бүх нээлттэй байгаа файлууд болон "хүлээж байгаа үйлчилгээ"/listening service-н жагсаалтыг харж болно.
[root@test]# /usr/sbin/lsof -i more
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
syslogd 639 root 7u IPv4 1115 UDP *:syslog
rpc.statd 680 rpcuser 4u IPv4 1205 UDP *:32771
rpc.statd 680 rpcuser 5u IPv4 1192 UDP *:856
rpc.statd 680 rpcuser 6u IPv4 1208 TCP *:32768 (LISTEN)
sshd 715 root 3u IPv4 1258 TCP *:ssh (LISTEN)
named 23808 named 20u IPv4 162255 UDP test.mn:domain
named 23808 named 21u IPv4 162256 TCP test.mn:domain (LISTEN)
named 23808 named 22u IPv4 162257 UDP test.mn:domain
named 23808 named 23u IPv4 162258 TCP test.mn:domain (LISTEN)
named 23808 named 24u IPv4 162259 UDP *:32773
lsof -i TCP - тухайн систем дээр байгаа TCP Socket-руу хандаж байгаа бүх процессыг харуулна.
lsof -i tcp:53 - 53-р портон дээр ажиллаж байгаа процессыг харуулна.
Файл гэдэгт юу юу орох вэ? Unix систем дээр бараг бүх зүйлийг файл гэж үзэж болно. Файл бол файл, директор бас нэг төрлийн онцгой файл, төхөөрөмжүүд мөн файл, /proc файлсистемийг аваад үзэх юм бол санах ой, процесс, сүлжээний холболтыг бүгдийг файлаар илэрхийлж болно. Файлыг процессууд хэрэглэх ба ихэвчлэн "нээлттэй" эсвэл "хаалттай" гэсэн хоёрхон төлөвт байдаг. Ер нь бол санах ойд ачаалагдан ажиллаж байгаа ямар нэг процессын хувьд холбогдох хоёртын файл, өгөгдөл эсвэл тохиргооны файлууд, цаашилбал түүнийг ашиглаж буй hardware төхөөрөмж "нээлттэй" төлөвт байна.
lsof-н энэ чадварыг ашиглан системийн хаана ямар үйл явц болж байгааг илрүүлэхэд хялбар болдог. Тиймээс ч lsof-г гадны халдлагыг илрүүлэхэд хэрэглэдэг байна. lsof-н тусламжтай ажиллаж байгаа процессын жагсаалтыг харж болно, үүгээрээ ps-г орлож чадна. Мөн сүлжээний холболтуудыг харж болно, үүгээрээ netstat-г орлож чадна. Дээр нь бид эдгээр процесс болон сүлжээний холболтуудын хэрэглэж байгаа бүх "нээлттэй" файлуудыг харж чадна.
нээлттэй портууд болон үүссэн сесс/session-ууд
-i тугын тусламжтай интернет холболттой холбоотой бүх нээлттэй байгаа файлууд болон "хүлээж байгаа үйлчилгээ"/listening service-н жагсаалтыг харж болно.
[root@test]# /usr/sbin/lsof -i more
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
syslogd 639 root 7u IPv4 1115 UDP *:syslog
rpc.statd 680 rpcuser 4u IPv4 1205 UDP *:32771
rpc.statd 680 rpcuser 5u IPv4 1192 UDP *:856
rpc.statd 680 rpcuser 6u IPv4 1208 TCP *:32768 (LISTEN)
sshd 715 root 3u IPv4 1258 TCP *:ssh (LISTEN)
named 23808 named 20u IPv4 162255 UDP test.mn:domain
named 23808 named 21u IPv4 162256 TCP test.mn:domain (LISTEN)
named 23808 named 22u IPv4 162257 UDP test.mn:domain
named 23808 named 23u IPv4 162258 TCP test.mn:domain (LISTEN)
named 23808 named 24u IPv4 162259 UDP *:32773
lsof -i TCP - тухайн систем дээр байгаа TCP Socket-руу хандаж байгаа бүх процессыг харуулна.
lsof -i tcp:53 - 53-р портон дээр ажиллаж байгаа процессыг харуулна.
lsof -р 578 - 578-р процессын ашиглаж байгаа ресурсуудыг харуулна.
lsof -с named - Линукс дээр нэг процессын хэд хэдэн тохиолдол/instance ажиллаж байх нь бий. -с тугын тусламжтайгаар ийм төрлийн ижил процессуудын ашиглаж байгаа ресурсуудыг харуулна.
lsof -u root - тухайн хэрэглэгчийн ашиглаж байгаа ресурсуудыг харуулна.
lsof командын бусад тугуудын талаар http://dmiessler.com/study/nix/commands/lsof/ хаягаас уншаарай.
Ажиллаж байгаа процессын устгагдсан файл
Нээлттэй боловч холбогдоогүй/unlinked файл гэдэг нь директор бүтэц дотор нэр нь байхгүй боловч, түүнд олгогдсон диск блокыг ямар нэг процесс хэрэглэж байгаа файлыг хэлнэ. Ийм төрлийн файл ls команданд өртөхгүй боловч программ түүнийг ашиглаж чадна гэсэн үг юм. Ийм төрлийн файлыг
# lsof +L1
+L1 нь link count нэгээс бага өөрөөр хэлбэл 0-тэй тэнцүү байгаа файлуудыг харуулна.
командын тусламжтай илрүүлж болно. Дээрх командыг өгсний дараа та устгагдсан мөртлөө ямар нэг процесс ашигласаар байгаа файлын жагсаалтыг дараах байдалтай харах болно.
COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME
less 25677 root 4r REG 3,8 103362 0 32868 /home/test/myfile (deleted)
Устгасан файлыг lsof-н тусламжтай хэрхэн сэргээх вэ?
Бид дээр жишээн дээрээс устгасан файлыг ашиглаж байгаа процессын PID болон энэ файлын FD(file descriptor) утгыг олж мэдсэн билээ. Одоо бид /proc файлсистемийн тусламжтай энэ файлыг хялбархан сэргээж болно.
/proc/PID/fd директор дотор энэ процессын ашиглаж байгаа файлууд тоогоор тэмдэглэгдсэн линк байдлаар байрласан байгаа.
# cd /proc/25677/fd # ls -la
total 0
dr-x------ 2 root root 0 Dec 1 18:14 ./
dr-xr-xr-x 3 root root 0 Dec 1 18:14 ../
lrwx------ 1 root root 64 Dec 1 18:17 0 -> /dev/pts/0
lrwx------ 1 root root 64 Dec 1 18:17 1 -> /dev/pts/0
lrwx------ 1 root root 64 Dec 1 18:17 2 -> /dev/pts/0
lr-x------ 1 root root 64 Dec 1 18:17 3 -> /dev/tty
lr-x------ 1 root root 64 Dec 1 18:17 4 -> /home/remote/myfile\ (deleted)
# cp 4 /home/test/myfile2
PS: Энэ жишээ зөвхөн устгасан файлыг ямар нэг процесс ашиглаж байгаа үед сэргээхийг харуулсан болно.
GIAC Certified UNIX Security Administrator (GCUX)
SANS-н GIAC Certified UNIX Security Administrator(GCUX) боллоо би. Урамтай сайхан байнаа. 2 удаагийн тестээр шалгалтаа өгсөн. Ихэнх асуултууд нь 7 сард суусан сургалтын агуулгаас ирсэн байсан. FreeBSD-с өөр UNIX систем дээр ажиллаж үзээгүй надад Solaris-н талаарх асуултууд их бүрхэг байсан. Solaris-н материалыг цээжилж орсон, зарим асуултанд яалт ч үгүй мэдэхгүй тул тэглэсэн...
Үнэндээ энэ шалгалтыг өгье гэж бодоогүй явтал, сургалтан дээр танилцсан Sailata гээд нэг энэтхэг бүсгүй "би хувьдаа өгнө, харин чи өгөөд үз л дээ" гэж ятгаснаас сүүлийн өдөр нь амжиж бүртгүүлсэн юм. Хүн үнэхээр хичээвэл чадахгүй юм гэж байдаггүй юм байна гэж хэлмээр байна даа.
За тэгээд мэдээж намайг мэргэжлээрээ өсөж дэвжихэд нэмэр болсон MobiNet-н хамт олондоо, мөн MUUG-н нөхөддөө баярлаж явдаг шүү гэж хэлье.
Хичээвэл чадна шүү! Та нар шүү!
Үнэндээ энэ шалгалтыг өгье гэж бодоогүй явтал, сургалтан дээр танилцсан Sailata гээд нэг энэтхэг бүсгүй "би хувьдаа өгнө, харин чи өгөөд үз л дээ" гэж ятгаснаас сүүлийн өдөр нь амжиж бүртгүүлсэн юм. Хүн үнэхээр хичээвэл чадахгүй юм гэж байдаггүй юм байна гэж хэлмээр байна даа.
За тэгээд мэдээж намайг мэргэжлээрээ өсөж дэвжихэд нэмэр болсон MobiNet-н хамт олондоо, мөн MUUG-н нөхөддөө баярлаж явдаг шүү гэж хэлье.
Хичээвэл чадна шүү! Та нар шүү!
Friday, November 24, 2006
Удирдлагын Академи дээрх сургалтууд
ЗГХЭГ(Засгийн Газрын Хэрэг Эрхлэх Газар)-аас нийт Яамд, Төрийн байгууллагуудын IT-гийн мэргэжилтнүүдийн дунд сургалт зохион байгуулдаг юм байна. Өнгөрсөн сард Яамны админуудад зориулж зохион байгуулсан сургалтанд "Mail System"-н талаар qmail server дээр тулгуурлаж нэг удаагийн хичээл заах боломж надад олдсон билээ.
Нилээд олон яамны IT Мэргэжилтнүүд ирсэн байлаа. Бүгдээрээ л сурч мэдье гэсэн залуу улсууд байсан. Харин "IT Мэргэжилтэн" нэрийн дор сүлжээгээ зохион байгуулдаг сүлжээний инженер, мэйл веб сервер ажиллуулдаг систем админ, үйлдлийн систем програм хангамжийг суулгадаг компьютерийн үйлчилгээ хариуцагч, компьютер эвдэрвэл засдаг засварчин... өөрсдийнх нь хэлснээр К үсгээр эхэлсэн бүх юмыг хариуцдаг ажил хийдэг гэлээ. :). Энэ нь IT-г хариуцсан ганц ганцхан хүн байдгаас болдог гэж ярьж байсан...
Хичээл дээр мэйл сервер, мэйл системийн талаар нилээд яриа дэлгэлээ. Ихэнх газар нь мэйл серверээ суулгаад л орхичихсон, логыг нь уншиж араас нь санаа тавьдаг газар үнэндээ байхгүй гэхэд болохоор цөөхөн байлаа... Би өөрийнхөө ажилтай зүйрлээд бодлоо. Манай хэрэглэгчид мэйл нь ирсэнгүй, явсангүй гээд л асуулга тавьж байдаг, мэйлийн логыг шалгах ажил өдөр тутам гардаг. Ингэж эргэх холбоотой ажиллана гэдэг хэн хэндээ хэрэгтэй байдаг. Нэг талаас хэрэглэгчид мэйл хэрхэн ажилладаг талаар бага ч гэсэн ойлголттой болж, бидний ажлыг ойлгож эхэлдэг. Бидний хувьд гэмтэл саатал, сервер дээр гарсан ямар нэг асуудлыг цаг алдалгүй шийдвэрлэх боломжтой болдог...
Ажил дээр сууж байхад "мэйл" гэдэг зүйл filesystem дээр байдаг нэг файл, terminal цонхон дээр урсаж байгаа нэг мөр бичлэг... л юм шиг санагддаг байлаа. Гэтэл мэйл бол бизнесийн үйл ажиллагаа явуулдаг газруудад амин чухал зүйлийн нэг. Ялангуяа цаг хугацаатай уралдаж байдаг газруудын хувьд... Нэг жишээ дурдахад: мэйлээ шалгаж болохгүй байна гэж нэг хэрэглэгч маань хэд хэдэн удаа утсаар ярилаа. Заавал хүн ирж үзүүлмээр байна гэж нилээд шалсан. Дуудлагын инженерүүд маань бүгд завгүй байсан тул өөрөө очиж үзлээ. Асуудал яахав амархан шийдэгдсэн л дээ. Тэднийх ачаа тээврийн зууч компани байлаа. Хаанаас ямар ачаа хэзээ гарсан, хэзээ хүрэх газраа очих гээд л бүх мэдээллээ мэйлээр солилцдог газар байлаа. Мэйлээ шалгаж болохгүй байгаа шалтгаанаар ажил нилээд цалгардсан, менежер нь бололтой хүн нилээд бухимдсан байдалтай байна. Тэгэхэд л ажлынхаа хариуцлагын талаар илүү ойлгох шиг болсон.
Тэгэхээр Төрийн ажил явуулж байгаа Яамдуудын хувьд мэйл гэдэг маань түрүүний ачаа тээврийн зууч компанийхаас дор байна гэж яав ч байхгүй. Сургалтанд суусан залуучуудын хэлснээр "IT-гийн алба нь IT ойлгодог даргатай болооосой", "IT-гийн мэргэжилтнийхээ тоог нэмээсэй", "өөрийн мэйл болон бусад серверүүд, мөн сүлжээнийхээ maintainance, аюулгүй байдалд илүү анхаараасай" гэж л хэлэх байна даа.
PS: Өнгөрсөн Даваа гарагт Мэйл Системийн талаар орох байсан хичээлийг орж чадаагүй тул хүлцэл өчье. Сургалтанд суусан админууд хичээлийн slide-г татаж авч болно.
Нилээд олон яамны IT Мэргэжилтнүүд ирсэн байлаа. Бүгдээрээ л сурч мэдье гэсэн залуу улсууд байсан. Харин "IT Мэргэжилтэн" нэрийн дор сүлжээгээ зохион байгуулдаг сүлжээний инженер, мэйл веб сервер ажиллуулдаг систем админ, үйлдлийн систем програм хангамжийг суулгадаг компьютерийн үйлчилгээ хариуцагч, компьютер эвдэрвэл засдаг засварчин... өөрсдийнх нь хэлснээр К үсгээр эхэлсэн бүх юмыг хариуцдаг ажил хийдэг гэлээ. :). Энэ нь IT-г хариуцсан ганц ганцхан хүн байдгаас болдог гэж ярьж байсан...
Хичээл дээр мэйл сервер, мэйл системийн талаар нилээд яриа дэлгэлээ. Ихэнх газар нь мэйл серверээ суулгаад л орхичихсон, логыг нь уншиж араас нь санаа тавьдаг газар үнэндээ байхгүй гэхэд болохоор цөөхөн байлаа... Би өөрийнхөө ажилтай зүйрлээд бодлоо. Манай хэрэглэгчид мэйл нь ирсэнгүй, явсангүй гээд л асуулга тавьж байдаг, мэйлийн логыг шалгах ажил өдөр тутам гардаг. Ингэж эргэх холбоотой ажиллана гэдэг хэн хэндээ хэрэгтэй байдаг. Нэг талаас хэрэглэгчид мэйл хэрхэн ажилладаг талаар бага ч гэсэн ойлголттой болж, бидний ажлыг ойлгож эхэлдэг. Бидний хувьд гэмтэл саатал, сервер дээр гарсан ямар нэг асуудлыг цаг алдалгүй шийдвэрлэх боломжтой болдог...
Ажил дээр сууж байхад "мэйл" гэдэг зүйл filesystem дээр байдаг нэг файл, terminal цонхон дээр урсаж байгаа нэг мөр бичлэг... л юм шиг санагддаг байлаа. Гэтэл мэйл бол бизнесийн үйл ажиллагаа явуулдаг газруудад амин чухал зүйлийн нэг. Ялангуяа цаг хугацаатай уралдаж байдаг газруудын хувьд... Нэг жишээ дурдахад: мэйлээ шалгаж болохгүй байна гэж нэг хэрэглэгч маань хэд хэдэн удаа утсаар ярилаа. Заавал хүн ирж үзүүлмээр байна гэж нилээд шалсан. Дуудлагын инженерүүд маань бүгд завгүй байсан тул өөрөө очиж үзлээ. Асуудал яахав амархан шийдэгдсэн л дээ. Тэднийх ачаа тээврийн зууч компани байлаа. Хаанаас ямар ачаа хэзээ гарсан, хэзээ хүрэх газраа очих гээд л бүх мэдээллээ мэйлээр солилцдог газар байлаа. Мэйлээ шалгаж болохгүй байгаа шалтгаанаар ажил нилээд цалгардсан, менежер нь бололтой хүн нилээд бухимдсан байдалтай байна. Тэгэхэд л ажлынхаа хариуцлагын талаар илүү ойлгох шиг болсон.
Тэгэхээр Төрийн ажил явуулж байгаа Яамдуудын хувьд мэйл гэдэг маань түрүүний ачаа тээврийн зууч компанийхаас дор байна гэж яав ч байхгүй. Сургалтанд суусан залуучуудын хэлснээр "IT-гийн алба нь IT ойлгодог даргатай болооосой", "IT-гийн мэргэжилтнийхээ тоог нэмээсэй", "өөрийн мэйл болон бусад серверүүд, мөн сүлжээнийхээ maintainance, аюулгүй байдалд илүү анхаараасай" гэж л хэлэх байна даа.
PS: Өнгөрсөн Даваа гарагт Мэйл Системийн талаар орох байсан хичээлийг орж чадаагүй тул хүлцэл өчье. Сургалтанд суусан админууд хичээлийн slide-г татаж авч болно.
Thursday, November 16, 2006
Datacom-н монгол дахь DNS серверvvд орж гараад байнуудаа гэж...
За ингээд хэлчихээр Датакомынхон болоод бусад хүмүүс сандралд орох вий дээ. Эхлээд энэ нийтлэлийг дуустал нь уншаарай.
Өнгөрсөн 10 сарын 03-ны өглөө 08:10-д манай оператороос манай DNS болохгүй байна, зарим домэйн олдоод зарим нь олдохгүй байна гэж дуудав. Би ч өөрийнхөө DNS серверийн логыг, дараа нь мэйл серверийнхээ логыг үзэв. Хараад байсан .mn домэйнууд олдохгүй байна. Манай DNS cache server-т л байна даа гэж бодсон. cache server-ээ үзээд байдаг үзээд байдаг... зүгээр л байх юм. Бусад газрууд яасийн бол гэж бодоод Magicnet-н админаас асуусан "Датакомоос асуухгүй юу, манайх лав зүгээр" гэнэ... танихгүй болоод ч тэр юмуу ёстой наашгүй хариу өглөө... хм... Дараа нь сая сургалтанд хамт сууснаараа Мicom-н Тэгшээгээс асууя гэж бодоод g0mb0 ахаас yahoo id-г авлаа. За нэг танилын нүүр халуун гэдэг шиг ёстой шалгааж авлаа. Танай DNS дээр ямар нэг сонин юм ажиглагдаагүй юу? гэлээ. Тэгшээ ч зүгээр л гээд байна... .mn домэйн болохгүй байгаа биз дээ, гэж нилээд шаллаа, тэгсэн харин сүүлд нь .mn домэйн харин өглөөнөөс болохгүй байх шиг байна гэлээ... ёстой нэг санаа амрах шиг болсон, хэхэ... За тэгээд удалгүй Датакомын нэг DNS дээр асуудал гарсан нь тодорхой болж удалгүй зүгээр болсон... 2 хоногын дараа mobicom.mn-г олохгүй хэдэн мэйл яваагүй харагдсан. Тэгэхээр нь Nagios дээрээ Datacom-н монголд байгаа 2 DNS сервер-г нэмээд байнга ажигладаг боллоо.
Уржигдар мөн MIX дээр асуудал гарснаас 07:56-10:48 хооронд Datacom DNS дээр critical alarm гарсан харагдана. Эдний сервер дээр аларм гарч харагддаг,харин манай DNS Cache дээр аларм гарахгүй болохоор ажиглаад л суугаад байсан. Сая нэг санаа авч Датакомын Мөнхдөлтэй ярилцлаа. Танайх орж гараад байна гээд... Тэгсэн тэдний сервертээ ч биш Magicnet-н холболтондоо байгаа бололтой... Гадаад гарц дүүрэх, эсвэл ачаалал ихтэй үед DNS хамгийн мэдрэмхий байдаг, DNS дээр хамгийн түрүүнд alarm гарч харагддаг л даа. Энэ нь bandwidth дүүрэх үед сүлжээний төхөөрөмжүүд prioroty багатай service-үүд (жишээлбэл DNS-г) хаадаг гэж ярьдаг юм байна лээ. Гэхдээ л бодох л асуудал... Датаком чинь үндэсний хэмжээний үйлчилгээ үзүүлдэг газар шүү дээ!
Тэгээд надад хэлэх гэсэн нэг л зүйл байна. Манай админууд яагаад хамтарч ажилладаггvй юм бэ? Надад тохиолдож байгаа асуудал бусад бүх ISP-н админуудад тохиолдож л байгаа. Datacom болохгүй байна, MIX дээр асуудал гарлаа гэхэд гэмтэлийн шинж тэмдэг, нөлөөлөх байдал, гэмтэл гарсан цаг, засагдсан цаг хугацааг мэдээлдэг самбар маягын юм байвал баахан бие биенээ гайхаж харж суухгүй байх. Бид бизнесээрээ өрсөлднүү гэхээс мэдлэгээ хуваалцаж, техникийн тал дээр хамтарч ажиллах учиртай шүү дээ.
Өнгөрсөн 10 сарын 03-ны өглөө 08:10-д манай оператороос манай DNS болохгүй байна, зарим домэйн олдоод зарим нь олдохгүй байна гэж дуудав. Би ч өөрийнхөө DNS серверийн логыг, дараа нь мэйл серверийнхээ логыг үзэв. Хараад байсан .mn домэйнууд олдохгүй байна. Манай DNS cache server-т л байна даа гэж бодсон. cache server-ээ үзээд байдаг үзээд байдаг... зүгээр л байх юм. Бусад газрууд яасийн бол гэж бодоод Magicnet-н админаас асуусан "Датакомоос асуухгүй юу, манайх лав зүгээр" гэнэ... танихгүй болоод ч тэр юмуу ёстой наашгүй хариу өглөө... хм... Дараа нь сая сургалтанд хамт сууснаараа Мicom-н Тэгшээгээс асууя гэж бодоод g0mb0 ахаас yahoo id-г авлаа. За нэг танилын нүүр халуун гэдэг шиг ёстой шалгааж авлаа. Танай DNS дээр ямар нэг сонин юм ажиглагдаагүй юу? гэлээ. Тэгшээ ч зүгээр л гээд байна... .mn домэйн болохгүй байгаа биз дээ, гэж нилээд шаллаа, тэгсэн харин сүүлд нь .mn домэйн харин өглөөнөөс болохгүй байх шиг байна гэлээ... ёстой нэг санаа амрах шиг болсон, хэхэ... За тэгээд удалгүй Датакомын нэг DNS дээр асуудал гарсан нь тодорхой болж удалгүй зүгээр болсон... 2 хоногын дараа mobicom.mn-г олохгүй хэдэн мэйл яваагүй харагдсан. Тэгэхээр нь Nagios дээрээ Datacom-н монголд байгаа 2 DNS сервер-г нэмээд байнга ажигладаг боллоо.
Уржигдар мөн MIX дээр асуудал гарснаас 07:56-10:48 хооронд Datacom DNS дээр critical alarm гарсан харагдана. Эдний сервер дээр аларм гарч харагддаг,харин манай DNS Cache дээр аларм гарахгүй болохоор ажиглаад л суугаад байсан. Сая нэг санаа авч Датакомын Мөнхдөлтэй ярилцлаа. Танайх орж гараад байна гээд... Тэгсэн тэдний сервертээ ч биш Magicnet-н холболтондоо байгаа бололтой... Гадаад гарц дүүрэх, эсвэл ачаалал ихтэй үед DNS хамгийн мэдрэмхий байдаг, DNS дээр хамгийн түрүүнд alarm гарч харагддаг л даа. Энэ нь bandwidth дүүрэх үед сүлжээний төхөөрөмжүүд prioroty багатай service-үүд (жишээлбэл DNS-г) хаадаг гэж ярьдаг юм байна лээ. Гэхдээ л бодох л асуудал... Датаком чинь үндэсний хэмжээний үйлчилгээ үзүүлдэг газар шүү дээ!
Тэгээд надад хэлэх гэсэн нэг л зүйл байна. Манай админууд яагаад хамтарч ажилладаггvй юм бэ? Надад тохиолдож байгаа асуудал бусад бүх ISP-н админуудад тохиолдож л байгаа. Datacom болохгүй байна, MIX дээр асуудал гарлаа гэхэд гэмтэлийн шинж тэмдэг, нөлөөлөх байдал, гэмтэл гарсан цаг, засагдсан цаг хугацааг мэдээлдэг самбар маягын юм байвал баахан бие биенээ гайхаж харж суухгүй байх. Бид бизнесээрээ өрсөлднүү гэхээс мэдлэгээ хуваалцаж, техникийн тал дээр хамтарч ажиллах учиртай шүү дээ.
Wednesday, November 15, 2006
Nagios + check_by_ssh + public key authentication
Серверрүү логин хийж ороод дотор нь ажиллаж байгаа процессуудыг хянадаг, эсвэл дискний зай дуусаж байгааг хэлдэг тийм хянагч/monitoring програм байдаг болоосой гэж админууд маань бодож явдаг байх, эсвэл өөрөө тийм скрипт бичихийг оролдож байсан ч байх. Тэгвэл та бүхэн Nagios-н "check_by_ssh plugin"-г "public key authentication"-ы хамт туршаад үзээрэй. Хянагч програмуудаас Nagios их зүгээр санагддаг. Тухайн хоструу 5 минутын зайтайгаар PING тест хийхээс гадна HTTP, MYSQL, DNS, POP, SMTP, FTP зэрэг гадаад портон дээр ажиллаж байгаа үйлчилгээнүүдийг хялбарханаар хянах боломжтой. Ямар нэг асуудал гарсан тохиолдолд мэйлээр Alarm message илгээх боломжтой. Админ мэйл хаягаа MailAlert-тай холбочихвол ч жинхэнэ real-time alert-г хүлээн авах боломжтой болно.
define command {
command_name check_remote_procs
command_line $USER1$/check_by_ssh -S 6 -H $HOSTADDRESS$ -u testuser -C '/home/testuser/check_procs -w $ARG1$ -c $ARG2$ -$ARG3$ $ARG4$'
}
Улаанаар бичсэн мөрийг nagios ssh-р login хийж орсны дараа ажиллуулах бөгөөд жишээ болгож check_remote_procs командыг авлаа.
Ажиллах үндсэн зарчим - monitor ажиллах машин(A) дээр nagios-г plugin-уудын хамт суулгасан байна. Хяналт хийх гэж байгаа сервер(B) дээр гаднаас ssh-р "public key authentication" хийж орох эрхтэй user account-г үүсгэн, түүний home directory дотор В машины юуг хянах гэж байгаагаас шалтгаалан хэрэгтэй nagios plugin-г байрлуулсан байна. А машин дээрээс check_by_ssh-н тусламжтайгаар В машинруу логин хийж орон харгалзах plugin-г ажиллуулан үр дүнг "OK, Warming, Critical, Unknown" түвшинүүдээр харуулна.
B машин дээр ажиллах боломжтой nagios plugin-ууд:
check_users
check_load
check_disk
check_procs
...
1. Nagios болон plugin-г суулгах - Nagios-г хэрхэн суулгах талаар маш дэлгэрэнгүй танилцуулга http://www.nagios.org/docs/ байгаа тул энэ хэсгийг алгасав. Plugin-г source tarball-с эсвэл rpm-р суулгах аль аль нь амархан сууна.
RPM-р суулгавал:
/etc/rc.d/init.d/nagios - control script
/usr/bin/ - nagios, nagiostat хоёртын файлууд
/usr/include/nagios/ - үндсэн кодын сан/library
/usr/lib/nagios/cgi - cgi cкриптүүд
/usr/lib/nagios/plugins - nagios plugin-ууд
/etc/nagios - үндсэн тохиргооны файлууд
байрлана.
2. Public Key Authetication - Ийм төрлийн authentication-г ихэвчлэн автоматжсан програмаас серверрүү логин хийж ороход хэрэглэдэг. Учир нь автомажсан програмыг ажиллуулах үед "login prompt" дээр програмыг гацаахгүйн тулд нууц үгийн оронд "public key"(сервер дээр урьдчилж хуулж тавина) ашиглан authentication хийнэ.
2.1 шинэ хэрэглэгч нэмэх - В машин дээр шинэ хэрэглэгч үүсгэхдээ:
# useradd testuser
testuser хэрэглэгчийг үүсгэхдээ нууц үг оноохгүйг анхаарай. "public key" ашиглан логин хийх тул нууц үг оруулах шаардлагагүй. Мөн энэ хэрэглэгчийн хувьд "interactive shell" идэвхжсэн байх ёстойг анхаараарай.
2.2 SSH-н хувьд public key authentication-г идэвхжүүлэх - /etc/ssh/sshd_config дотор дараах тохиргоог хийнэ:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers testuser xxx
xxx - оронд ssh-р хандах бусад хэрэглэгчдийн нэрсийг зай аван цуьуулж бичнэ.
2.3 Хос түлхүүрийг үүсгэх - хос түлхүүр үүсгэж нэгийг А машин дээр, нөгөөг В машин дээр байрлуулах ёстой. Хос түлхүүрийг дараах байдалтай үүсгэнэ.
# ssh-keygen -t rsa
PS: Энд RSA-н оронд DSA алгоритмаар кодлож болно.
Энэ командыг өгсний дараа passphrase асуух бөгөөд та passphrase оруулах шаардлагагүй.
PS: passphrase оруулж түлхүүр үүсгэж болно. Энэ тохиолдолд public key authentication хийхийн тулд ssh-agent ажиллуулах хэрэгтэй болно. Асуудал цааш хүндрэх тул энэ талаар сонирхож байгаа бол бусад гарын авлагыг ашиглана уу.
Үр дүнд нь id_rsa, id_rsa.pub гэсэн 2 файл үүснэ. id_rsa файлыг А машин дээр, nagios server-г ажиллуулж буй хэрэглэгчийн (ихэнх тохиолдолд nagios) home directory дотор хуулж тавина.
# cp id_rsa /home/nagios/.ssh/
# chmod 600 /home/nagios/.ssh/id_rsa
# chown root.root /home/nagios/.ssh/id_rsa
Харин id_rsa.pub файлыг В машин дээр testuser хэрэглэгчийн home directory /home/testuser/.ssh/ дотор authorized_keys нэртэйгээр байрлуулах хэрэгтэй.
# cp id_rsa.pub /home/testuser/.ssh/authorized_keys
# chmod 400 /home/testuser/.ssh/authorized_keys
# chown root.root /home/testuser/.ssh/authorized_keys
Аюулгүй байдлыг хангах үүднээс authorized_keys файл дотор, мөрийн эхэнд уг түлхүүр үгийг ашиглан хандах эрхтэй IP хаягуудыг жагсаан бичнэ:
from="10.1.5.23"
3. check_by_ssh plugin-г тохируулах
3.1 Эхлээд check_by_ssh plugin-г
define command {
command_name check_remote_procs
command_line $USER1$/check_by_ssh -S 6 -H $HOSTADDRESS$ -u testuser -C '/home/testuser/check_procs -w $ARG1$ -c $ARG2$ -$ARG3$ $ARG4$'
}
Улаанаар бичсэн мөрийг nagios ssh-р login хийж орсны дараа ажиллуулах бөгөөд жишээ болгож check_remote_procs командыг авлаа.
3.2 check_procs хоёртын файлыг В машины /home/testuser дотор хуулж тавих бөгөөд 744 permision тавина.
За ингээд бүх тохиргоог хийж дууслаа. Одоо check_remote_procs командыг ашиглан шинэ service үүсгэн туршиж үзье. Үүний тулд /etc/nagios/services.cfg дотор дараах мөрүүдийг нэмнэ:
define service{
use generic-service
host_name Web_Server_1
service_description ProFTP
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups linux-admins
notification_interval 240
notification_period 24x7
notification_options c,r
check_command check_remote_procs!1:1!1:1024!C!proftpd
}
Monday, October 30, 2006
Yahoo-гийн мэйл ойрд яагаад байнаа
Манай мэйлийн админууд анзаарсан боловуу. Ойрын нэг 7 хоног yahoo-гийн мэйл нэг л сонин байна. Шөнө болохоор явахгүй байгаа юмуу, mail queue дотор шөнө ирсэн мэйлүүд яваагүй харагдаад, тэгээд шалгахаар "Connected to ... but greeting failed. /Remote host said: 451 Message temporarily deferred - 4.16.50/" гэсэн алдаа өгсөн байна. Ажлын цагаар харин зүгээр яваад байх шиг...
Интернэтээс хайсан yahoo-гийнхан бүх IP-г greylist-д оруулсан гэнэ. Санаа нь smtp connection үүсгэхээс эхлээд татгалзах юм байна, дараагийн оролдлого дээр нь харин зөвшөөрөх юм байна. Энэ нь спамаас хамгаалж байгаа арга юм байнаа?! Өөрөөр хэлбэл спамерууд нэг мэйлээ дахин явуулахыг ихэнх тохиолдолд оролддоггүй юм байхаа... Бодвол тэр том компанийхан бодож төлөвлөж байж л ийм алхам хийсэн байх, гэхдээ л асуудлыг улам хүндрүүлээд байх шиг...
Одоо тэгээд яах вэ? Yahoo-гийн нэг ийм заавар байна.
http://help.yahoo.com/help/us/mail/defer/defer-01.html
Гэхдээ л асуудал тун бүрхэг байна. Yahoo-гийнхан явуулсан мэйлэнд хариу өгнө ч гэж байхгүй, урьд нь энгийн мэйлүүд Bulk-руу орчихоод байна гэж нилээд олон form бөглөж, мэйл явуулж байсан. Ганц л хариу байхгүй... Дахиад л баахан хайлаа, DomainKey-н сураг гарч байна. Domainkey-г хэрэгжүүлнэ гээд л яригдаад байсан, ганцхан өдөр ингээд л хэрэгжүүлчдэг юм боловуу.
Манай админуудад санаа оноо байнуу?
Интернэтээс хайсан yahoo-гийнхан бүх IP-г greylist-д оруулсан гэнэ. Санаа нь smtp connection үүсгэхээс эхлээд татгалзах юм байна, дараагийн оролдлого дээр нь харин зөвшөөрөх юм байна. Энэ нь спамаас хамгаалж байгаа арга юм байнаа?! Өөрөөр хэлбэл спамерууд нэг мэйлээ дахин явуулахыг ихэнх тохиолдолд оролддоггүй юм байхаа... Бодвол тэр том компанийхан бодож төлөвлөж байж л ийм алхам хийсэн байх, гэхдээ л асуудлыг улам хүндрүүлээд байх шиг...
Одоо тэгээд яах вэ? Yahoo-гийн нэг ийм заавар байна.
http://help.yahoo.com/help/us/mail/defer/defer-01.html
Гэхдээ л асуудал тун бүрхэг байна. Yahoo-гийнхан явуулсан мэйлэнд хариу өгнө ч гэж байхгүй, урьд нь энгийн мэйлүүд Bulk-руу орчихоод байна гэж нилээд олон form бөглөж, мэйл явуулж байсан. Ганц л хариу байхгүй... Дахиад л баахан хайлаа, DomainKey-н сураг гарч байна. Domainkey-г хэрэгжүүлнэ гээд л яригдаад байсан, ганцхан өдөр ингээд л хэрэгжүүлчдэг юм боловуу.
Манай админуудад санаа оноо байнуу?
Friday, October 27, 2006
Oyunbodol blog
Оюунбодолын үлдээсэн линкээр орж түүний нийтлэлийг уншлаа. Түүний хэлсэн зарим нэг санаа үнэхээр дэмжүүштэй юмаа. Хараад байхад блог бичдэг хүмүүс зөндөө болж, хүн болгон мэдээж өөрийн сонирхдог зүйл, эсвэл хийдэг ажлынхаа талаар, зарим нь бодол эргэцүүллээ гээд л бичдэг. Мэдээж энэ бүгдийг ганцхан өөртөө зориулж бичнэ гэж байхгүй. Өөрийн хүсэл санаа нэгтэй хүмүүст хүрч тэдэнд бодол саналаа хүргэх гэж л бичдэг байж таараа. Миний хувьд ч ялгаагүй мэдэж чадаж байгаа юм байвал хүмүүст хэрэг болох байх гэсэн үүднээс л бичдэг. Тэгээд хүмүүсийн үлдээсэн comment-г уншаад урам авдаг. Блог бичих сайхан санагддаг, нэг бодлын өөрийн үүргээ гүйцэтгэж байна гэж боддог. Мэдээж одоогоор зөвхөн хийж байгаа ажлынхаа хүрээнд sysadmin-уудад зориулсан нийтлэл бичиж байна. Гэхдээ надад өөр зөндөө бодож санаж явдаг зүйл бий. Жишээ нь байгал орчноо хамгаалах талаар хүмүүстэй санал бодлоо солилцмоор санагддаг. Байгалаа хамгаалах талаар зарим хүмүүсийн блогыг уншаад таалагдсан.
Гэхдээ бидэнд нийтлэг нэг зүйл байгаа нь хийхээсээ их яридаг л асуудал байна даа. Ямар нэг зүйл хийж эхлүүлэхийн тулд эхлээд нэгдэх хэрэгтэй. Тийм болохоор нэгдэх боломжийг нь хамгийн түрүүнд бүрдүүлж өгөх хэрэгтэй байх шүү.
Сая л гэхэд надад Цэвэл гуайн толь бичгээс нэг үг харах хэрэг гарлаа. Тэгээд Хотын Нийтийн Номын Сангийн Бэгзээгээс электрон хэлбэрээр байдаг уу? гэж асуусан. Тэр хариуд нь "чи Цэвэлийн толийг асуусан 2 дахь хүн нь боллоо. Харамсалтай нь үгүй. Номын электронжуулах ажил удаашралтай байна" гэсэн. Тэр надад "онлайн номын сан гэвэл БСШУЯамны http://www.elibrary.mn/ байна" гэлээ. Зохиолчдийн намтар гэдэг дээр нь Цэвэл гуай ч алга. Уран зохиол, хүүхдийн номнууд хэд хэд орсон байна. Электрон номын сан гээд ч яригдаад л байдаг, төсөл хэрэгжүүлж байна гээд л байсан. Тэгсэн яг харахаар юу ч байдаггүй юм байна. Ямар сайндаа л "Тэр номнуудыг нь хэн оруулдаг юм бээ. Мөнгө санхүү нь хүрдэггүй юмуу, тийм бол тэрийг нь цуглуулаад өгье л дөө. Чи Цэвэлийн толийг оруулаад өгөөч" гэж байхав...
Цэвэлийн толь электрон хэлбэрээр байдаг болчвол гадаадад байгаа Монголчуудад маань их л хэрэгтэй байх сан. Бэгзээ надад ямар ч байсан нэг хариу хэлэх байх гэж хүлээж байна.
Гэхдээ бидэнд нийтлэг нэг зүйл байгаа нь хийхээсээ их яридаг л асуудал байна даа. Ямар нэг зүйл хийж эхлүүлэхийн тулд эхлээд нэгдэх хэрэгтэй. Тийм болохоор нэгдэх боломжийг нь хамгийн түрүүнд бүрдүүлж өгөх хэрэгтэй байх шүү.
Сая л гэхэд надад Цэвэл гуайн толь бичгээс нэг үг харах хэрэг гарлаа. Тэгээд Хотын Нийтийн Номын Сангийн Бэгзээгээс электрон хэлбэрээр байдаг уу? гэж асуусан. Тэр хариуд нь "чи Цэвэлийн толийг асуусан 2 дахь хүн нь боллоо. Харамсалтай нь үгүй. Номын электронжуулах ажил удаашралтай байна" гэсэн. Тэр надад "онлайн номын сан гэвэл БСШУЯамны http://www.elibrary.mn/ байна" гэлээ. Зохиолчдийн намтар гэдэг дээр нь Цэвэл гуай ч алга. Уран зохиол, хүүхдийн номнууд хэд хэд орсон байна. Электрон номын сан гээд ч яригдаад л байдаг, төсөл хэрэгжүүлж байна гээд л байсан. Тэгсэн яг харахаар юу ч байдаггүй юм байна. Ямар сайндаа л "Тэр номнуудыг нь хэн оруулдаг юм бээ. Мөнгө санхүү нь хүрдэггүй юмуу, тийм бол тэрийг нь цуглуулаад өгье л дөө. Чи Цэвэлийн толийг оруулаад өгөөч" гэж байхав...
Цэвэлийн толь электрон хэлбэрээр байдаг болчвол гадаадад байгаа Монголчуудад маань их л хэрэгтэй байх сан. Бэгзээ надад ямар ч байсан нэг хариу хэлэх байх гэж хүлээж байна.
Security through Obscurity - II (Version hiding)
Энэ удаа "өнгөлөн далдлалт"-н нэг хэлбэр болох "version hiding" буюу серверийн хувилбарыг нуух аргын талаар товч дурдъя.
Ихэнх сервер софтверүүд өөрийн хувилбарын дугаарыг нийтэд зарлаж байдаг ба хялбархан scan хийснээр тухайн серверийн талаар бүх мэдээллийг олж болно. Хэрвээ Hacker хувилбарын дугаарыг мэдвэл... bug-р дамжин системд чинь нэвтрэх боломжтой болно. Энэ нь ямар нэг гадны автоматжсан скрипт/automated script-д өртөх магадлалыг бууруулж өгч байгаа хэдий ч, нууцлал хамгааллын шалгарсан арга биш гэдгийг манай админууд анхаарна бизээ.
Өөрийн веб серверийн хувилбарыг одоо шалгаад үзээрэй. Үүний тулд:
$ telnet IP 80
гарч ирсэн prompt дээр "HEAD / HTTP/1.0" гэж бичээд enter дарна. Ингэхэд таны серверээс ирсэн HTTP Header мэдээллийг танд харуулах болно. Санаснаас хавьгүй их мэдээллийг олж харвуу?...
1. Version hiding in Apache - httpd.conf дотор ServerTokens directive-г ашиглан тохиргоог хийнэ.
ServerTokens Prod[uctOnly] -> Server: Apache
ServerTokens Major -> Server: Apache/2
ServerTokens Minor -> Server: Apache/2.0
ServerTokens Min[imal] -> Server: Apache/2.0.41
ServerTokens OS -> Server: Apache/2.0.41 (Unix)
ServerTokens Full (or not specified) -> Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
"ServerTokens Prod" гэсэн тохиргоог хийхэд хамгийн бага мэдээлэл өгөх нь. Хэрвээ та Apache ажиллаж байгааг мэдэгдүүлмээргүй байгаа бол эх кодод засвар оруулж дахин compile-дах хэрэгтэй. Үүний тулд include/ap_release.h файлын
#define AP_SERVER_BASEPRODUCT "Apache"
гэсэн мөрийг засах хэрэгтэй.
2. Version hiding in BIND - BIND-н хувьд named.conf файлын options{} directive дотор дараах байдлаар тохиргоог хийнэ.
options {
...
version "D00d!";
... };
3. Version hiding in ProFTP - ProFTP-н хувьд proftpd.conf дотор ServerIdent directive-г ашиглан тохиргоо хийнэ. Default мэндчилгээ, хувилбарын оронд хүссэн мэндчилгээг оруулж болно.
ServerIdent on "MobiNet ISP"
Хэрэв юу ч хэвлэхийг хүсэхгүй бол
ServerIdent off
гэсэн байдлаар тохиргоог хийж болно. Энэ тохиолдолд серверийн домэйн нэрнээс өөр мэдээллийг харуулахгүй.
Obscurity is not security, but... obscurity is a layer of security!
Ихэнх сервер софтверүүд өөрийн хувилбарын дугаарыг нийтэд зарлаж байдаг ба хялбархан scan хийснээр тухайн серверийн талаар бүх мэдээллийг олж болно. Хэрвээ Hacker хувилбарын дугаарыг мэдвэл... bug-р дамжин системд чинь нэвтрэх боломжтой болно. Энэ нь ямар нэг гадны автоматжсан скрипт/automated script-д өртөх магадлалыг бууруулж өгч байгаа хэдий ч, нууцлал хамгааллын шалгарсан арга биш гэдгийг манай админууд анхаарна бизээ.
Өөрийн веб серверийн хувилбарыг одоо шалгаад үзээрэй. Үүний тулд:
$ telnet IP 80
гарч ирсэн prompt дээр "HEAD / HTTP/1.0" гэж бичээд enter дарна. Ингэхэд таны серверээс ирсэн HTTP Header мэдээллийг танд харуулах болно. Санаснаас хавьгүй их мэдээллийг олж харвуу?...
1. Version hiding in Apache - httpd.conf дотор ServerTokens directive-г ашиглан тохиргоог хийнэ.
ServerTokens Prod[uctOnly] -> Server: Apache
ServerTokens Major -> Server: Apache/2
ServerTokens Minor -> Server: Apache/2.0
ServerTokens Min[imal] -> Server: Apache/2.0.41
ServerTokens OS -> Server: Apache/2.0.41 (Unix)
ServerTokens Full (or not specified) -> Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
"ServerTokens Prod" гэсэн тохиргоог хийхэд хамгийн бага мэдээлэл өгөх нь. Хэрвээ та Apache ажиллаж байгааг мэдэгдүүлмээргүй байгаа бол эх кодод засвар оруулж дахин compile-дах хэрэгтэй. Үүний тулд include/ap_release.h файлын
#define AP_SERVER_BASEPRODUCT "Apache"
гэсэн мөрийг засах хэрэгтэй.
2. Version hiding in BIND - BIND-н хувьд named.conf файлын options{} directive дотор дараах байдлаар тохиргоог хийнэ.
options {
...
version "D00d!";
... };
3. Version hiding in ProFTP - ProFTP-н хувьд proftpd.conf дотор ServerIdent directive-г ашиглан тохиргоо хийнэ. Default мэндчилгээ, хувилбарын оронд хүссэн мэндчилгээг оруулж болно.
ServerIdent on "MobiNet ISP"
Хэрэв юу ч хэвлэхийг хүсэхгүй бол
ServerIdent off
гэсэн байдлаар тохиргоог хийж болно. Энэ тохиолдолд серверийн домэйн нэрнээс өөр мэдээллийг харуулахгүй.
Obscurity is not security, but... obscurity is a layer of security!
Tuesday, October 17, 2006
Linux Firewalls
SysAdminSummit2006-д илтгэл тавих байсан боловч, монголд байж таараагүй болохоор оролцож чадаагүй билээ. "Unix&Linux Security" талаар сонссон мэдсэнээ хуваалцана гэсэн бодлоо блогоороо дамжуулан хүргэеээ. СисАдминаар ажиллаад 1 жил 6 сар болж байна, туршлага нимгэн болохоор хийж үзсэн гэхээсээ дуулсан, сонссон нь давах тул та бүхэн өршөөгөөрэй. Энэ удаад *nux Firewall-уудын талаар товчхон танилцуулъя.
TCP Wrapper, IPFilter, IPTables/IPChains, PortSentry... гээд Unix төрлийн систем дээр ажилладаг software firewall-уудыг та бүхэн мэдэх байх.
TCP Wrapper, IPFilter, IPTables/IPChains, PortSentry... гээд Unix төрлийн систем дээр ажилладаг software firewall-уудыг та бүхэн мэдэх байх.
TCP Wrapper(IP-based filtering or access control)- хамгийн өргөн тархсан firewall, inetd-тэй хамт ажилладаг, inetd service-үүд бүгд tcpwrapper-р дамжин ажиллана гэсэн үг юм. Жишээ нь: гаднаас FTP connection үүсэхэд inetd ftpd daemon-г дуудаж ажиллуулахын оронд tcpwrapper-г дуудан түүнд бүх эрхийг шилжүүлнэ, tcpwrapper харин тухайн IP-наас FTP connection үүсэхийг зөвшөөрч байвал ftpd daemon-г дуудаж ажиллуулна.
hosts.allow
hosts.deny
гэсэн 2 файлаас access control rule-г авдаг. Дээр бичсэн дарааллаар эхлээд hosts.allow файлыг, дараа нь hosts.deny файлыг уншина. Эдгээр файлын синтаксийг болон rule яаж бичих талаар та бүхэн интернетээс олон материал олж болох тул энэ талаар энд нуршсангүй.
TCP Wrapper-г зөвхөн трафикийг ажиглахын тулд logging mode-нд ажиллуулах нь бас түгээмэл байдаг. Хэрэв та гаднаас зөвшөөрөгдөөгүй хандалтуудыг мэйлээр хүлээн авах хүсэлтэй бол hosts.allow дотор allow statement-үүдээ жагсаан бичээд hosts.deny файлыг дараах байдалтай үүсгэж болох юм.
ALL: ALL: /usr/bin/mailx -s '%s (%p): connection attempted from %n [%a]' admin@mydomain.com
%s - daemon@hostname
%p - process id
%a - IP address of the remote host
%n - hostname of the remote host, or unknown
Энд мэйл явуулахын оронд ямар ч shell code ажиллуулж болно.
advantage:
- маш энгийн, бас олон платформ дээр ажиллах чадвартай/portable.
disadvantage:
- яалт ч үгүй inetd-тэй ажиллахаар бүтээгдсэн. Apache, sendmail, ssh зэрэг stand-alone daemon-уудын хувьд tcpwrapper library-тай хамт compiled-дсанаар tcpwrapper access control-г ашиглах боломжтой болдог.
- UDP болон RPC дээр тулгуурласан service-үүдийн хувьд тохиромжгүй. TCPWrapper-н оронд host-based FW(Жишээ нь: IPFilter...) ашиглах нь дээр.
IPFilter - kernel-based/кернелийн төвшинд ажилладаг, IP болон Transport Layer Header-г хянах боломжтой.
IPFilter-н kernel module-уудаас гадна ipmon daemon хамт ажиллаж байдаг. Энэ daemon нь IPFilter-н үүсгэсэн device-уудыг байнга сонсож message-г ямар нэг лог файлруу эсвэл syslog-руу хөрвүүлж байдаг. Тийм учраас үйлдлийн систем ачаалахад ipmon daemon автоматаар ачаалагдаж байгаа эсэхийг анхаарах хэрэгтэй.
IPFilter нь:
1. packet filtering (/etc/ipf.rules)
2. NAT (/etc/ipf.nat)
гэсэн хоёр үүргийг гүйцэтгэж чадна.
Filtering rules - "last match and exit" гэсэн дүрмээр явагддаг. Cisco ACL дээр ажиллаад сурчихсан улсуудад энэ мэдээж ойлгомжгүй санагдах байх. Гэхдээ quick түлхүүр үгийн тусламжтайгаар "first match and exit" маягаар ажиллуулж болно.
Жишээ 1: Бүх трафикийг зөвшөөрч, логыг харах (/etc/ipf.rules)
pass in log from any to any
pass out log from any to any
Жишээ 2: Гаднаас зөвхөн SSH трафикийг зөвшөөрч, гадагшаа бүх tcp, udp, icmp трафикийг зөвшөөрөн бусад трафикийг хаах (/etc/ipf.rules)
# don't block loopback interface
pass in quick log lo0 all
pass out quick log lo0 all
# Incoming packets: allow ssh, block the rest
pass in log quick proto tcp from any to any port = 22
block in log quick
# Outgoing packets: all allowed
pass out log quick proto tcp all keep state
pass out log quick proto udp all keep state
pass out log quick proto icmp all keep state
keep state - хариуд нь буцаж ирэх packet-г зөьшөөрөх
note: FTP, rlogin, rsh, rcp зэрэг bi-directional socket ашигладаг програмууд дээр заасан ruleset-р ажиллахгүй, ийм төрлийн программыг ажиллуулахын тулд ipnat.rules файл дотор proxy тохиргоо хийж өгөх хэрэгтэй.
# /etc/ipnat.rules
map eth0 eth0/32 -> eth0/32 proxy port ftp ftp/tcp
disadvantage:
- олон платформ дээр ажиллах чадвартай.
- олон NIC-тэй машинийг сүлжээний FW болгон ашиглах боломжтой.
disadvantage:
- kernel module ачаалах хэрэгтэй болдог.
- rule бичиж сурах нь нилээд тэвчээр, туршлага шаарддаг.
Redhat - xinetd дотор IP-based access controlе-г дэмждэг тул тусад нь tcpwrapper суулгах шаардлагагүй.
Linux - Линуксийн хувьд ipfilter-н оронд бэлэн суучихсан ирдэг iptables/ipchains-г ашиглах нь илүү хялбар байдаг.
Solaris - Solaris8/9 хувьд SunScreen Lite, Solaris10 хувьд IPFilter хамт ирдэг болж байгаа.
NetBSD, FreeBSD - IPFilter суусан ирдэг.
OpenBSD - ipfilter-н дараагийн үе болох PF-г ашигладаг.
PortSentry - нь гадны сэжигтэй трафикийг илрүүлэхээс гадна түүний эсрэг арга хэмжээ авах чадвартай, iptables, ipfilter, tcpwrapper болон kernel routing table-д өөрчлөлт хийж сэжигтэй трафикийг хаах арга хэмжээ авч чадна. Хэн нэг хүн порт скан хийж байвал түүнийг exloit хийхээс өмнө өөрийн router-рүү логин хийж орон сүлжээний түвшинд уг трафикийг хаадаг байхаар тохируулж ч бас болох юм байна.
Sunday, October 08, 2006
Security through Obscurity - I (Login banner)
"Obscurity is not security, but... obscurity is a layer of security!" - Монголоор харин "өнгөлөн далдлалт бол нууцлал хамгаалал биш, гэхдээ түүний нэг хэсэг юм" гэчихвэл хэлэх гэсэн санаа нь гараад байна. Юу вэ гэхээр, ач холбогдолгүй гэмээр жижигхэн зүйлс ч нууцлал хамгааллыг хангахад чухал шүү гэсэн санаа...
Энэ удаад та бүхэнд "login banner"-г танилцуулж байна.
Гадны хүн нэвтрэх хориотой газруудад "гадны хүн орохыг хориглоно!", "staff only!" гэсэн бичгүүдийг та бүхэн зөндөө л харсан байх. Энэ нь тухайн газрын дотоод ба гадаад хил хязгаарыг зааглан тогтоож өгч байгаагаас гадна энэ хил хязгаарыг зөвшөөрөлгүй давсан хүнд хариуцлага ноогдуулна гэдгийг маш товчхоноор хэлж өгч байгаа билээ. Хэрвээ ийм бичиг байхгүй байсан бол яах вэ? ... Мэдээж будилж яваа хүмүүс ч юмуу, эсвэл дэмий сониуч хүмүүс орох ёсгүй газарлуу ороод л явчихна гэсэн үг. Тэгхээр "login banner"-г системрүү нэвтэрч байгаа хил хязгаар бүрт тавьж өгөх нь ямар ач холбогдолтой болохыг та бүхэн ойлгосон байх.
Login banner гэхээр дүрэм журам, бүхэл бүтэн нүүр дүүрэн зүйл байх хэрэггүй. Гүйлгээд уншихад, гол нь "unauthorized use is prohibited...", "activities are reported..." гэсэн үгнүүд байхаар бичигдсэн байх хэрэгтэй. Энэ нь "зөвшөөрөлгүй системд нэвтрэхийг хориглоно,хийсэн зүйлүүдийг чинь хуулийн байгууллагад шилжүүлэх эрхтэй" гэсэн санааг агуулж байгаа юм. Би систем дээрээ жишээлбэл:
******************************************************
Authorized uses only!!!
All access to this system is monitored and reported!!!
******************************************************
гэсэн баннер тавьсан. Системрүүгээ орох болгондоо, энэ үгийг уншдаг. Тэгээд жижигхэн ч гэсэн хариуцлага мэдэрч, урдынхаасаа илүү нямбай ажиллах болсон. Харин гадны хэн нэгний хувьд ийм үгстэй тулгарвал хэсэгхэн зуур ч гэсэн тээнэгэлзэж эргэлзэх нь мэдээж...
Харин би анх энэ санаагаа MUG-н нийтэд зориулсан shell server-н login banner-с авсан. Энэ баннерийг бүгдээрээ одоо харцгаая:
Энэ удаад та бүхэнд "login banner"-г танилцуулж байна.
Гадны хүн нэвтрэх хориотой газруудад "гадны хүн орохыг хориглоно!", "staff only!" гэсэн бичгүүдийг та бүхэн зөндөө л харсан байх. Энэ нь тухайн газрын дотоод ба гадаад хил хязгаарыг зааглан тогтоож өгч байгаагаас гадна энэ хил хязгаарыг зөвшөөрөлгүй давсан хүнд хариуцлага ноогдуулна гэдгийг маш товчхоноор хэлж өгч байгаа билээ. Хэрвээ ийм бичиг байхгүй байсан бол яах вэ? ... Мэдээж будилж яваа хүмүүс ч юмуу, эсвэл дэмий сониуч хүмүүс орох ёсгүй газарлуу ороод л явчихна гэсэн үг. Тэгхээр "login banner"-г системрүү нэвтэрч байгаа хил хязгаар бүрт тавьж өгөх нь ямар ач холбогдолтой болохыг та бүхэн ойлгосон байх.
Login banner гэхээр дүрэм журам, бүхэл бүтэн нүүр дүүрэн зүйл байх хэрэггүй. Гүйлгээд уншихад, гол нь "unauthorized use is prohibited...", "activities are reported..." гэсэн үгнүүд байхаар бичигдсэн байх хэрэгтэй. Энэ нь "зөвшөөрөлгүй системд нэвтрэхийг хориглоно,хийсэн зүйлүүдийг чинь хуулийн байгууллагад шилжүүлэх эрхтэй" гэсэн санааг агуулж байгаа юм. Би систем дээрээ жишээлбэл:
******************************************************
Authorized uses only!!!
All access to this system is monitored and reported!!!
******************************************************
гэсэн баннер тавьсан. Системрүүгээ орох болгондоо, энэ үгийг уншдаг. Тэгээд жижигхэн ч гэсэн хариуцлага мэдэрч, урдынхаасаа илүү нямбай ажиллах болсон. Харин гадны хэн нэгний хувьд ийм үгстэй тулгарвал хэсэгхэн зуур ч гэсэн тээнэгэлзэж эргэлзэх нь мэдээж...
Харин би анх энэ санаагаа MUG-н нийтэд зориулсан shell server-н login banner-с авсан. Энэ баннерийг бүгдээрээ одоо харцгаая:
#################################################
# Sign up for a free shell account from ...
# MICOM CO., LTD
#################################################
do not misuse the server for hacking purpose!
Credit to HBX and hairball :)
HBX ба hairball гэж хэн болохыг g0mb0 ах маань хэлж өгөх байх :). Харин энэ сервер дээр ажиллахдаа бусдын эрх ашгийг хүндэтгэхийг энэхүү баннер хэлж өгч байна даа...
login banner хэрхэн тавих вэ?
1. SSH-н хувьд sshd_config файл дотор
Banner /etc/ssh/ssh_banner
мөрийг нэмснээр "/etc/ssh/ssh_banner" гэсэн текст файл доторхийг хэрэглэгч login хийж орохын өмнө дэлгэцэн дээр хэвлэнэ... гэхдээ login prompt дээр username-г бичсэний дараа хэвлэнэ.
2. Unix төрлийн үйлдлийн системд хэрэглэгч логин хийж орсны дараах login banner-г тавиж болно. Үүний тулд "/etc/motd" файл доторхыг өөрчилнө, хэрэв ийм файл байхгүй бол үүсгэж өгнө. Мэдээж хэрэглэгч системд нэвтэрсний дараа гарах баннер учир "орохыг хориглоно" гэсэн үгс байхгүй нь мэдээж. Энд ихэвчлэн хэрэглэгчдэд хандсан сануулга, эсвэл компаний лого, системийн цаг... гэх мэтчилэн юу дуртайгаа оруулж болно.
Obscurity is not security, but... obscurity is a layer of security!
Monday, October 02, 2006
APNIC Training - 28-29 Sep 2006 - DNS Workshop
DNS Workshop-н лабораторийн ажлууд хамгийн сонирхолтой байсан. Тэр дундаа DNS delegation яаж хийдэг юм бол? гэж бодож явдаг байсан бол түүнийгээ хийгээд үзлээ. Мөн RNDC(Remote Name Daemon Controller), TSIG(Transaction signiture) талаар сайн мэддэггүй байсан бол одоо ашиглаж чаддаг боллоо.
DNS Server security & reliability - Хичээл дээр яригдсан DNS Server-н талаарх чухал зүйлсүүд:
security = s, reliability = r
-r- DNS Cервер заавал redundant-тай байх - Энэ мэдээж бүх төрлийн production server-үүдэд хамаарна. DNS-н хувьд master & slave байдлаар зохион байгуулах боломжтой тул zone-н бүртгэлийг хийж байгаа сервер 1 ба түүнээс дээш slave DNS сервертэй байх шаардлагатай.
-sr- Master болон Slave серверүүд тусдаа дэд сүлжээ/subnet-д байрлах - Энд мэдээж Microsoft компаний жишээг дурдаж ярих хүн олон. Энэ удаа ч багш маань дурдаад амжив. Microsoft-н бүх DNS серверүүд нэг дэд сүлжээнд байрласнаас, router дээр тохиргоо хийж байсан ажилтны хайхрамжгүйгээс энэ дэд сүлжээрүү гаднаас хандах боломжгүй болж, улмаар Microsoft-н веб хуудсууд ажиллахгүй болсон байна.
-sr- Authoritative серверээс "forwarder" үүргийг салгах - Энэ нь мэдээж серверийн ачааллыг бодсон хэрэг. Authoritative серверүүд зөвхөн өөрийн мэдэх асуулга/query-д хариу өгч, "caching forwarder" хэрэглэгчдийн бусад асуулга/query-д ,жишээлбэл mail.yahoo.com-н IP-г олох зэрэг, хариу өгнө гэсэн үг юм. Нэг үгээр хэлбэл интернетийн хэрэглэгчиддээ (ISP-н хувьд) "сaching forwarder" DNS Cерверийнхээ IP-г зарлаж, authoritative DNS серверээ нууна гэсэн үг юм. Мэдээж authoritative DNS Серверийг чинь хүн болгон мэдэж байх албагүй.
-s- Authoritative cерверийн zone transfer, zone update-г хязгаарлах - allow-transfer{}, allow-update{} directive-үүдийг ашиглан хязгаарлалт хийх боломжтой. Default-р zone transfer хийх нээлттэй байдаг тул зөвхөн өөрийн slave серверт zone transfer хийх эрхийг олгон бусдад хаах шаардлагатай болохыг манай админууд анхаарна уу.
-s- Dynamic zone transfer & update хийхдээ TSIG ашиглах - Хуурамч IP хаягаар DNS cерверийг хууран zone transfer&update хийх нөхцөлийг хаах үүднээс encrypt-лэгдсэн түлхүүр үгийн тусламжтайгаар authorization хийнэ гэсэн үг юм. TSIG амжилттай ажиллахын тулд 2 серверийн цагууд 5 минутаас багагүй зөрөөтэй ажиллаж байх ёстойг анхаараарай.
-sr- Recursive cерверийг зөвхөн өөрийн хэрэглэгчдийн subnet-д зөвшөөрөх - open recursive server нь cache snooping attack-д өртдөг тул өөрийн хэрэглэгчдийн subnet-с гадуур ирэх query-г хязгаарлах хэрэгтэй. Үүний тулд allow-query{} directive-г ашиглана. Ингэснээр гадны халдлагаас хамгаалах төдийгүй серверийн ачааллыг ихэсгэхгүй байх давуу талтай юм. Зүйрлэж хэлбэл энэ нь open relay mail server-тэй адил шаардлагагүй трафикийг өөрөөрөө дамжуулж байна гэсэн үг юм.
-sr- Системийн логыг бичих - (Бүх production server-үүдэд хамаарна). BIND дээр category{}, channel{} directive-үүдийг ашиглан лог-г ангилж бүртгэх боломжтой байдаг. Сервер гадны халдлагад өртөх, хэвийн ажиллагаа доголдох зэрэгт лог л ганц аврана шүү дээ.
Дээрх үндсэн зүйлсээс гадна nslookup, dig зэрэг командуудыг эзэмших, гаднаас серверээ удирдах rndc программтай ажиллаж дадах зэрэг зайлшгүй сурах зүйлс байгааг манай сисадминууд анхаарна бизээ...
DNS Server security & reliability - Хичээл дээр яригдсан DNS Server-н талаарх чухал зүйлсүүд:
security = s, reliability = r
-r- DNS Cервер заавал redundant-тай байх - Энэ мэдээж бүх төрлийн production server-үүдэд хамаарна. DNS-н хувьд master & slave байдлаар зохион байгуулах боломжтой тул zone-н бүртгэлийг хийж байгаа сервер 1 ба түүнээс дээш slave DNS сервертэй байх шаардлагатай.
-sr- Master болон Slave серверүүд тусдаа дэд сүлжээ/subnet-д байрлах - Энд мэдээж Microsoft компаний жишээг дурдаж ярих хүн олон. Энэ удаа ч багш маань дурдаад амжив. Microsoft-н бүх DNS серверүүд нэг дэд сүлжээнд байрласнаас, router дээр тохиргоо хийж байсан ажилтны хайхрамжгүйгээс энэ дэд сүлжээрүү гаднаас хандах боломжгүй болж, улмаар Microsoft-н веб хуудсууд ажиллахгүй болсон байна.
-sr- Authoritative серверээс "forwarder" үүргийг салгах - Энэ нь мэдээж серверийн ачааллыг бодсон хэрэг. Authoritative серверүүд зөвхөн өөрийн мэдэх асуулга/query-д хариу өгч, "caching forwarder" хэрэглэгчдийн бусад асуулга/query-д ,жишээлбэл mail.yahoo.com-н IP-г олох зэрэг, хариу өгнө гэсэн үг юм. Нэг үгээр хэлбэл интернетийн хэрэглэгчиддээ (ISP-н хувьд) "сaching forwarder" DNS Cерверийнхээ IP-г зарлаж, authoritative DNS серверээ нууна гэсэн үг юм. Мэдээж authoritative DNS Серверийг чинь хүн болгон мэдэж байх албагүй.
-s- Authoritative cерверийн zone transfer, zone update-г хязгаарлах - allow-transfer{}, allow-update{} directive-үүдийг ашиглан хязгаарлалт хийх боломжтой. Default-р zone transfer хийх нээлттэй байдаг тул зөвхөн өөрийн slave серверт zone transfer хийх эрхийг олгон бусдад хаах шаардлагатай болохыг манай админууд анхаарна уу.
-s- Dynamic zone transfer & update хийхдээ TSIG ашиглах - Хуурамч IP хаягаар DNS cерверийг хууран zone transfer&update хийх нөхцөлийг хаах үүднээс encrypt-лэгдсэн түлхүүр үгийн тусламжтайгаар authorization хийнэ гэсэн үг юм. TSIG амжилттай ажиллахын тулд 2 серверийн цагууд 5 минутаас багагүй зөрөөтэй ажиллаж байх ёстойг анхаараарай.
-sr- Recursive cерверийг зөвхөн өөрийн хэрэглэгчдийн subnet-д зөвшөөрөх - open recursive server нь cache snooping attack-д өртдөг тул өөрийн хэрэглэгчдийн subnet-с гадуур ирэх query-г хязгаарлах хэрэгтэй. Үүний тулд allow-query{} directive-г ашиглана. Ингэснээр гадны халдлагаас хамгаалах төдийгүй серверийн ачааллыг ихэсгэхгүй байх давуу талтай юм. Зүйрлэж хэлбэл энэ нь open relay mail server-тэй адил шаардлагагүй трафикийг өөрөөрөө дамжуулж байна гэсэн үг юм.
-sr- Системийн логыг бичих - (Бүх production server-үүдэд хамаарна). BIND дээр category{}, channel{} directive-үүдийг ашиглан лог-г ангилж бүртгэх боломжтой байдаг. Сервер гадны халдлагад өртөх, хэвийн ажиллагаа доголдох зэрэгт лог л ганц аврана шүү дээ.
Дээрх үндсэн зүйлсээс гадна nslookup, dig зэрэг командуудыг эзэмших, гаднаас серверээ удирдах rndc программтай ажиллаж дадах зэрэг зайлшгүй сурах зүйлс байгааг манай сисадминууд анхаарна бизээ...
Sunday, October 01, 2006
APNIC Training - 27 Sep 2006 - Internet resource management
APNIC-н сургалт Датакомын дэмжлэгтэйгээр 3 хоног амжилттай болж өнгөрлөө. Энэ сургалтанд MobiNet, Micom, MagicNet, RailCom, MCSCom, WirelessCom зэрэг ISP-нуудаас гадна IT-гийн чиглэлээр үйл ажиллагаа явуулдаг, интернетийн үйлчилгээ үзүүлдэг нилээд олон байгууллагын IT-н ажилтнууд оролцлоо. Cургалт "Internet resource management", "DNS workshop" гэсэн 2 чиглэлээр явагдсан ба үр өгөөж ихтэй сайн сургалт болсон гэж би хувьдаа дүгнэж байна. APNIC-с жил бүр монголд сургалт зохион явуулдаг тул энэ удаагийнхад амжаагүй бол дараа заавал нэг суугаад үзээрэй.
Internet resource management - Хичээл эхлэхээс өмнө оролцогч бүр өөрийгөө танилцуулж, энэ сургалтаас юу олж мэдэж авах хүсэлтэй байгаагаа товчхон хэллээ. Миний хувьд "IPv6"-н талаар мөн whois өгөгдлийн санд хэрэглэгчдийнхээ мэдээллийг хэрхэн оруулах вэ? гэсэн асуултын хариуг олж авъя гэсэн бодолтой очсон. Хүмүүсийн ихэнх нь "IPv6", DNS гэсэн хариултыг өгч байлаа.
Эхлээд мэдээж APNIC-н үйл ажиллагаа, бүтэц зохион байгуулалтын талаар товчхон мэдээлэл авлаа. APNIC нь 62 орны 1000 гаруй гишүүдтэй үйл ажиллагаа явуулдаг бөгөөд төв нь Австралийн Брисбен хотод байрладаг. Ази Номхон далайн орнуудын интернет хаяглалтыг бүрэн хариуцаж ажилладаг байгууллага юм. IP хаягаас гадна, DNS reverse delegation, AS number бүртгэх үйлчилгээг үзүүлдэг. APNIC-c шинэ IP хаяглалт авахын тулд байгууллагынхаа хэтийн төлөвлөгөө, сүлжээний зохион байгуулалт, магадгүй санхүүгийн бичиг баримтаар нотолгоо болгосны үндсэн дээр хамгийн багадаа IPv4 бол /21, IPv6 бол /32 хэмжээтэй IP block авах боломжтой юм байна лээ.
Whois database-н хувьд манай ISP-нууд хэрэглэгчдийн мэдээллийг маш хангалтгүй оруулсан харагдсан. Миний хувьд Abuse report-c залхсандаа хэрэглэгчдийнхээ IP Assignment-г бүртгүүлье гэж бодож байсан удаа цөөнгүй. Харин яаж бүртгүүлэх аргаа сайн олоогүй. Ямартай ч одоо MyAPNIC-р эсвэл мэйлээр бүртгүүлж болох боломжтойг мэдэж авлаа. Гэтэл хэрэглэгчдийнхээ нэрс, IP хаягыг зарлах ер нь зөв үү гэсэн асуудалтай тулгараад бүртгүүлэхээ жаахан азнахаар шийдлээ... Энэ талаар бусад админуудтай зөвлөмөөр ч юм шиг...
IPv6 - 128 bit хаяглалт гэхээр мэдээж замбараагүй их тоо гарч байна. Зүйрлэж хэлбэл одоо хэрэглэж байгаа IPv4 IP хаягыг 4 залгаад биччихсэнтэй тэнцэхээр тийм урт хаяг гэсэн үг... Энэ их IP хаягаар юугаа хийдэг байнаа?... тэгсэн бүх "intellligent" гэр ахуйн хэрэгсэл IP хаягтай болж байгаа юм байна. Япон, Солонгост IPv6 дэмждэг гэр ахуйн хэрэгслүүд аль хэдийн худалдаанд гарсан гэнэ. Энд багшийн авсан жишээг дурдвал: taxi-ны бүх шил арчигчид IP хаягтай болбол хаана бороо орж байгааг төврүүгээ мэдээлэх боломжтой болох юм байна. Ингэснээр бороо орж байгаа дүүрэгрүү илүү олон taxi явуулна... бодоод байсан үнэхээр хэрэгтэй байгаа биз.
IPv4 IP хаягнууд дуусаж байгаа тул IPv6-руу шилжих болсон гэж гэнэхэн бодолтой явж байсан үгүй юм байна лээ. IPv4-н тал гаруй хувийг ямар ч гэрээ хийлгүйгээр 2хон жилийн дотор тараачихсан нь жаахан асуудал хэвээрээ байгаа хэдий ч, "ирээдүйгээ харж" IPv6-г бий болгосон тухай ойлгож авлаа. Бас нэг зүйл гэвэл IPv6-д private network хаяг гэж байхгүй, яагаад гэвэл private хаягны шаардлага байхгүйгээр хангалттай IP хаяг байгаа...
IPv4-c IPv6-руу хэрхэн шилжих вэ? Хэд хэдэн арга байгаан байна.
1. Dual Stack transition - Нэг төхөөрөмж дээр IPv4, IPv6 зэрэг орших боломжийг олгох
2. Tunneling - IPv4 дээгүүр IPv6-г тунелээр дамжуулах - (Dual Stack дэмждэг router ашиглан гараар тохиргоог хийх маягаар, эсвэл гадны tunnel broker ашиглан тохиргоог хийх маягаар хэрэгжүүлж болно)
3. Translation - зөвхөн IPv4, IPv6 дэмждэг төхөөрөмжүүдийг хамтран ажилладаг болгох
Бас нэг сонирхолтой мэдээлэл: 1998 оноос хойш 8 жил үргэлжилсэн IPv6-г хэрэглээнд нэвтрүүлэх зорилготой KAME төсөл саяхан дуусаж IPv6 protocol stack-г нийтэд түгээхэд бэлэн болгосон байна. IPv6 protocol stack-г эх кодын хамт удахгүй BSD License-н дор BSD үйлдлийн системд өгөх бодолтой байгаа бөгөөд одоогоор KAME-н функцүүдийг BSD үйлдлийн систем дээр нэгтгэх ажил үлдээд байгаан байна.
Internet resource management - Хичээл эхлэхээс өмнө оролцогч бүр өөрийгөө танилцуулж, энэ сургалтаас юу олж мэдэж авах хүсэлтэй байгаагаа товчхон хэллээ. Миний хувьд "IPv6"-н талаар мөн whois өгөгдлийн санд хэрэглэгчдийнхээ мэдээллийг хэрхэн оруулах вэ? гэсэн асуултын хариуг олж авъя гэсэн бодолтой очсон. Хүмүүсийн ихэнх нь "IPv6", DNS гэсэн хариултыг өгч байлаа.
Эхлээд мэдээж APNIC-н үйл ажиллагаа, бүтэц зохион байгуулалтын талаар товчхон мэдээлэл авлаа. APNIC нь 62 орны 1000 гаруй гишүүдтэй үйл ажиллагаа явуулдаг бөгөөд төв нь Австралийн Брисбен хотод байрладаг. Ази Номхон далайн орнуудын интернет хаяглалтыг бүрэн хариуцаж ажилладаг байгууллага юм. IP хаягаас гадна, DNS reverse delegation, AS number бүртгэх үйлчилгээг үзүүлдэг. APNIC-c шинэ IP хаяглалт авахын тулд байгууллагынхаа хэтийн төлөвлөгөө, сүлжээний зохион байгуулалт, магадгүй санхүүгийн бичиг баримтаар нотолгоо болгосны үндсэн дээр хамгийн багадаа IPv4 бол /21, IPv6 бол /32 хэмжээтэй IP block авах боломжтой юм байна лээ.
Whois database-н хувьд манай ISP-нууд хэрэглэгчдийн мэдээллийг маш хангалтгүй оруулсан харагдсан. Миний хувьд Abuse report-c залхсандаа хэрэглэгчдийнхээ IP Assignment-г бүртгүүлье гэж бодож байсан удаа цөөнгүй. Харин яаж бүртгүүлэх аргаа сайн олоогүй. Ямартай ч одоо MyAPNIC-р эсвэл мэйлээр бүртгүүлж болох боломжтойг мэдэж авлаа. Гэтэл хэрэглэгчдийнхээ нэрс, IP хаягыг зарлах ер нь зөв үү гэсэн асуудалтай тулгараад бүртгүүлэхээ жаахан азнахаар шийдлээ... Энэ талаар бусад админуудтай зөвлөмөөр ч юм шиг...
IPv6 - 128 bit хаяглалт гэхээр мэдээж замбараагүй их тоо гарч байна. Зүйрлэж хэлбэл одоо хэрэглэж байгаа IPv4 IP хаягыг 4 залгаад биччихсэнтэй тэнцэхээр тийм урт хаяг гэсэн үг... Энэ их IP хаягаар юугаа хийдэг байнаа?... тэгсэн бүх "intellligent" гэр ахуйн хэрэгсэл IP хаягтай болж байгаа юм байна. Япон, Солонгост IPv6 дэмждэг гэр ахуйн хэрэгслүүд аль хэдийн худалдаанд гарсан гэнэ. Энд багшийн авсан жишээг дурдвал: taxi-ны бүх шил арчигчид IP хаягтай болбол хаана бороо орж байгааг төврүүгээ мэдээлэх боломжтой болох юм байна. Ингэснээр бороо орж байгаа дүүрэгрүү илүү олон taxi явуулна... бодоод байсан үнэхээр хэрэгтэй байгаа биз.
IPv4 IP хаягнууд дуусаж байгаа тул IPv6-руу шилжих болсон гэж гэнэхэн бодолтой явж байсан үгүй юм байна лээ. IPv4-н тал гаруй хувийг ямар ч гэрээ хийлгүйгээр 2хон жилийн дотор тараачихсан нь жаахан асуудал хэвээрээ байгаа хэдий ч, "ирээдүйгээ харж" IPv6-г бий болгосон тухай ойлгож авлаа. Бас нэг зүйл гэвэл IPv6-д private network хаяг гэж байхгүй, яагаад гэвэл private хаягны шаардлага байхгүйгээр хангалттай IP хаяг байгаа...
IPv4-c IPv6-руу хэрхэн шилжих вэ? Хэд хэдэн арга байгаан байна.
1. Dual Stack transition - Нэг төхөөрөмж дээр IPv4, IPv6 зэрэг орших боломжийг олгох
2. Tunneling - IPv4 дээгүүр IPv6-г тунелээр дамжуулах - (Dual Stack дэмждэг router ашиглан гараар тохиргоог хийх маягаар, эсвэл гадны tunnel broker ашиглан тохиргоог хийх маягаар хэрэгжүүлж болно)
3. Translation - зөвхөн IPv4, IPv6 дэмждэг төхөөрөмжүүдийг хамтран ажилладаг болгох
Бас нэг сонирхолтой мэдээлэл: 1998 оноос хойш 8 жил үргэлжилсэн IPv6-г хэрэглээнд нэвтрүүлэх зорилготой KAME төсөл саяхан дуусаж IPv6 protocol stack-г нийтэд түгээхэд бэлэн болгосон байна. IPv6 protocol stack-г эх кодын хамт удахгүй BSD License-н дор BSD үйлдлийн системд өгөх бодолтой байгаа бөгөөд одоогоор KAME-н функцүүдийг BSD үйлдлийн систем дээр нэгтгэх ажил үлдээд байгаан байна.
Friday, September 22, 2006
Accessing remote Linux desktop from Windows over SSH
Линукс десктопруу гаднаас хандах шаардлага гарлаа. Тэр нь офисоос маань 1км цаана байгаа серверийн өрөөрүү гүйхгүй гэсэндээ л тэр шүү дээ. "google is your best friend!" гэж Nuunee-гийн хэлснээр баахан google-длээ. Ер нь өөрт тулгарсан асуудлын 90%-г google-с хайж шийддэг болохоор нэг ч их бэрхшээлтэй ажил биш байлаа. Мэдээж энэ баахан эмх замбараагүй мэдээллийг буцааж эвлүүлж хэрэгтэй зүйлээ босгож авах гэдэг л их цаг зарсан ажил байна. Гэхдээ зүгээрээ тэр хирээрээ шинэ сонин зүйлсийг сурах болно...
За гол асуудалдаа оръё. Эхлээд "X11 Forwarding"-г туршаад гацчихсан тул болиод VNC-г туршиж үзлээ. Нилээд нухсаны эцэст VNC болсон, энэ удаад түрүүн гацсан алдаагаа ч олов. Ингээд дээрх 2 аргаар линукс десктопруу гаднаас хандах аргыг доор бичлээ.
Windows дээр ажилладаг хэд хэдэн ssh client программ байдаг бөгөөд хамгийн өргөн хэрэглэгддэг Putty ашиглан дараах байдлаар Линукс десктопруу хандана.
1. X11 Forwaring - буюу X11 tunneling ч гэж нэрлэгддэг. Энгийн tunnel-тэй адил бөгөөд ганц ялгаа нь тухайн машинруу ssh-р логин хийж ороход ssh таны өмнөөс DISPLAY хувьсагчийн утгыг оноож, таны сууж байгаа машинруу чинь зааж өгнө. Таны PC дээр Putty(X11 tunnel-г дэмждэг байх ёстой), мөн хүлээж авсан мэдээллийг танд дэлгэцэнд харуулахын тулд X Server суусан байх хэрэгтэй. Windows platform дээр ажилладаг X-Win32 программыг ашиглаж болно. HostА->HostB (A-с B-рүү) хандаж байна гэж үзвэл.
2.3 VNC Серверийг ажиллуулахад тухайн хэрэглэгчийн хувьд $HOME/.vnc/xstartup файл үүсэх бөгөөд энэ файл дотор десктоп дээр ажиллах программыг тохируулна.
#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &
Хамгийн сүүлийн мөрний оронд өөрийн тохирох WM-г сольж бичнэ. Gnome бол gnome-session гэж бичнэ.
2.4 VNCViewer программыг ажиллуулан "server" дээр "localhost:5900" гэж бичин холбогдоно. Одоо танаас нууц үгийг чинь асуух болно.
... EVRICA!!! ... танил дэлгэц чинь гарч ирнэ.
PS: Дээр дурдсан жишээнээс гадна SSH Tunnel-г ашиглан TCP/IP протоколоор ажилладаг бүх төрлийн service-үүдрүү хандаж болно. Жишээ нь гаднаас хандалтгүй серверээс мэйлээ шалгах... Хамгийн гол нь бүх траффик SSH-р кодлогдон дамжих тул нууцлал хамгаалал сайтай.
Та нар ч гэсэн туршаад үзээрэй.
За гол асуудалдаа оръё. Эхлээд "X11 Forwarding"-г туршаад гацчихсан тул болиод VNC-г туршиж үзлээ. Нилээд нухсаны эцэст VNC болсон, энэ удаад түрүүн гацсан алдаагаа ч олов. Ингээд дээрх 2 аргаар линукс десктопруу гаднаас хандах аргыг доор бичлээ.
Windows дээр ажилладаг хэд хэдэн ssh client программ байдаг бөгөөд хамгийн өргөн хэрэглэгддэг Putty ашиглан дараах байдлаар Линукс десктопруу хандана.
1. X11 Forwaring - буюу X11 tunneling ч гэж нэрлэгддэг. Энгийн tunnel-тэй адил бөгөөд ганц ялгаа нь тухайн машинруу ssh-р логин хийж ороход ssh таны өмнөөс DISPLAY хувьсагчийн утгыг оноож, таны сууж байгаа машинруу чинь зааж өгнө. Таны PC дээр Putty(X11 tunnel-г дэмждэг байх ёстой), мөн хүлээж авсан мэдээллийг танд дэлгэцэнд харуулахын тулд X Server суусан байх хэрэгтэй. Windows platform дээр ажилладаг X-Win32 программыг ашиглаж болно. HostА->HostB (A-с B-рүү) хандаж байна гэж үзвэл.
1.1 X-Win32-г тохируулах - "Configuration/Security" ороод HostB-г зөвшөөрч өгөөд X-Win32 серверийг ажиллуулж орхино.
1.2 Putty-г тохируулах - "Session/Host name" дээр HostB-г бичнэ. "Connection/SSH/Tunnels" эсвэл "Connection/SSH/X11" дээр "Enable X11 forwarding" хэсгийг чагтлан, "X Display location" дээр "IP address:display" гэсэн форматаар "HostА:0" гэж бичнэ. Ихэнх тохиолдолд display=0 утгыг авдаг тул та ямар нэг тохиргоог өөрчлөөгүй бол энэ байдлаар ажиллах ёстой.
1.3 Одоо Putty ашиглан ssh-r HostB-рүү хандан холбогдоно. Тохиргоо зөв байгаа эсэхийг шалгахын тулд ямар нэг X11 application, жишээ болгож xclock-г ажиллуулъя. (Ихэвчлэн /usr/X11R6/bin дотор байрлана)
# xclock &
Дэлгэцэн дээр жижиг цонхонд цаг гарч ирэх ёстой. Хэрэв гарч ирэхгүй бол DISPLAY хувьсагчийн утгыг шалгаж үзээрэй.
# echo $DISPLAY
Хэрэв энэ утга "HostA:0.0" биш бол гараар утгыг оноож өгнө. Миний хувьд энэ хэсэг дээр нилээд цаг алдсан ба DISPLAY хувьсагчийн утгыг дараах байдлаар онооно:
# export DISPLAY=HostA:0.0
За одоо ямар ч байсан цаг гарч ирсэн гэж найдъя.
1.4 HostB ямар төрлийн windows manager дэмждэг вэ?
Gnome бол :
# gnome-session
KDE бол :
# startkde &
командыг өгөхөд... EVRICA!!! ... танил дэлгэц чинь гарч ирнэ.
Дээрхээс гадна icewm-session, x-window-manager, twm командуулыг өгч бусад wm-үүдийг туршаад үзээрэй.
2. VNC - Хандах гэж байгаа машин дээр VNC Cервер суусан байх ёстой. Мөн PC дээрээ VNCViewer суулгана.
2.1 VNC Серверийг ажиллуулахын тулд хамгийн багадаа нэг хэрэглэгч нэмэх хэрэгтэй. Тохиргоог /etc/sysconfig/vncservers дотор дараах байдлаар хийнэ.
VNCSERVERS="1:baynaa"
VNCSERVERARGS[1]="-geometry 1024x768 -depth 16"
VNC Cервер энд зааж өгсөн тохиолдол тус бүрт өөр өөр порт дээр сонсох бөгөөд манай тохиолдолд 5900+1 буюу 5901-р порт дээр холбогдоно гэсэн үг юм.
2.2 VNC Cерверрүү холбогдох user shell-рүү орон доорх командыг өгч нууц үгийг идэвхжүүлнэ.
# vncpasswd2.3 VNC Серверийг ажиллуулахад тухайн хэрэглэгчийн хувьд $HOME/.vnc/xstartup файл үүсэх бөгөөд энэ файл дотор десктоп дээр ажиллах программыг тохируулна.
#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &
Хамгийн сүүлийн мөрний оронд өөрийн тохирох WM-г сольж бичнэ. Gnome бол gnome-session гэж бичнэ.
2.4 VNCViewer программыг ажиллуулан "server" дээр "localhost:5900" гэж бичин холбогдоно. Одоо танаас нууц үгийг чинь асуух болно.
... EVRICA!!! ... танил дэлгэц чинь гарч ирнэ.
PS: Дээр дурдсан жишээнээс гадна SSH Tunnel-г ашиглан TCP/IP протоколоор ажилладаг бүх төрлийн service-үүдрүү хандаж болно. Жишээ нь гаднаас хандалтгүй серверээс мэйлээ шалгах... Хамгийн гол нь бүх траффик SSH-р кодлогдон дамжих тул нууцлал хамгаалал сайтай.
Та нар ч гэсэн туршаад үзээрэй.
Thursday, August 31, 2006
SysAdmin Summit - 2006 болон энэ хүртэлх бидний зам
2006 оны 1 сарын 5-нд MUG-н анхны шар айрагны үдэшлэг болж юникс сонирхогчид уулзацгааж билээ. Ажлын төлөвлөгөөгөө бичдэг дэвтэрт маань дурайтал бичээтэй байгаа болохоор би он сарыг нь ч тод санаж байна. Цагаасаа яльгүй эрт очоод үүдэнд жаахан тээнэгэлзэж зогссоноо санаж байна. Мэдээж цагаасаа өмнө ирсэн нилээд хэдэн хүн байсан. Ингээд л энэ MUG гэдэг айлынхан сар бүр уулзаж, юникс үйлдлийн системийг, чухамдаа GPL(General Public License)-н үзэл санааг монголдоо хэрхэн түгээн дэлгэрүүлэх, улс эх орныхоо хөгжилд хувь нэмрээ оруулах талаар ярилцдаг болсон. Мэдээж хийх юм маш их байсан болохоор тэрийг ч хийе, энийг ч хийе гэж эхлээд нилээдгүй маргацгаасан. Тэгээд Дөлөө маань Install Fest гэж арга хэмжээ байдаг, түүнийг зохиоё гэсэн санаа гаргасан. Дөлөөгийн маань өөртөө итгэлтэй байдал нөлөөлсөн байх, юу ч хамаагүй нэг юмнаас эхлэх хэрэгтэй гэж хүмүүсийн санаа ч нэгдсэн байх ингээд л 3 сарын шар айрагны үдэшлэг дээр анхны Install Fest-г зохиохоор тогтсон. 20 хүрэхгүй хоногт бэлтгэл ажлаа дуусган 4 сарын 7-ны өдөр анхны арга хэмжээ маань болж өнгөрсөн. Анхных гэхэд миний л бодлоор үнэхээр сайн болсон. Хүмүүс орж гарч байсан хэдий ч ITPark-н хурлын заал дүүрэн байсан нь мартагдамгүй. Дотор зааланд илтгэлүүд тавигдаж, гадаах хонгилд эгнүүлэн тавьсан компьютерүүд дээр линукс тархацуудыг хүмүүс сонирхож, цаадхан талд нь өөрийн PC-г авчран линукс суулгаж байгаа залуучууд харагдана. Ийм л дүр зураг үлджээ.
Тиймээ одоо дараагийн арга хэмжээ SysAdmin Summit 2006. Аль 6 сараас хойш дуншиж 9 сарын 12-нд болохоор эцэслэн тогтлоо. Энд жинхэнэ мэргэжлийн хүмүүс цуглах болохоор чанар чансаатай сайн хийе гэснээс товоо хэд хэд хойшлуулаад авсан. Бас ч дээд албан тушаалын хүмүүс уригдан ирэх учир тохь тухтайг бодон зочид буудалд, цайны завсарлагатайгаар хийхээр боллоо. SAS2006 логотой T-shirt өмсөөд, мэргэжил нэгт анд нөхдийнхөө илтгэлийг сонсоод сууж байна гэдэг монголд байгаа сисадминуудын маань мөрөөдөл байх нь дамжиггүй. Миний хувьд л лав энэ бол хэдхэн жилийн өмнө мөрөөдөж байсан мөрөөдлийн маань нэг байлаа. Хувийн ажлаар гадаадад зорчих болсон болохоор 9 сарын 12-ны өдөр монголд байж таарахгүй нь. Хэдийгээр өөрөө хуралд оролцож чадахгүй ч тэр мөрөөдөл маань биелсэн. Юникс сонирхогчид та бүхэн энэ боломжийг битгий алдаарай. SAS2006-д оролцож хүсэл мөрөөдлөө биелүүлээрэй.
Нийт MUG-н хамт олон болон Дөлөөдөө амжилт хүсье.
Та нар шүү!!!
Тиймээ одоо дараагийн арга хэмжээ SysAdmin Summit 2006. Аль 6 сараас хойш дуншиж 9 сарын 12-нд болохоор эцэслэн тогтлоо. Энд жинхэнэ мэргэжлийн хүмүүс цуглах болохоор чанар чансаатай сайн хийе гэснээс товоо хэд хэд хойшлуулаад авсан. Бас ч дээд албан тушаалын хүмүүс уригдан ирэх учир тохь тухтайг бодон зочид буудалд, цайны завсарлагатайгаар хийхээр боллоо. SAS2006 логотой T-shirt өмсөөд, мэргэжил нэгт анд нөхдийнхөө илтгэлийг сонсоод сууж байна гэдэг монголд байгаа сисадминуудын маань мөрөөдөл байх нь дамжиггүй. Миний хувьд л лав энэ бол хэдхэн жилийн өмнө мөрөөдөж байсан мөрөөдлийн маань нэг байлаа. Хувийн ажлаар гадаадад зорчих болсон болохоор 9 сарын 12-ны өдөр монголд байж таарахгүй нь. Хэдийгээр өөрөө хуралд оролцож чадахгүй ч тэр мөрөөдөл маань биелсэн. Юникс сонирхогчид та бүхэн энэ боломжийг битгий алдаарай. SAS2006-д оролцож хүсэл мөрөөдлөө биелүүлээрэй.
Нийт MUG-н хамт олон болон Дөлөөдөө амжилт хүсье.
Та нар шүү!!!
Friday, August 18, 2006
Spam шаналгаа
За ёстой энэ спам нэг шаналгаа болж байнаа. Бодвол хэрэглэгчдийн бухимдлыг бүр их хүргэдэг байх. SpamAssassin-3.1.4 шинэ хувилбар хүртэл upgrade хийж үзлээ. Онцын өөрчлөлт гарсангүй. Харин rblsmtpd-н RBL(Realtime Black List)-н тоогоо нэмж үзье гэж бодогдлоо. Одоо хэрэглэж байгаа RBL-ууд ямар ч байсан хангалтгүй байна. Тэгээд дараах RBL-үүдийг интернетээс хайж олоод нэмсэн.
bl.csma.biz
bl.spamcop.net
bl.spam-trap.net
blackhole.securitysage.com
blackholes.easynet.nl
blackholes.mail-abuse.org
blacklist.jippg.org
cbl.abuseat.org
combined.njabl.org
dev.null.dk
dnsbl.ahbl.org
dnsbl.sorbs.net
dsn.rfc-ignorant.org
dul.dnsbl.sorbs.net
dynablock.easynet.nl
list.dsbl.org
multihop.dsbl.org
opm.blitzed.org
proxies.blackholes.easynet.nl
psbl.surriel.com
relays.ordb.org
sbl.spamhaus.org
sbl-xbl.spamhaus.org
unconfirmed.dsbl.org
Ингээд нэг үзсэн гаднаас ирж байгаа мэйлийн тоо бараг 4 дахин багассан. Спам мэйл ч эрс цөөрсөн байна. Та нар ч гэсэн хэрэглээд үзээрэй. Мэдээж мэйл сервер дээр чинь SMTP connection үүсэх болгонд дээрх RBL-үүдээс хайлт хийх болохоор мэйл серверийн ачаалал ихсэх байх. Гэхдээ спам явуулж байгаа серверүүдээс connection үүсэх үед нь хаадаг болохоор спамаас хамгаалах хамгийн сайн аргуудын нэг юм шүү.
bl.csma.biz
bl.spamcop.net
bl.spam-trap.net
blackhole.securitysage.com
blackholes.easynet.nl
blackholes.mail-abuse.org
blacklist.jippg.org
cbl.abuseat.org
combined.njabl.org
dev.null.dk
dnsbl.ahbl.org
dnsbl.sorbs.net
dsn.rfc-ignorant.org
dul.dnsbl.sorbs.net
dynablock.easynet.nl
list.dsbl.org
multihop.dsbl.org
opm.blitzed.org
proxies.blackholes.easynet.nl
psbl.surriel.com
relays.ordb.org
sbl.spamhaus.org
sbl-xbl.spamhaus.org
unconfirmed.dsbl.org
Ингээд нэг үзсэн гаднаас ирж байгаа мэйлийн тоо бараг 4 дахин багассан. Спам мэйл ч эрс цөөрсөн байна. Та нар ч гэсэн хэрэглээд үзээрэй. Мэдээж мэйл сервер дээр чинь SMTP connection үүсэх болгонд дээрх RBL-үүдээс хайлт хийх болохоор мэйл серверийн ачаалал ихсэх байх. Гэхдээ спам явуулж байгаа серверүүдээс connection үүсэх үед нь хаадаг болохоор спамаас хамгаалах хамгийн сайн аргуудын нэг юм шүү.
Friday, August 11, 2006
g0mb0 ахдаа баярлалаа
Өчигдөр 8 сарын 10, "Юникс шар айрагны үдэшлэг" дээр MUG-ынхан уулзлаа. Энэ удаа ихэнх яриа маань нууцлал хамгааллын талаар болж өнгөрсөн. Дөлөө, Буянзаяа, Тэлмэн, Эрхэмээ тэгээд g0mb0 ах ирсэн юм байна. g0mb0 ах тэгсэн яриан дундаа "buffer overflow-ын талаар хэдэн хуучин paper байгаа" гэсэн санагдаж байна. Яриа тэгээд л өнгөрсөн. Өнөөдөр харин санаандгүй g0mb0 ахын paper-үүдийн хаягыг авлаа. (Баруун талд Links хэсэгт нэмсэн байгаа)
Үнэхээр гайхалтай. buffer overflow-ын талаар монголоор ийм ойлгомжтой, өндөр түвшинд нарийн тайлбарласан хуудас олж харж байгаагүй. Юникс ба Линуксын үүсэл хөгжил, Нууцлал хамгааллын талаарх бусад хуудсуудыг ч бас олж уншлаа. Энэ хуудсууд 2001 онд, одоогоос бүтэн 5 жилийн өмнө бичигдэж... гэхдээ миний өдийг хүртэл олж мэдээгүй байсан зүйлс байх юм. Ер нь бодоод байсан g0mb0 ах шиг олон жил ажилласан, туршлагатай сисадмин монголд лав байхгүйн байна. Тэгээд бас MUG...
Ер нь MUG-г анхлан санаачилж, веб хуудсыг хөтлөн, list.mng.net мэйлинг листээр мэдээ явуулж, энэ байгууллагыг өдий болтол бөөцийлж ирсэн хүн бол яах аргагүй g0mb0 ах юм. 2005 оны 4 сард би анх сисадминаар ажилд ороод list.mng.net-д бүртгүүлж нууцлал хамгаалал болон юникс сонирхогчдийн мэйлийн листээс мэйл хүлээн авч эхэлсэн. Долоо хоногт нилээд хэдэн удаа тогтмол сонирхолтой мэйлүүд ирдэг байсан. Миний мэдэхийн g0mb0 ах л бүгдийг бичдэг байж дээ. Тэгээд дараа нь веб хуудас маань илүү идэвхтэй ажиллаж эхэлснээс мэдээнүүд тэнд тавигддаг болжээ.
Юникс сонирхогчид нэгдэн нийлж, хөгжин дэвжихэд MUG-ын оруулсан хувь нэмэр угтаа g0mb0 ахын маань хувь нэмэр дэндүү их юмаа.
g0mb0 ахдаа баярлалаа.
MUG-ын хамт олноос...
Үнэхээр гайхалтай. buffer overflow-ын талаар монголоор ийм ойлгомжтой, өндөр түвшинд нарийн тайлбарласан хуудас олж харж байгаагүй. Юникс ба Линуксын үүсэл хөгжил, Нууцлал хамгааллын талаарх бусад хуудсуудыг ч бас олж уншлаа. Энэ хуудсууд 2001 онд, одоогоос бүтэн 5 жилийн өмнө бичигдэж... гэхдээ миний өдийг хүртэл олж мэдээгүй байсан зүйлс байх юм. Ер нь бодоод байсан g0mb0 ах шиг олон жил ажилласан, туршлагатай сисадмин монголд лав байхгүйн байна. Тэгээд бас MUG...
Ер нь MUG-г анхлан санаачилж, веб хуудсыг хөтлөн, list.mng.net мэйлинг листээр мэдээ явуулж, энэ байгууллагыг өдий болтол бөөцийлж ирсэн хүн бол яах аргагүй g0mb0 ах юм. 2005 оны 4 сард би анх сисадминаар ажилд ороод list.mng.net-д бүртгүүлж нууцлал хамгаалал болон юникс сонирхогчдийн мэйлийн листээс мэйл хүлээн авч эхэлсэн. Долоо хоногт нилээд хэдэн удаа тогтмол сонирхолтой мэйлүүд ирдэг байсан. Миний мэдэхийн g0mb0 ах л бүгдийг бичдэг байж дээ. Тэгээд дараа нь веб хуудас маань илүү идэвхтэй ажиллаж эхэлснээс мэдээнүүд тэнд тавигддаг болжээ.
Юникс сонирхогчид нэгдэн нийлж, хөгжин дэвжихэд MUG-ын оруулсан хувь нэмэр угтаа g0mb0 ахын маань хувь нэмэр дэндүү их юмаа.
g0mb0 ахдаа баярлалаа.
MUG-ын хамт олноос...
Monday, July 17, 2006
SANFIRE2006 - Washington DC
SANFIRE2006-д амжилттай оролцоод ирлээ. Манай ангийн багш Hal Pomeranz систем админаар 15 жил ажилласан, SysAdmin сэтгүүлийн техникийн редактор, одоогоор системийн нууцлал хамгааллаар зөвлөгөө өгдөг DeerRun гээд хувийн консалтинг компанидаа ажилладаг хүн байсан. Хичээлүүд практик мэдлэг дээр тулгуурласан байсан болохоор, хичээлээ дуусаад сурсан зүйлсээ туршиж үзмээр санагдаж байсан шүү.
Өдөр бүр хичээл дээр дасгал хийж байсан нь хичээлийг ойлгоход илүү дөхөм болсон байх. Гэхдээ л 6 хоногт ахдахаар их мэдээллийг багтаасан байсан нь сурч мэдэх юм их байна даа гэсэн сэтгэлийг минь улам хүчтэй болгож байлаа.
Энэ сургалтанд нийт зөвхөн суралцагч 860 орчим хүн оролцсон бөгөөд, үүнээс ердөө 40 хүрэхгүй нь гадаадаас ирсэн хүмүүс байлаа. Америкаас оролцож байгаа хүмүүс дотор 2-3 дахь удаагаа оролцож байгаа хүмүүс ч байсан. Компани нь ч ажилтнуудаа сургалтанд суулгаж, мэдлэг мэргэжлийг нь дээшлүүлэхэд их анхаардаг санагдсан.
SANS өөрийн GIAC Certificate-г санал болгодог бөгөөд үйлдлийн систем, салбараасаа хамаараад 23 төрлийн сертификат өгдөг юм билээ. Шалгалт нь 2 хэсгээс бүрдэх ба тест бөглөөд хангалттай оноо авбал Silver Certificate, үүний дараа холбогдох сэдвээр илтгэл бичээд комиссоор хянуулж хангалттай гэж үзвэл Gold Certificate өгдөг. Мөн CISSP гээд хамгийн алдартай нууцлал хамгааллын сертификатанд бэлдэх сургалтыг зохион явуулдаг.
Өдөр бүр хичээл дээр дасгал хийж байсан нь хичээлийг ойлгоход илүү дөхөм болсон байх. Гэхдээ л 6 хоногт ахдахаар их мэдээллийг багтаасан байсан нь сурч мэдэх юм их байна даа гэсэн сэтгэлийг минь улам хүчтэй болгож байлаа.
Энэ сургалтанд нийт зөвхөн суралцагч 860 орчим хүн оролцсон бөгөөд, үүнээс ердөө 40 хүрэхгүй нь гадаадаас ирсэн хүмүүс байлаа. Америкаас оролцож байгаа хүмүүс дотор 2-3 дахь удаагаа оролцож байгаа хүмүүс ч байсан. Компани нь ч ажилтнуудаа сургалтанд суулгаж, мэдлэг мэргэжлийг нь дээшлүүлэхэд их анхаардаг санагдсан.
SANS өөрийн GIAC Certificate-г санал болгодог бөгөөд үйлдлийн систем, салбараасаа хамаараад 23 төрлийн сертификат өгдөг юм билээ. Шалгалт нь 2 хэсгээс бүрдэх ба тест бөглөөд хангалттай оноо авбал Silver Certificate, үүний дараа холбогдох сэдвээр илтгэл бичээд комиссоор хянуулж хангалттай гэж үзвэл Gold Certificate өгдөг. Мөн CISSP гээд хамгийн алдартай нууцлал хамгааллын сертификатанд бэлдэх сургалтыг зохион явуулдаг.
Thursday, June 29, 2006
SANFIRE2006 - Бэлтгэл ажил
SANFIRE2006 - энэ бол SANS Institute-с зохион байгуулж байгаа энэ жилийн хамгийн том арга хэмжээ. Сүлжээний нууцлал хамгаалалын бүхий л чиглэлээр сисадмин, сүлжээний аудитор, сүлжээний инженерүүдэд зориулсан 30 гаруй ангиуд зэрэг хичээллэнэ.
Харин SEC506 бол миний суух ангийн нэр. Хайж хайж яг тохирох сургалтыг олж чадлаа. Урамтай байна шүү. Бүтэн зургаан өдөр Юникс төрлийн системийн нууцлал, хамгааллын талаар судлана. Өдөр бүр 9:00-17:00. Өдөр бүр үзсэн материалаасаа шалгалт өгч 6 оноо цуглуулна, нийт 36 оноо. Миний хамгийн их сонирхлыг татаж байгаа зүйл бол, ямар хүмүүс ирэх бол? ур чадвар нь хэр бол? сисадмин хүн юу хийдэг бол? гэхчлэн олон зүйлүүд байна.
Бэлтгэл ажил - Бэлтгэл ажил гэхээр л хувцас хунараа боож баглах гэж ойлгогдох вий дээ, хэхэ. Ер нь ямар нэг ажлыг хийхийн өмнө, төлөвлөгөөгөө гаргана гэдэг чинь л хамаг цаг авдаг ажил байна. 7 сард болох сургалтаа би 4 сараас хайж эхэлснээс хоцрох шахсан шүү. SANFIRE2006 дээр тогтохын тулд нилээд хэдэн өдөр интернет ухаж, харьцуулж, мөн удирдах хүмүүстээ танилцуулсны эцэст шийдсэн. Дараа нь төсөв мөнгөө батлуулах, онгоцны тийзээ захиалах, визний ярилцлаганд орох өдрөө 6 долоо хоногийн өмнө захиалах гэх мэтчилэн аян замд явах хүнд эртнээс төлөвлөх ажил тун их байлаа.
Харин SEC506 бол миний суух ангийн нэр. Хайж хайж яг тохирох сургалтыг олж чадлаа. Урамтай байна шүү. Бүтэн зургаан өдөр Юникс төрлийн системийн нууцлал, хамгааллын талаар судлана. Өдөр бүр 9:00-17:00. Өдөр бүр үзсэн материалаасаа шалгалт өгч 6 оноо цуглуулна, нийт 36 оноо. Миний хамгийн их сонирхлыг татаж байгаа зүйл бол, ямар хүмүүс ирэх бол? ур чадвар нь хэр бол? сисадмин хүн юу хийдэг бол? гэхчлэн олон зүйлүүд байна.
Бэлтгэл ажил - Бэлтгэл ажил гэхээр л хувцас хунараа боож баглах гэж ойлгогдох вий дээ, хэхэ. Ер нь ямар нэг ажлыг хийхийн өмнө, төлөвлөгөөгөө гаргана гэдэг чинь л хамаг цаг авдаг ажил байна. 7 сард болох сургалтаа би 4 сараас хайж эхэлснээс хоцрох шахсан шүү. SANFIRE2006 дээр тогтохын тулд нилээд хэдэн өдөр интернет ухаж, харьцуулж, мөн удирдах хүмүүстээ танилцуулсны эцэст шийдсэн. Дараа нь төсөв мөнгөө батлуулах, онгоцны тийзээ захиалах, визний ярилцлаганд орох өдрөө 6 долоо хоногийн өмнө захиалах гэх мэтчилэн аян замд явах хүнд эртнээс төлөвлөх ажил тун их байлаа.
Визээ өчигдөр авсан. Одоо л нэг санаа амар жинхэнэ бэлтгэл ажилдаа орох нь. Laptop requirement гэсэн уртаа гэгч нь мэйл ирж. Redhat эсвэл Fedora заавал суусан байх ёстой, сургалтын турш ашиглагдах заавал суусан байх package-уудын жагсаалт гэхчилэн их л олон зүйл заасан байна. Дассан сурсан Redhat-аа суулгая гэсэн үнэтэй болчиж. Fedora дээр л тунаад байна даа.
Мөн сургалтын дараа завтай өдрөө Washingtond-д байдаг их сургуулиудаар орж танилцах хүсэлтэй байна. UMD (University of Maryland)-д Linux User Group гэж лав байдаг юм байна. Хүмүүстэй нь холбоо барьж уулзах хүсэлтэй байна.
Subscribe to:
Posts (Atom)
