Нилээд завсарлаад APNIC-с дахин Монголд арга хэмжээ зохиожээ дээ...
The Asia Pacific Network Information Centre (APNIC), in collaboration with the Government of Mongolia, MobiCom and MobiNet, will hold a one-day conference on the 21 October 2010 at Kempinski Hotel Khan Palace in Ulaanbaatar, Mongolia. The conference will be focused on the evolution of the Internet with the theme "Future of the Internet in Mongolia".
Inaugural session - Keynote
Moderator: Mr. Munkhbold Udval, Director, TPD, MobiCom
Speakers:
* Mr. BOLOR.D, CEO, MobiCom Corporation / Mr. Enkhsaikhan.M, CEO, MobiNet
* Mr. Munkhbold Udval, Director, TPD, MobiCom Corporation
* Mr. Nyamjdorj.G, Director, Information, Communications, Technology and Post Authority
* Mr. Batbold Toiruul, Communication Regulatory Commission
* Mr. German Valdez, Asia Pacific Network Information Centre (APNIC)
Technical session:
Coordinator: Mr. Srinivas (Sunny) Chendi, APNIC, Australia
Presenters:
* Supporting Internet growth and evolution: Mr. German Valdez, APNIC, Australia
* IPv6 deployment cases: Mr. Matsuzaki Yoshinobu, IIJ, Japan
* Internet Exchange and Peering: Mr. Bill Woodcock, PCH, USA
* DNS Security: Mr. Champika Wijayatunga, APNIC, Australia
Internet Policy, Governance, and Multilingualism:
Coordinator: Mr. Srinivas (Sunny) Chendi, APNIC, Australia
Presenters:
* Internet users' role in Internet Governance: Dr. Hong Xue, APRALo
* Internationalized domain names: Ms. Jian Zhang, APTLD
* Internet Policy and regulations: Ms. Christine Runnegar, ISOC
* Introduction to ICANN and Policy Development: Mr. Save Vocea, ICANN
Panel discussion – Future of Internet in Mongolia
Moderator: Mr. Munkhbold Udval, Director, TPD, MobiCom
Panelists:
* Mr. [TBC], CRC
* Mr. Nyamdorj.G, ICTPA
* Mr. Sukhbaatar.Yo, NITP
* Mr. Enkhsaikhan.M, MobiNet
* Mr. [TBC], NDC
* Mr. Bayarsaikhan.V, "MOSA" NGO
* Ms. Tsetsegulzii.Ya, "Tsahim Medleg" NGO
Showing posts with label DNS. Show all posts
Showing posts with label DNS. Show all posts
Friday, October 22, 2010
Thursday, April 05, 2007
DNSStuff - dns web tools
DNS-c залхаагүй хүмүүст дахин нэг мэдээ... :)
DNS-тэй холбоотой real-time асуулга явуулах хэрэгтэй үедээ www.dnsstuff.com хуудсыг хэрэглэдэг билээ. Ер нь DOS юмуу, Юникс тушаалын мөрний nslookup, dig зэрэг tool-үүдийг хэрэглэн ижил мэдээллийг олж авч болох боловч, аргагүй веб интерфэйс болохоор ойлгоход хялбар байдаг юм. Манай зарим админууд энэ хуудсыг магадгүй хэрэглэдэг байх. Энэ сайтнаас forward ба reverse DNS асуулга, WHOIS, Spam Database(RBL) асуулгууд, TraceRoute, Ping зэрэг (үүгээр бас зогсохгүй) tool-үүдийг бүгдийг нэг дороос олж болно.
Саяхнаас энэ сайт шинэчлэгдэж, асуулга явуулахын тулд заавал гишүүнчлэл шаарддаг болсон боловч, үнэгүй эрхээр хуучин нийтэд нээлттэй байсан бүх tool-үүдийг хэрэглэж болох тул DNS системтэй ажилладаг, DNS асуулга явуулах хүсэлтэй хэн бүхэн энэ хуудсаар зочлоод нэг үзээрэй.
Шинээр нэмэгдсэн, миний сонирхлыг татсан хэсэг гэвэл хэлэлцүүлэг буюу forum байна. Энд DNS-тэй холбоотой асуудлууд, сонирхсон асуултуудаа бичиж, нийтээс болон DNSStuff-н мэргэжилтнээс хариултыг авч болох юм байна. Хэрвээ танд DNS-тэй холбоотой ойлгомжгүй асуудлууд байвал асуугаад үзээрэй. Бас нэг сонирхол татсан шинэ үйлчилгээ гэвэл жилийн 36$ төлөөд 24 цагын DNS Monitoring, нэмэлт DNS tool-үүдийг хэрэглэж болохоос гадна DNSStuff-c technical support авч болох юм байна. "Let us monitor your domain 24/7/365 - be DNS smart!" гэсэн хөөрхөн уриатай юм. Энд хэлж байгаа DNS Monitoring хийх нь чухал гэсэн гол санаа нь их зөв санаа байна.
Зөвхөн DNS Monitoring хийхийн тул 36$ төлөөд ч яахав, нээлттэй эхийн Nagios-г ашиглахад л болно. Nagios 5 минут тутамд таны зааж өгсөн домэйноор Root DNS Серверүүдээс асуулга явуулж, хэрэв name resolution хийж чадахгүй бол тэр дор нь танд цахим захидлаар мэдэгдэх болно. Nagios-н талаарх мэдээллийг http://nagios.org/ хуудаснаас үзээрэй.
DNS-тэй холбоотой real-time асуулга явуулах хэрэгтэй үедээ www.dnsstuff.com хуудсыг хэрэглэдэг билээ. Ер нь DOS юмуу, Юникс тушаалын мөрний nslookup, dig зэрэг tool-үүдийг хэрэглэн ижил мэдээллийг олж авч болох боловч, аргагүй веб интерфэйс болохоор ойлгоход хялбар байдаг юм. Манай зарим админууд энэ хуудсыг магадгүй хэрэглэдэг байх. Энэ сайтнаас forward ба reverse DNS асуулга, WHOIS, Spam Database(RBL) асуулгууд, TraceRoute, Ping зэрэг (үүгээр бас зогсохгүй) tool-үүдийг бүгдийг нэг дороос олж болно.
Саяхнаас энэ сайт шинэчлэгдэж, асуулга явуулахын тулд заавал гишүүнчлэл шаарддаг болсон боловч, үнэгүй эрхээр хуучин нийтэд нээлттэй байсан бүх tool-үүдийг хэрэглэж болох тул DNS системтэй ажилладаг, DNS асуулга явуулах хүсэлтэй хэн бүхэн энэ хуудсаар зочлоод нэг үзээрэй.
Шинээр нэмэгдсэн, миний сонирхлыг татсан хэсэг гэвэл хэлэлцүүлэг буюу forum байна. Энд DNS-тэй холбоотой асуудлууд, сонирхсон асуултуудаа бичиж, нийтээс болон DNSStuff-н мэргэжилтнээс хариултыг авч болох юм байна. Хэрвээ танд DNS-тэй холбоотой ойлгомжгүй асуудлууд байвал асуугаад үзээрэй. Бас нэг сонирхол татсан шинэ үйлчилгээ гэвэл жилийн 36$ төлөөд 24 цагын DNS Monitoring, нэмэлт DNS tool-үүдийг хэрэглэж болохоос гадна DNSStuff-c technical support авч болох юм байна. "Let us monitor your domain 24/7/365 - be DNS smart!" гэсэн хөөрхөн уриатай юм. Энд хэлж байгаа DNS Monitoring хийх нь чухал гэсэн гол санаа нь их зөв санаа байна.
Зөвхөн DNS Monitoring хийхийн тул 36$ төлөөд ч яахав, нээлттэй эхийн Nagios-г ашиглахад л болно. Nagios 5 минут тутамд таны зааж өгсөн домэйноор Root DNS Серверүүдээс асуулга явуулж, хэрэв name resolution хийж чадахгүй бол тэр дор нь танд цахим захидлаар мэдэгдэх болно. Nagios-н талаарх мэдээллийг http://nagios.org/ хуудаснаас үзээрэй.
Tuesday, April 03, 2007
SPF - Спамаас хамгаалах арга
Энэ сар DNS-р амьсгалсан сар боллоо :). Та бүхэндээ DNS системийн талаар дахин нэг нийтлэл толилуулж байна.
SPF буюу Sender Policy Framework нь DomainKeys-н нэгэн адилаар DNS дээр тулгуурласан спамаас хамгаалах нэг арга юм. Гол ялгаа нь DomainKeys TXT бичлэг дотор өөрийн хэрэглэж буй public түлхүүрийг зарладаг бол, SPF нь authorized/бүрэн эрхт мэйл серверүүдээ зарладаг явдал юм. Domainkeys-н талаарх түрүүчийн нийтлэлийг үзнэ үү.
Тэгэхээр та танай мэйлүүд дамжин гардаг бүх мэйл серверүүдийг өөрийн домэйны TXT бичлэгт зааж өгнө гэсэн үг юм. Ажилчид чинь ажил дээрээсээ мэйл явуулах тул мэдээж эхлээд байгууллагын чинь мэйл сервер, хэрвээ гэрээсээ бас мэйл явуулдаг бол тухайн ISP-н мэйл серверүүд бас бичигдэнэ гэсэн үг.
Жишээ нь:
mx : mx бичлэгт заасан серверүүд энэ домэйны мэйл дамжуулахыг зааж байна
a:mail.isp-test.mn : mail.isp-test.mn гэсэн хост мөн мэйл явуулах эрхтэй
include:gmail.com : gmail-н зөвшөөрсөн серверүүдийг бүгдийг зөвшөөрөх
-all : бусад нь энэ домэйнтой мэйл явуулах эрхгүй
SPF бичлэгийг яаж үүсгэхээ сайн ойлгохгүй байвал SPF Төслөөс гаргасан "SPF Setup Wizard"-г хэрэглээд үзээрэй.
Хэрэв өөрийн мэйл серверийг SPF хэрэглэдэг болгоё гэвэл SPF Төслийн ЭНЭ хуудсаар зочилж өөрийн тань MTA SPF-г дэмждэг эсэхийг шалгаарай.
SPF зарим нэг талаар хязгаарлагдмал хэдий ч, Amazon, AOL, EBay, Google, GMX, Hotmail, Microsoft, ба W3C зэрэг олонд нэртэй домэйнууд өөрсдийн SPF мэдээллийг зарлах болсон байна. 2007 оны судалгаагаар .com ба .net домэйны 5% нь ямар нэг хэлбэрийн SPF бодлогыг хэрэгжүүлж байна. Мөн бидний сайн мэдэх SpamAssassin 3.0.0-с SPF-г дэмждэг болжээ.
Холбоосууд:
1. SPF Project homepage
2. Wikipedia - SPF
3. SPF Syntax
SPF буюу Sender Policy Framework нь DomainKeys-н нэгэн адилаар DNS дээр тулгуурласан спамаас хамгаалах нэг арга юм. Гол ялгаа нь DomainKeys TXT бичлэг дотор өөрийн хэрэглэж буй public түлхүүрийг зарладаг бол, SPF нь authorized/бүрэн эрхт мэйл серверүүдээ зарладаг явдал юм. Domainkeys-н талаарх түрүүчийн нийтлэлийг үзнэ үү.
Тэгэхээр та танай мэйлүүд дамжин гардаг бүх мэйл серверүүдийг өөрийн домэйны TXT бичлэгт зааж өгнө гэсэн үг юм. Ажилчид чинь ажил дээрээсээ мэйл явуулах тул мэдээж эхлээд байгууллагын чинь мэйл сервер, хэрвээ гэрээсээ бас мэйл явуулдаг бол тухайн ISP-н мэйл серверүүд бас бичигдэнэ гэсэн үг.
Жишээ нь:
v=spf1 : SPF протоколыг зааж байнаtest.mn. TXT "v=spf1 mx a:mail.isp-test.mn include:gmail.com -all"
mx : mx бичлэгт заасан серверүүд энэ домэйны мэйл дамжуулахыг зааж байна
a:mail.isp-test.mn : mail.isp-test.mn гэсэн хост мөн мэйл явуулах эрхтэй
include:gmail.com : gmail-н зөвшөөрсөн серверүүдийг бүгдийг зөвшөөрөх
-all : бусад нь энэ домэйнтой мэйл явуулах эрхгүй
SPF бичлэгийг яаж үүсгэхээ сайн ойлгохгүй байвал SPF Төслөөс гаргасан "SPF Setup Wizard"-г хэрэглээд үзээрэй.
Хэрэв өөрийн мэйл серверийг SPF хэрэглэдэг болгоё гэвэл SPF Төслийн ЭНЭ хуудсаар зочилж өөрийн тань MTA SPF-г дэмждэг эсэхийг шалгаарай.
SPF зарим нэг талаар хязгаарлагдмал хэдий ч, Amazon, AOL, EBay, Google, GMX, Hotmail, Microsoft, ба W3C зэрэг олонд нэртэй домэйнууд өөрсдийн SPF мэдээллийг зарлах болсон байна. 2007 оны судалгаагаар .com ба .net домэйны 5% нь ямар нэг хэлбэрийн SPF бодлогыг хэрэгжүүлж байна. Мөн бидний сайн мэдэх SpamAssassin 3.0.0-с SPF-г дэмждэг болжээ.
Холбоосууд:
1. SPF Project homepage
2. Wikipedia - SPF
3. SPF Syntax
Monday, April 02, 2007
Ажлын єндєр амжилт хvсье!
Голомтын админууд үнэхээр хурдан арга хэмжээ авчээ. Миний нийтлэл тэр том байгууллагын админуудад хүрсэн бол үнэхээр их баяртай байна. Ажилдаа хариуцлагатай, бас гадагшаа нээлттэй мэргэжил нэгт нөхөддөө ажлын өндөр амжилт хүсье!
Хүндэтгэсэн,
Л.Баянзул
Хүндэтгэсэн,
Л.Баянзул
Sunday, April 01, 2007
split-brain DNS, split-horizon DNS, DNS view
"Гадаадад нэг, дотоодод тусдаа мэдээлэл өгдөг DNS тогтолцоо"-г split-horizon DNS, split-brain DNS, DNS view гэх мэтчилэн олон янзаар нэрлэх болжээ. Хэдийгээр бүгд угтаа нэг утгыг агуулж байгаа хэдий ч цаад үүсэлийг нь аваад үзвэл хоорондоо нилээд ялгаатай ойлголтууд юм.
Split-horizon гэдэг нь router болон сүлжээний төхөөрөмжийн хувьд хэрэглэгддэг бөгөөд сервер DMZ(demiliterized zone)-д байрлахыг хэлнэ.
DNS View гэж split-brain DNS-г implement хийхэд зориулсан BIND 9-н View функцыг хэлж байгаа хэрэг юм.
Split-brain DNS гэж энд түрүүнээс хойш яригдаад байгаа үндсэн ойлголтыг нэрлэж байна.
Split-brain DNS-г дараах байдлаар зохион байгуулж болно.
1. Гадаад, дотоод DNS мэдээллүүд тусдаа баазуудад, тусдаа DNS серверүүд дээр байрлах
Гол санаа нь гадаадад нэг, дотоодод нэг DNS сервер(эсвэл бүлэг серверүүд) ажиллана гэсэн үг. Гадаад сервер дээр зөвхөн гадаадад зориулсан мэдээлэл, дотоод сервер дээр дотоодод зориулсан мэдээлэл байх ёстой. Дотоод серверүүд гадаад мэдээлэлд хүрч чаддаг байхын тулд гадаад мэдээллийн хуулбарыг дотоод сервер дээр байрлуулах хэрэгтэй болно. Хоёр талд байгаа ижил мэдээллийг яаж consistent байлгах вэ гэдэг дээр жинхэнэ админы шийдэл гарч ирэх байх. Энэ мэдээллийг гараар 2 дахин оруулах уу? Динамик болгохын тулд гаднах нь дотнохынхоо slave болох уу? эсвэл эсрэгээрээ байх уу? гэх мэтчилэн олон шийдэл гарч ирнэ.
Дээр нь дотоод серверүүд бусад домэйны хувьд name resolution яаж хийх вэ? гэсэн асуудал гарч ирэх болно. Гол шийдэл нь дотоод DNS хариулж чадахгүй асуулгуудаа гадаад DNS-рүү forward хийнэ. Дотоодод ганц сервер байгаад zone file-уудаа агуулаад, caching бас хийхүү? эсвэл caching-only DNS сервер тусад нь ажиллуулах уу? гэдгийг тухайн системээс хамаарч админ шийдэх болвуу. Серверийнхээ ачаалал, найдвартай ажиллагааг бодолцвол гадаадад primary ба secondary, дотоодод primary ба secondary, дээр нь caching-only DNS cервер гэсэн хувилбараар нийтдээ 5 DNS сервер ажиллуулж болох юм.
Ямар ямар хувилбарууд байж болох талаар дэлгэрэнгүйг энэ нийтлэлийн төгсгөлд байгаа "Холбоосууд" хэсэгт байгаа баримтуудаас олж уншина уу.
Нэг мэдээллийг хоёр янзаар харуулахын тулд, бичлэг бүр дээр "tag" буюу тэмдэг тавьж ялгана гэнэ. Дотоод гэж тэмдэглэсэн бол дотоодод харуулж, гадаад гэж тэмдэглэсэн бол гадаадад харуулах юм байх. BIND мэдээж одоогоор ингэж чадахгүй байгаа. Харин Daniel J.Bernstein-ы djbdns тусламжтай үүнийг хийх боломжтой. Дэлгэрэнгүйг дор байгаа "Холбоосууд" хэсгийн 2 дахь баримтаас уншаарай.
Холбоосууд:
1. Microsoft DNS Technical Articles - Split-Brain DNS Server Configuration for ISPs
2. Jonathan de Boyne Pollard's homepage - Providing "split horizon" DNS service
3. Hal Pomeranz's homepage - DNS and Sendmail(PDF file)
4. BIND 9 - Administrator Reference Manual
Split-horizon гэдэг нь router болон сүлжээний төхөөрөмжийн хувьд хэрэглэгддэг бөгөөд сервер DMZ(demiliterized zone)-д байрлахыг хэлнэ.
DNS View гэж split-brain DNS-г implement хийхэд зориулсан BIND 9-н View функцыг хэлж байгаа хэрэг юм.
Split-brain DNS гэж энд түрүүнээс хойш яригдаад байгаа үндсэн ойлголтыг нэрлэж байна.
Split-brain DNS-г дараах байдлаар зохион байгуулж болно.
1. Гадаад, дотоод DNS мэдээллүүд тусдаа баазуудад, тусдаа DNS серверүүд дээр байрлах
Гол санаа нь гадаадад нэг, дотоодод нэг DNS сервер(эсвэл бүлэг серверүүд) ажиллана гэсэн үг. Гадаад сервер дээр зөвхөн гадаадад зориулсан мэдээлэл, дотоод сервер дээр дотоодод зориулсан мэдээлэл байх ёстой. Дотоод серверүүд гадаад мэдээлэлд хүрч чаддаг байхын тулд гадаад мэдээллийн хуулбарыг дотоод сервер дээр байрлуулах хэрэгтэй болно. Хоёр талд байгаа ижил мэдээллийг яаж consistent байлгах вэ гэдэг дээр жинхэнэ админы шийдэл гарч ирэх байх. Энэ мэдээллийг гараар 2 дахин оруулах уу? Динамик болгохын тулд гаднах нь дотнохынхоо slave болох уу? эсвэл эсрэгээрээ байх уу? гэх мэтчилэн олон шийдэл гарч ирнэ.
Дээр нь дотоод серверүүд бусад домэйны хувьд name resolution яаж хийх вэ? гэсэн асуудал гарч ирэх болно. Гол шийдэл нь дотоод DNS хариулж чадахгүй асуулгуудаа гадаад DNS-рүү forward хийнэ. Дотоодод ганц сервер байгаад zone file-уудаа агуулаад, caching бас хийхүү? эсвэл caching-only DNS сервер тусад нь ажиллуулах уу? гэдгийг тухайн системээс хамаарч админ шийдэх болвуу. Серверийнхээ ачаалал, найдвартай ажиллагааг бодолцвол гадаадад primary ба secondary, дотоодод primary ба secondary, дээр нь caching-only DNS cервер гэсэн хувилбараар нийтдээ 5 DNS сервер ажиллуулж болох юм.
Ямар ямар хувилбарууд байж болох талаар дэлгэрэнгүйг энэ нийтлэлийн төгсгөлд байгаа "Холбоосууд" хэсэгт байгаа баримтуудаас олж уншина уу.
BIND болон Sendmail ашиглан mail gateway хэрхэн тохируулах талаар "Холбоосууд" хэсгийн 3 дахь баримтаас уншаарай.
2. Гадаад, дотоод DNS мэдээллүүд тусдаа баазуудад, нэг DNS Cервер дээр байрлах
Үүнийг BIND9-н VIEW функцийн тусламжтай хийж болно. Тэгэхээр нэг DNS сервер гаднаас ч, дотроос ч DNS асуулгыг хүлээн авдаг байхын тулд 2 сүлжээний картаар гадаад, дотоод сүлжээнд шууд холбогдсон байх, эсвэл NAT-р гадагшаа гардаг байх ёстой болно. Эхнийх буюу нэг машин шууд гадаад, дотоодод зэрэг гарна гэдэг нь аюулгүй байдлын хувьд тун муу шийдэл юм. Тиймээс ихэнх тохиолдолд NAT хийгдсэн байдаг.
За тэгэхээр ямар ч байсан гаднаас ч, дотроос ч DNS асуулга хүлээж авдаг боллоо. Одоо BIND9-г тохируулах хэрэгтэй. Доорх жишээн дээр нэг гадаад slave сервертэй, split-brain DNS тогтолцооны гол сервер дээрх тохиргоог харуулав:
acl internal { 192.168.2.0/24; 192.168.0.0/24;};
acl secondary { xx.xx.xx.xx;};
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
recursion no;
notify no;
};
view internal {
match-clients { internal; };
recursion yes;
zone "test.mn" IN {
type master;
file "test.internal";
allow-update { localhost; };
};
"168.192.in-addr.arpa" IN {
type master;
file "named.internal";
allow-update { localhost; };
};
};
view external {
match-clients { any; };
recursion no;
zone "test.mn" IN {
type master;
file "test.external";
allow-update { localhost; };
allow-transfer { secondary; };
notify yes;
};
};
Нэг мэдээллийг хоёр янзаар харуулахын тулд, бичлэг бүр дээр "tag" буюу тэмдэг тавьж ялгана гэнэ. Дотоод гэж тэмдэглэсэн бол дотоодод харуулж, гадаад гэж тэмдэглэсэн бол гадаадад харуулах юм байх. BIND мэдээж одоогоор ингэж чадахгүй байгаа. Харин Daniel J.Bernstein-ы djbdns тусламжтай үүнийг хийх боломжтой. Дэлгэрэнгүйг дор байгаа "Холбоосууд" хэсгийн 2 дахь баримтаас уншаарай.
Холбоосууд:
1. Microsoft DNS Technical Articles - Split-Brain DNS Server Configuration for ISPs
2. Jonathan de Boyne Pollard's homepage - Providing "split horizon" DNS service
3. Hal Pomeranz's homepage - DNS and Sendmail(PDF file)
4. BIND 9 - Administrator Reference Manual
Wednesday, March 28, 2007
Split-horizon DNS
Энэ нийтлэлийг бичье гэж бодсоор их удлаа. Анх санаа нь Голомт банкны DNS бичлэгийг хараад төрсөн билээ.
Episode 1: Тэр үед 2005 оны 5 сард дөнгөж ажилд ороод байсан би, танайхаас Голомт банкруу мэйл явуулж чадахгүй байна гэсэн хэрэглэгчийн гомдолыг хүлээж авлаа. Эхлээд учраа сайн олохгүй нилээд материал уншиж судалсны эцэст Голомт банкны DNS бичлэг нэг домэйн нэр дээр нилээд олон A бичлэгийг дотоод, гадаад IP холин цувуулан бичсэн байлаа. Манай мэйл серверээс DNS resolution хийхэд дотоод IP нь гарч ирээд мэйл явуулж чадахгүй байсан бололтой. Нилээд хэдэн утас эргэдэж байж Голомтын DNS бичлэгийг хариуцдаг админ-тай нь ярилаа. Тэгвэл зүгээр, ингэвэл дээр гэж хэлж чадахаар юм надад үнэндээ байсангүй. "Гадаад IP-тай A бичлэгээ, дотоод IP-тайгийнхаа дээр нь тавьчиж болохгүй юу?" гэж хэлж байснаа санаж байна. Мэдээж Голомтынхон ямар нэг арга хэмжээ аваагүй, тэр хэрэглэгч дахин утасдаж байсан санагдана. Тэр үед миний хийх гэж оролдсон ганц алхам бол өөрийн DNS Cache сервер дээр Голомтын golombank.com домэйныг гадаад IP-руу нь шууд зааж өгөх гэсэн оролдлого байлаа. Тэр үед DNS системийн талаар үнэндээ ямар ч мэдлэг байгаагүй болохоор нөгөө хэрэглэгч маань ч утасдахаа больж, би ч энэ талаар таг мартав.
Episode 3: 2006 оны 9 сард, Улаанбаатарт болсон APNIC DNS Workshop... DNS-ын ойлгомжгүй олон асуудлууд байсныг хичээл заасан багшаасаа асууж нэг санаа амрав. Мэдээж Голомт банкны бичлэгийг асуухаа мартсангүй. "Манай нэг хэрэглэгч дотоод IP-гаа гадаад DNS дээрээ биччихээд байх юм. Энэ болохгүй биз дээ?" гэж асуухад минь, "It is stupid thing to annouce your private IP to the world." гэж хариулж байсан билээ. Хичээл дууссаны дараа шалгатал Голомтын DNS бичлэг хэвээрээ л байсан санагдана. Хичээл заалгасан хүн чинь юу гэж зүгээр байхав дээ. Zone transfer хийх гэж оролдсон, болоогүй. Гэхдээ сонирхолтой мэдээлэл нилээд олсон. Би сүлжээний хакер биш л дээ, үнэндээ энэ мэдээллээр юу хийхээ ч өөрөө ойлгоогүй, зүгээр л сонирхол татаж байлаа. dns, mail, web нь бүгд (Голомт банк мэдээж олон домэйнтэй байх, зөвхөн golomtbank.com-н хувьд) нэг IP-руу заагдсан байсан. 192.168.0.8 байсан шиг санаж байна. Мэдээж бүхэл бүтэн банк юм чинь энэ олон сервис нэг сервер дээр байна гэж байхгүй л дээ, proxy сервер биз гэсэн яриа манай ажлынхны дунд өрнөлөө.
Episode 4: 2006 оны 12 сар... Дөлөө, Нүүнээ хоёртой буу халж байсан, Голомт банкны DNS бичлэгийн талаар яриа өрнөлөө. (Ярих бодит жишээтэй байх сайхан юм :) ) "Дотоод сүлжээндээ DNS cервер хэрэгтэй байгаа л юм бол дотооддоо тусад нь DNS тавьчиж болдоггүй юм байх даа" гэсэн миний саналын хариуд Дөлөө "Request ирж байгаа IP-наас нь хамаарч BIND гадаадад нэг мэдээлэл, дотоодод өөр мэдээлэл өгч чадна." гэж байна. "BIND уу? Чадахгүй." гэж Нүүнээ бид 2 зөрөөд... барьдаг дээрээ туллаа.
Episode 2: SANS-н сургалтанд суухдаа split-horizon DNS зохион байгуулж, дотоод DNS мэдээллээ гаднаас хэрхэн хамгаалах талаар анх олж сонслоо.
Episode 5: Саяхан Голомт банкны бичлэгийг шалгаад орхисон, харин дотоод IP-нууд нь алга болчиж... Админууд нь нэг арга хэмжээ авсан бололтой.
Episode 6: ... гэж бодоод дөнгөж сая шалгатал, яг ч бас үгүй юм байна.
www.golomtbank.com 202.170.65.8 (A)
mail.golomtbank.com 202.170.65.8 (A)
> golomtbank.com
Server: [202.170.65.8]
Address: 202.170.65.8
golomtbank.com nameserver = glmt.golomtbank.com
glmt.golomtbank.com internet address = 192.168.1.4
glmt.golomtbank.com internet address = 202.170.65.8
DNS нь дотоод IP-гаа зарласан хэвээр байна. Байгууллагын дотоод сүлжээнээс хандаж байгаа болохоор гарч ирж байгаа байж магадгүй.
Нэмээд хэлчихэд golomtbank.com домэйнд MX бичлэг байхгүй, 2 authoritative/бүрэн эрхт DNS сервер зарласан хэдий ч glmt1.golomtbank.com-202.170.65.9 нь ерөөсөө ажилладаггүй юм билээ.
Episode 7: Уг нь split-horizon DNS, DNS view-н талаар энд бичих ёстой байлаа. Ойлгоогүй зүйлс бас байгаа тул дараагийн нийтлэлдээ гүйцээе.
PS: Голомт банкыг шүүмжилсэн өнгө аястай нийтлэл болсон бол хүлцэл өчье. Аргагүй толгойд яваад байсан болохоор энд жишээ болгон бичлээ. Дээрх мэдээллийг хялбархан nslookup хийгээд олж авч болно.
Episode 1: Тэр үед 2005 оны 5 сард дөнгөж ажилд ороод байсан би, танайхаас Голомт банкруу мэйл явуулж чадахгүй байна гэсэн хэрэглэгчийн гомдолыг хүлээж авлаа. Эхлээд учраа сайн олохгүй нилээд материал уншиж судалсны эцэст Голомт банкны DNS бичлэг нэг домэйн нэр дээр нилээд олон A бичлэгийг дотоод, гадаад IP холин цувуулан бичсэн байлаа. Манай мэйл серверээс DNS resolution хийхэд дотоод IP нь гарч ирээд мэйл явуулж чадахгүй байсан бололтой. Нилээд хэдэн утас эргэдэж байж Голомтын DNS бичлэгийг хариуцдаг админ-тай нь ярилаа. Тэгвэл зүгээр, ингэвэл дээр гэж хэлж чадахаар юм надад үнэндээ байсангүй. "Гадаад IP-тай A бичлэгээ, дотоод IP-тайгийнхаа дээр нь тавьчиж болохгүй юу?" гэж хэлж байснаа санаж байна. Мэдээж Голомтынхон ямар нэг арга хэмжээ аваагүй, тэр хэрэглэгч дахин утасдаж байсан санагдана. Тэр үед миний хийх гэж оролдсон ганц алхам бол өөрийн DNS Cache сервер дээр Голомтын golombank.com домэйныг гадаад IP-руу нь шууд зааж өгөх гэсэн оролдлого байлаа. Тэр үед DNS системийн талаар үнэндээ ямар ч мэдлэг байгаагүй болохоор нөгөө хэрэглэгч маань ч утасдахаа больж, би ч энэ талаар таг мартав.
Episode 3: 2006 оны 9 сард, Улаанбаатарт болсон APNIC DNS Workshop... DNS-ын ойлгомжгүй олон асуудлууд байсныг хичээл заасан багшаасаа асууж нэг санаа амрав. Мэдээж Голомт банкны бичлэгийг асуухаа мартсангүй. "Манай нэг хэрэглэгч дотоод IP-гаа гадаад DNS дээрээ биччихээд байх юм. Энэ болохгүй биз дээ?" гэж асуухад минь, "It is stupid thing to annouce your private IP to the world." гэж хариулж байсан билээ. Хичээл дууссаны дараа шалгатал Голомтын DNS бичлэг хэвээрээ л байсан санагдана. Хичээл заалгасан хүн чинь юу гэж зүгээр байхав дээ. Zone transfer хийх гэж оролдсон, болоогүй. Гэхдээ сонирхолтой мэдээлэл нилээд олсон. Би сүлжээний хакер биш л дээ, үнэндээ энэ мэдээллээр юу хийхээ ч өөрөө ойлгоогүй, зүгээр л сонирхол татаж байлаа. dns, mail, web нь бүгд (Голомт банк мэдээж олон домэйнтэй байх, зөвхөн golomtbank.com-н хувьд) нэг IP-руу заагдсан байсан. 192.168.0.8 байсан шиг санаж байна. Мэдээж бүхэл бүтэн банк юм чинь энэ олон сервис нэг сервер дээр байна гэж байхгүй л дээ, proxy сервер биз гэсэн яриа манай ажлынхны дунд өрнөлөө.
Episode 4: 2006 оны 12 сар... Дөлөө, Нүүнээ хоёртой буу халж байсан, Голомт банкны DNS бичлэгийн талаар яриа өрнөлөө. (Ярих бодит жишээтэй байх сайхан юм :) ) "Дотоод сүлжээндээ DNS cервер хэрэгтэй байгаа л юм бол дотооддоо тусад нь DNS тавьчиж болдоггүй юм байх даа" гэсэн миний саналын хариуд Дөлөө "Request ирж байгаа IP-наас нь хамаарч BIND гадаадад нэг мэдээлэл, дотоодод өөр мэдээлэл өгч чадна." гэж байна. "BIND уу? Чадахгүй." гэж Нүүнээ бид 2 зөрөөд... барьдаг дээрээ туллаа.
Episode 2: SANS-н сургалтанд суухдаа split-horizon DNS зохион байгуулж, дотоод DNS мэдээллээ гаднаас хэрхэн хамгаалах талаар анх олж сонслоо.
Episode 5: Саяхан Голомт банкны бичлэгийг шалгаад орхисон, харин дотоод IP-нууд нь алга болчиж... Админууд нь нэг арга хэмжээ авсан бололтой.
Episode 6: ... гэж бодоод дөнгөж сая шалгатал, яг ч бас үгүй юм байна.
www.golomtbank.com 202.170.65.8 (A)
mail.golomtbank.com 202.170.65.8 (A)
> golomtbank.com
Server: [202.170.65.8]
Address: 202.170.65.8
golomtbank.com nameserver = glmt.golomtbank.com
glmt.golomtbank.com internet address = 192.168.1.4
glmt.golomtbank.com internet address = 202.170.65.8
DNS нь дотоод IP-гаа зарласан хэвээр байна. Байгууллагын дотоод сүлжээнээс хандаж байгаа болохоор гарч ирж байгаа байж магадгүй.
Нэмээд хэлчихэд golomtbank.com домэйнд MX бичлэг байхгүй, 2 authoritative/бүрэн эрхт DNS сервер зарласан хэдий ч glmt1.golomtbank.com-202.170.65.9 нь ерөөсөө ажилладаггүй юм билээ.
Episode 7: Уг нь split-horizon DNS, DNS view-н талаар энд бичих ёстой байлаа. Ойлгоогүй зүйлс бас байгаа тул дараагийн нийтлэлдээ гүйцээе.
PS: Голомт банкыг шүүмжилсэн өнгө аястай нийтлэл болсон бол хүлцэл өчье. Аргагүй толгойд яваад байсан болохоор энд жишээ болгон бичлээ. Дээрх мэдээллийг хялбархан nslookup хийгээд олж авч болно.
Monday, March 26, 2007
DomainKeys - Спамаас хамгаалах арга
Yahoo болон Gmail-рүү явуулсан мэйлүүд BULK-руу орчихоод байвал DomainKey-г хэрэглэж эхлэх цаг болсоных ч байж мэднэ!
Саяхнаас yahoo.co.jp домэйнтой мэйл хаягтай болсон билээ. Хэрэглэж байхдаа нэг анзаарвал зарим мэйл From талбартаа, мэйл хаягныхаа доод талд "DomainKeys は、このメールが yahoo.com から送信されたことを確認しました。" гэсэн бичиг байна. Монголоор "Энэ мэйл yahoo.com-с ирсэн болохыг DomainKeys шалган тогтоов ." гэсэн үг л дээ. Монголд байхад л DomainKeys гээд яригдаад байсан, нээрээ ингээд хэрэглээд эхэлчихсэн юм байх даа гэсэн бодол толгойд орж ирж байна. Wiki-дээд орхисон Yahoo бүр 2004 оноос хойш DomainKeys ашиглах болсон гэж байна. Хэрэв тийм бол яагаад анзаарайгүй байдаг билээ?...
yahoo.com-ын мэйлүүдэд From хэсэгт мэйл хаягны өмнө "дугтуйн дээрх түлхүүрний тэмдэг" байнуу? Дээр нь хулганаар очвол "This sender is DomainKeys verified" гэж гарч ирж байгаа биз...
DomainKeys гэж юу вэ?
DomainKeys гэдэг нь мэйл үнэхээр "From" хэсэгт бичигдсэн домэйноос ирсэн байнуу гэдгийг шалган тогтоох зориулалттай нэг төрлийн шинэ протокол юм. Хялбарханаар тайлбарлавал: явуулж байгаа тал нь гарын үсгээ зурна, хүлээн авч байгаа тал нь түүнийг шалгана гэсэн үг юм.
Хэрхэн ажиллах вэ?
DomainKeys-г ашиглахын тулд эхлээд private/public хос түлхүүр үүсгэх ёстой. Private түлхүүрийг MTA өөртөө хадгалж, гадагшаа явуулж байгаа бүх мэйлийн header дотор бичнэ. Public хэсгийг админ өөрийн DNS zone file-д, _domainkey дэд домэйны TXT бичлэг дотор тавьсанаар, хүлээн авч байгаа мэйл сервер энэ түлхүүрийг авч гарын үсгийг шалгах боломжтой болно. Өөрөөр хэлбэл public түлхүүрийг нийтэд тараахдаа DNS hierarchy-г ашиглаж байна гэсэн үг юм. DNS бичлэгийг зөвхөн тухайн домэйны эзэн өөрчлөх эрхтэй тул хос түлхүүрийг заавал гадны CA(Certificate Authority)-р баталгаажуулах шаардлагагүй болсон давуу талтай.
DomainKey-р баталгаажсан мэйлийн header ямар байдаг бол? гэсэн сониуч зандаа хөтлөгдөж байгаа бол мэйлийн full header-г нь нэг нээгээд хараарай. DomainKey-Signature гэсэн талбар нэмэгдсэн байгаа:
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:cc:mime-version:content-type;
Хэрхэн хэрэглэх вэ?
Yahoo, Gmail бүгд DomainKey-г хэрэглээд нэгэнт эхэлчихсэн тул, та эдгээр домэйнуудруу мэйл явуулахын тулд ядаж гарын үсгээ зураад явуулах хэрэгтэй болох байх даа. Одоо яах вэ гэж санаа зовох хэрэггүй. Өргөн хэрэглэгддэг MTA-уудын хувьд patch/шинэ хувилбар/plugin аль хэдийнэ гарчихсан, аваад хэрэглэх л үлдэж дээ:
- Sendmail milter implementation - http://sourceforge.net/projects/dk-milter
- Qmail patch qmail-dk - http://www.qmail.org/top.html
- Exim version - http://duncanthrax.net/exim-experimental
болон бусад MTA-н талаар DomainKeys төслийн хуудаснаас орж үзнэ үү.
Холбоосууд:
1. Yahoo Anti-Spam Resource Center-с гаргасан танилцуулга - http://antispam.yahoo.com/domainkeys
2. Yahoo-гаас санхүүжүүлж буй нээлттэй эхийн DomainKeys төсөл - http://domainkeys.sourceforge.net
3. Wikipedia - http://en.wikipedia.org/wiki/DomainKeys
Саяхнаас yahoo.co.jp домэйнтой мэйл хаягтай болсон билээ. Хэрэглэж байхдаа нэг анзаарвал зарим мэйл From талбартаа, мэйл хаягныхаа доод талд "DomainKeys は、このメールが yahoo.com から送信されたことを確認しました。" гэсэн бичиг байна. Монголоор "Энэ мэйл yahoo.com-с ирсэн болохыг DomainKeys шалган тогтоов ." гэсэн үг л дээ. Монголд байхад л DomainKeys гээд яригдаад байсан, нээрээ ингээд хэрэглээд эхэлчихсэн юм байх даа гэсэн бодол толгойд орж ирж байна. Wiki-дээд орхисон Yahoo бүр 2004 оноос хойш DomainKeys ашиглах болсон гэж байна. Хэрэв тийм бол яагаад анзаарайгүй байдаг билээ?...
yahoo.com-ын мэйлүүдэд From хэсэгт мэйл хаягны өмнө "дугтуйн дээрх түлхүүрний тэмдэг" байнуу? Дээр нь хулганаар очвол "This sender is DomainKeys verified" гэж гарч ирж байгаа биз...
DomainKeys гэж юу вэ?
DomainKeys гэдэг нь мэйл үнэхээр "From" хэсэгт бичигдсэн домэйноос ирсэн байнуу гэдгийг шалган тогтоох зориулалттай нэг төрлийн шинэ протокол юм. Хялбарханаар тайлбарлавал: явуулж байгаа тал нь гарын үсгээ зурна, хүлээн авч байгаа тал нь түүнийг шалгана гэсэн үг юм.
Хэрхэн ажиллах вэ?
DomainKeys-г ашиглахын тулд эхлээд private/public хос түлхүүр үүсгэх ёстой. Private түлхүүрийг MTA өөртөө хадгалж, гадагшаа явуулж байгаа бүх мэйлийн header дотор бичнэ. Public хэсгийг админ өөрийн DNS zone file-д, _domainkey дэд домэйны TXT бичлэг дотор тавьсанаар, хүлээн авч байгаа мэйл сервер энэ түлхүүрийг авч гарын үсгийг шалгах боломжтой болно. Өөрөөр хэлбэл public түлхүүрийг нийтэд тараахдаа DNS hierarchy-г ашиглаж байна гэсэн үг юм. DNS бичлэгийг зөвхөн тухайн домэйны эзэн өөрчлөх эрхтэй тул хос түлхүүрийг заавал гадны CA(Certificate Authority)-р баталгаажуулах шаардлагагүй болсон давуу талтай.
DomainKey-р баталгаажсан мэйлийн header ямар байдаг бол? гэсэн сониуч зандаа хөтлөгдөж байгаа бол мэйлийн full header-г нь нэг нээгээд хараарай. DomainKey-Signature гэсэн талбар нэмэгдсэн байгаа:
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:cc:mime-version:content-type;
Хэрхэн хэрэглэх вэ?
Yahoo, Gmail бүгд DomainKey-г хэрэглээд нэгэнт эхэлчихсэн тул, та эдгээр домэйнуудруу мэйл явуулахын тулд ядаж гарын үсгээ зураад явуулах хэрэгтэй болох байх даа. Одоо яах вэ гэж санаа зовох хэрэггүй. Өргөн хэрэглэгддэг MTA-уудын хувьд patch/шинэ хувилбар/plugin аль хэдийнэ гарчихсан, аваад хэрэглэх л үлдэж дээ:
- Sendmail milter implementation - http://sourceforge.net/projects/dk-milter
- Qmail patch qmail-dk - http://www.qmail.org/top.html
- Exim version - http://duncanthrax.net/exim-experimental
болон бусад MTA-н талаар DomainKeys төслийн хуудаснаас орж үзнэ үү.
Холбоосууд:
1. Yahoo Anti-Spam Resource Center-с гаргасан танилцуулга - http://antispam.yahoo.com/domainkeys
2. Yahoo-гаас санхүүжүүлж буй нээлттэй эхийн DomainKeys төсөл - http://domainkeys.sourceforge.net
3. Wikipedia - http://en.wikipedia.org/wiki/DomainKeys
Wednesday, January 17, 2007
Шинэ .МN домэйн сервер нэмэгдлээ
МIX(Mongolian Internet Exchange) дээр гарсан гэмтлээс болж .MN домэйн нэрүүд олдохгүй болсон тухай 11 сарын нийтлэлдээ дурдаж байсан билээ. Харин энэ удаа Датакомын шинэ домэйн сервер ns3.magic.mn(202.131.224.80) нэртэйгээр МобиНет-н IP zone-д ажиллаж эхлээд байгаа тухай дуулгахад таатай байна. Асуудлыг нааштай хүлээн авч, түргэн шуурхай шийдвэрлэж өгсөн Датаком компанийн Техникийн албаны захирал Г.Энхболд-д болон инженерүүддээ талархал илэрхийлье.
MобиНетийн IP zone-д .МN домэйн сервер ажиллаж эхэлснээр, МобиНетээс интернетийн үйлчилгээ авч байгаа байгууллага, хэрэглэгчдийн хувьд MIX дээрх гэмтэлээс үл хамааран .МN домэйн нэрийн үйлчилгээг илүү найдвартай авах боломжоор хангагдах юм.
PS: Өмнө нь .МN домэйн нэрийн АНУ-д 6, Монголд 2 сервер ажиллаж байсан бол одоо Монголд байгаа сервер дээр 1 нэмэгдэж нийт 9 сервер ажиллаж байна.
MобиНетийн IP zone-д .МN домэйн сервер ажиллаж эхэлснээр, МобиНетээс интернетийн үйлчилгээ авч байгаа байгууллага, хэрэглэгчдийн хувьд MIX дээрх гэмтэлээс үл хамааран .МN домэйн нэрийн үйлчилгээг илүү найдвартай авах боломжоор хангагдах юм.
PS: Өмнө нь .МN домэйн нэрийн АНУ-д 6, Монголд 2 сервер ажиллаж байсан бол одоо Монголд байгаа сервер дээр 1 нэмэгдэж нийт 9 сервер ажиллаж байна.
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 хийхгүй байх нь хамгийн үр дүнтэй болохыг анхаараарай.
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 дээр асуудал гарлаа гэхэд гэмтэлийн шинж тэмдэг, нөлөөлөх байдал, гэмтэл гарсан цаг, засагдсан цаг хугацааг мэдээлдэг самбар маягын юм байвал баахан бие биенээ гайхаж харж суухгүй байх. Бид бизнесээрээ өрсөлднүү гэхээс мэдлэгээ хуваалцаж, техникийн тал дээр хамтарч ажиллах учиртай шүү дээ.
Subscribe to:
Posts (Atom)
