SPF - Спамаас хамгаалах арга

Энэ сар DNS-р амьсгалсан сар боллоо :). Та бүхэндээ DNS системийн талаар дахин нэг нийтлэл толилуулж байна.

SPF буюу Sender Policy Framework нь DomainKeys-н нэгэн адилаар DNS дээр тулгуурласан спамаас хамгаалах нэг арга юм. Гол ялгаа нь DomainKeys TXT бичлэг дотор өөрийн хэрэглэж буй public түлхүүрийг зарладаг бол, SPF нь authorized/бүрэн эрхт мэйл серверүүдээ зарладаг явдал юм. Domainkeys-н талаарх түрүүчийн нийтлэлийг үзнэ үү.

Тэгэхээр та танай мэйлүүд дамжин гардаг бүх мэйл серверүүдийг өөрийн домэйны TXT бичлэгт зааж өгнө гэсэн үг юм. Ажилчид чинь ажил дээрээсээ мэйл явуулах тул мэдээж эхлээд байгууллагын чинь мэйл сервер, хэрвээ гэрээсээ бас мэйл явуулдаг бол тухайн ISP-н мэйл серверүүд бас бичигдэнэ гэсэн үг.

Жишээ нь:

test.mn.  TXT  "v=spf1 mx a:mail.isp-test.mn include:gmail.com -all"

v=spf1 : SPF протоколыг зааж байна
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

Ажлын єндєр амжилт хvсье!

Голомтын админууд үнэхээр хурдан арга хэмжээ авчээ. Миний нийтлэл тэр том байгууллагын админуудад хүрсэн бол үнэхээр их баяртай байна. Ажилдаа хариуцлагатай, бас гадагшаа нээлттэй мэргэжил нэгт нөхөддөө ажлын өндөр амжилт хүсье!

Хүндэтгэсэн,
Л.Баянзул

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 сервер ажиллуулж болох юм.

Ямар ямар хувилбарууд байж болох талаар дэлгэрэнгүйг энэ нийтлэлийн төгсгөлд байгаа "Холбоосууд" хэсэгт байгаа баримтуудаас олж уншина уу.

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;
};
};

3. Гадаад, дотоод DNS мэдээллүүд нэг баазад, нэг DNS Cервер дээр байлах
Нэг мэдээллийг хоёр янзаар харуулахын тулд, бичлэг бүр дээр "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 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 хийгээд олж авч болно.

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

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-руу бүртгэдэг онцлогтой.

Буцааж сэргээхдээ:

# usermod -U -s /bin/bash username

# passwd -u username
# passmgmt -m -s /bin/bash username

PS: /etc/passwd болон /etc/shadow файлуудыг гараар засаж болохгүй!

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-г хэрхэн тохируулах жишээг харуулав.

Жишээ нь: /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 ашиглан логыг аюулгүйгээр бүртгэх боломжтой болдог.

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" гэж гарч ирж байна.

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-р портон дээр ажиллаж байгаа процессыг харуулна.

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: Энэ жишээ зөвхөн устгасан файлыг ямар нэг процесс ашиглаж байгаа үед сэргээхийг харуулсан болно.

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-г хүлээн авах боломжтой болно.

Ажиллах үндсэн зарчим - 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-г

ажиллуулах check_remote_procs нэртэй шинэ командыг үүсгэнэ. Үүний тулд "command definition"-г /etc/nagios/checkcommands.cfg дотор дараах байдалтай хийнэ.

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
}

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!

Linux Firewalls

SysAdminSummit2006-д илтгэл тавих байсан боловч, монголд байж таараагүй болохоор оролцож чадаагүй билээ. "Unix&Linux Security" талаар сонссон мэдсэнээ хуваалцана гэсэн бодлоо блогоороо дамжуулан хүргэеээ. СисАдминаар ажиллаад 1 жил 6 сар болж байна, туршлага нимгэн болохоор хийж үзсэн гэхээсээ дуулсан, сонссон нь давах тул та бүхэн өршөөгөөрэй. Энэ удаад *nux 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-рүү логин хийж орон сүлжээний түвшинд уг трафикийг хаадаг байхаар тохируулж ч бас болох юм байна.

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-с авсан. Энэ баннерийг бүгдээрээ одоо харцгаая:

#################################################
# 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!