diff --git a/mn_MN.UTF-8/books/handbook/security/chapter.sgml b/mn_MN.UTF-8/books/handbook/security/chapter.sgml index 11b2a29913..c3452a908c 100644 --- a/mn_MN.UTF-8/books/handbook/security/chapter.sgml +++ b/mn_MN.UTF-8/books/handbook/security/chapter.sgml @@ -1,4769 +1,4769 @@ Мэтью Диллон Энэ бүлгийн ихэнх хэсгийг security(7) гарын авлагын хуудаснаас авсан бөгөөд security(7) гарын авлагын хуудсыг бичсэн Цагаанхүүгийн Ганболд Орчуулсан Аюулгүй байдал аюулгүй байдал Ерөнхий агуулга Энэ бүлэг нь системийн аюулгүй байдлын ухагдахуунуудын үндэс, зарим нэг нийтлэг практикийн сайн аргууд болон &os; дэх зарим нэг дэвшилттэй сэдвүүдийг танилцуулах болно. Энд дурдагдсан олон сэдвүүдийг бас системийн болон Интернэтийн аюулгүй байдалд хэрэглэж болох юм. Интернэт нь хүн бүр таны найрсаг хөрш байхыг хүсдэг найзархаг газар байхаа аль хэдийн больсон. Өөрийн системийг аюулгүй болгох нь таны өгөгдөл, оюуны өмч, цаг хугацаа зэрэг олон зүйлсийг хакерууд зэргийн савраас хамгаалахад хойшлуулашгүй чухал юм. &os; нь таны систем болон сүлжээний аюулгүй байдал болон бүрэн бүтэн байдлыг хангаж байдаг хэрэгслүүд болон арга замуудын цуглуулгыг агуулдаг. Энэ бүлгийг уншсаны дараа, та дараах зүйлсийг мэдэх болно: &os;-ийн хувьд системийн аюулгүй байдлын үндсэн ухагдахуунууд. &os;-д байдаг DES болон MD5 зэрэг төрөл бүрийн нууцлах арга замуудын талаар. Нэг удаагийн нууц үгийн нэвтрэлтийг хэрхэн тохируулах талаар. TCP Wrappers буюу TCP Гүйцэтгэлийг хялбаршуулагчдыг inetd-д ашиглан хэрхэн тохируулах талаар. &os;-ийн 5.0-с өмнөх хувилбарууд дээр KerberosIV-г хэрхэн тохируулах талаар. &os; дээр Kerberos5-г хэрхэн тохируулах талаар. IPsec-г хэрхэн тохируулж &os;/&windows; машинуудын хооронд VPN үүсгэх талаар. &os;-ийн SSH шийдэл болох OpenSSH-г хэрхэн тохируулж ашиглах талаар. Файлын системийн ACL-үүд гэж юу болох, тэдгээрийг хэрхэн ашиглах талаар. Portaudit хэрэгслийг хэрхэн ашиглаж Портын цуглуулгаас суулгагдсан гуравдагч програм хангамжийн багцуудыг аудит хийх талаар. &os;-ийн аюулгүй байдлын зөвлөмжүүдийн сонордуулгуудыг хэрхэн хэрэглэх талаар. Процессийн Бүртгэл хөтлөх гэж юу болох талаар ойлголттой болж түүнийг &os; дээр хэрхэн идэвхжүүлэх талаар. Энэ бүлгийг уншихаасаа өмнө, та дараах зүйлсийг мэдэх шаардлагатай: &os; болон Интернэтийн үндсэн ухагдахуунуудыг ойлгох. Энэ номонд нийтдээ аюулгүй байдлын нэмэлт сэдвүүд хамрагдсан болно. Жишээ нь Mandatory Access Control буюу Шаардлагатай Хандалтын Хяналт -д, Интернэт галт ханануудын талаар -д хэлэлцэгдсэн байгаа. Танилцуулга Аюулгүй байдал нь системийн администратораас эхэлж түүнтэй дуусдаг үйл ажиллагаа юм. BSD &unix; олон хэрэглэгчийн системүүд нь угаасаа зарим нэг аюулгүй байдлыг хангаж байдаг боловч тэдгээр хэрэглэгчдийг үнэнч байлгахыг эрмэлздэг аюулгүй байдлын нэмэлт арга замуудыг бүтээж түүний ажиллагааг хангах ажил нь сисадмины магадгүй ганц, хамгийн том үүргүүдийн нэг юм. Таныг аюулгүй болгосон зөвхөн тэр хэмжээгээр машинууд нь аюулгүй байдаг бөгөөд аюулгүй байдлын санаа зовнилууд нь хүний ая тухтай хялбар байлгах гэсэн хэрэгцээтэй үргэлж тэмцэлдэж байдаг. Ерөнхийдөө &unix; системүүд нь асар олон тооны зэрэгцээ процессуудыг ажиллуулах чадвартай бөгөөд эдгээр процессуудын ихэнх нь серверүүд болон ажилладаг — энэ нь гаднын зүйлс тэдэнтэй холбогдож ярилцах боломжтой гэсэн үг юм. Өчигдрийн миникомпьютерууд, мэйнфрэймүүдээс өнөөгийн ширээний компьютерууд болж компьютерууд нь сүлжээнд холбогдож сүлжээнүүд нь хоорондоо холбогдох тусам аюулгүй байдал нь улам илүү том асуудал болсоор байна. Системийн аюулгүй байдал нь сүйрүүлэхийг оролдсон эсвэл системийг ашиглагдахааргүй болгох гэсэн, гэхдээ root бүртгэлийг буулган авах (root-г эвдэх) оролдлого хийдэггүй, халдлагууд зэрэг төрөл бүрийн халдлагуудыг зогсоохтой бас хамааралтай юм. Аюулгүй байдлын санаа зовнилуудыг хэд хэдэн зэрэглэлд хувааж болно: Үйлчилгээг зогсоох халдлагууд. Хэрэглэгчийн бүртгэл буулган авалтууд. Хандаж болох серверүүдээр дамжин root-г буулган авах. Хэрэглэгчийн бүртгэлүүдээс дамжин root-г буулган авах. Арын хаалга үүсгэлт. DoS халдлагууд Үйлчилгээг Зогсоох (DoS) аюулгүй байдал DoS халдлагууд Үйлчилгээг Зогсоох (DoS) Үйлчилгээг Зогсоох (DoS) Үйлчилгээг зогсоох халдлага нь машиныг хэрэгцээтэй эх үүсвэрээс нь салгах үйлдэл юм. Ихэвчлэн DoS халдлагууд нь сүйрүүлэхийг оролдсон эсвэл машиныг түүн дээрх серверүүд болон сүлжээний стекийг эзэмдэн ашиглах боломжгүй болгодог балмадаар хүчлэх арга замууд юм. Зарим DoS халдлагууд нь сүлжээний стек дэх алдаануудыг ашиглан ганц пакетаар машиныг сүйрүүлэхийг оролддог. Үүнийг зөвхөн алдааны засварыг цөмд хийснээр засах боломжтой. Систем дээрх хөнөөлтэй нөхцөлд байх тэр серверийн дуудлагыг хязгаарладаг тохируулгуудыг зөв зааж серверүүд уруу хийсэн халдлагуудыг ихэвчлэн засаж болдог. Сүлжээний балмадаар хүчлэх халдлагуудын эсрэг арга хэмжээ авахад илүү төвөгтэй байдаг. Жишээ нь хууран мэхэлсэн пакетийн халдлагыг зогсоох бараг л боломжгүй, таны системийг Интернэтээс салгахад хүргэж болох юм. Энэ нь таны машиныг зогсоож чадахгүй байж болох боловч таны Интернэтийн холболтыг дүүргэж болно. аюулгүй байдал бүртгэл буулган авалтууд Хэрэглэгчийн бүртгэлийг буулган авах халдлага нь DoS халдлагаас илүү их тохиолддог. Одоо болтол олон сисадминууд стандарт telnetd, rlogind, rshd, болон ftpd серверүүдийг өөрсдийн машинууд дээр ажиллуулсаар байна. Анхдагчаар серверүүд нь шифрлэсэн холболт дээр ажилладаггүй. Ийм холболт дээр хэрэв та багагүй хэмжээний хэрэглэгчидтэй бөгөөд тэдгээр хэрэглэгчдээс нэг болон хэд хэд нь алсаас (энэ нь систем уруу нэвтрэн орох хамгийн нийтлэг тав тухтай арга юм) таны систем уруу нэвтрэн орж байгаа бол тэдгээр хэрэглэгчийн нууц үг дундаасаа сүлжээгээр шиншлэгдэн алдагдах боломжтой байдаг. Анхааралтай системийн админ тэр хэрэглэгчийн алсаас хандсан бүртгэлүүд дээрээс бүр амжилттай болсон нэвтрэлтүүдэд хүртэл сэжигтэй эхлэл хаягууд байгаа эсэхийг хайн шинжилдэг. Халдагч хэрэглэгчийн бүртгэлд хандаж чадсаны дараа root-г бас эвдэж чадна гэдгийг үргэлж бодож байх хэрэгтэй. Гэхдээ жинхэнэ амьдрал дээр бол сайн аюулгүй байдлыг хангаж нууцлаг болгосон байнга ажиллагааг нь хянаж байдаг систем дээр хэрэглэгчийн бүртгэлд хандах нь халдагч заавал ч үгүй root эрхэд хандаж чадна гэсэн үг биш юм. Энэ ялгааг зөв салгаж ойлгох хэрэгтэй. Учир нь root уруу хандах боломжгүй халдагч ерөнхийдөө өөрийн мөрийг баллаж нууж чаддаггүй бөгөөд тухайн хэрэглэгчийн файлуудыг замбараагүйтүүлэх эсвэл машиныг сүйрүүлэхээс илүүтэйг хийж чаддаггүй. Хэрэглэгчид нь сисадминууд шиг аюулгүй байдлын арга хэмжээг тэр болгон авдаггүй болохоор хэрэглэгчийн бүртгэлийн буулган авалт нь маш элбэг байдаг юм. аюулгүй байдал арын хаалганууд Машин дээрх root бүртгэлийг эвдэх боломжит олон аргууд байдгийг системийн администраторууд санаж байх хэрэгтэй. Халдагч нь root-н нууц үгийг мэдэж болно. Эсвэл халдагч root эрхээр ажилладаг серверт алдаа олж сүлжээгээр тэр сервер уруу дамжин орж root-г эвдэж болно. Эсвэл халдагч нь suid-root програмд алдаа байгааг мэдэж хэрэглэгчийн бүртгэлийг эвдэн орсныхоо дараа тэр алдаагаар дамжин root-г эвдэн орж болох юм. Хэрэв халдагч машин дээрх root-г эвдэх аргаа олсон бол заавал арын хаалга суулгах шаардлагагүй болж болох юм. root-н цоорхойнуудын олонхийг тухайн үед аль хэдийн олоод хаачихсан байдаг бөгөөд энэ үед халдагчид өөрийн мөрөө цэвэрлэхэд ихээхэн ажиллагаа шаарддаг болохоор ихэнх халдагчид арын хаалга суулгадаг. Арын хаалга нь систем уруу хандах root хандалтыг халдагчид амархнаар дахин олж авах боломжийг олгодог боловч энэ нь ухаалаг системийн администраторт халдлагыг амархнаар илрүүлэх боломжийг бас олгодог юм. Халдагчийн хамгийн эхлээд эвдэн орсон цоорхойг хааж чаддаггүй болохоор арын хаалга суулгахыг боломжгүй болгох нь магадгүй таны аюулгүй байдалд ашиггүй байж болох юм. Аюулгүй байдлын засварууд нь олон давхраатай сонгины хальс хандлагаар үргэлж шийдэгдэж байх шаардлагатай бөгөөд тэдгээрийг дараах маягаар зэрэглэж болно: root болон staff бүртгэлүүдийг нууцлаг/аюулгүй болгох. root–ажилладаг серверүүд болон suid/sgid хоёртын файлуудыг аюулгүй болгох. Хэрэглэгчийн бүртгэлүүдийг аюулгүй болгох. Нууц үгийн файлыг аюулгүй болгох. Цөмийн гол хэсэг, түүхий төхөөрөмжүүд болон файлын системүүдийг аюулгүй болгох. Системд хийгдсэн зохисгүй өөрчлөлтүүдийг түргэн илрүүлэх. Параной буюу хэт зовнил. Энэ бүлгийн дараагийн хэсэг нь дээр дурдсан зүйлсүүдийг илүү гүнзгийгээр авч үзэх болно. &os;-н аюулгүй байдлыг хангах нь аюулгүй байдал &os;-н аюулгүй байдлыг хангах нь Тушаалыг Протоколтой харьцуулахад (Command vs. Protocol) Энэ баримтын туршид бид тод текстээр програмыг monospaced фонтоор тусгай тушаалуудыг тэмдэглэх болно. Протоколууд ердийн фонт ашиглах болно. Тэмдэглэгээний энэ ялгаа нь ssh зэргийн хувьд ашигтай, учир нь энэ ssh нь протоколоос гадна бас тушаал юм. Үүнээс хойшх хэсгүүд нь түрүүчийн бүлгийн сүүлийн хэсэгт дурдсан таны &os; системийг аюулгүй болгох аргуудыг авч үзнэ. <username>root</username> бүртгэл болон staff бүртгэлүүдийг аюулгүй болгох su Эхлээд хэрэв та root бүртгэлийг аюулгүй болгоогүй бол staff бүртгэлүүдийг аюулгүй болгоход санаа зовсны хэрэггүй. Ихэнх системүүд root бүртгэлд нууц үг өгсөн байдаг. Таны эхний хийх зүйл бол нууц үг үргэлж эвдэгдэж болно гэдгийг бодох хэрэгтэй. Энэ нь та нууц үгээ устгах хэрэгтэй гэсэн үг биш юм. Нууц үг нь машин уруу консол хандалт хийхэд үргэлж хэрэгтэй байдаг. Энэ нь юу гэсэн үг вэ гэхээр та нууц үгийг консолоос гадна эсвэл болж өгвөл бүр &man.su.1; тушаалтай ашиглаж болохоор хийх ёсгүй гэсэн үг юм. Жишээ нь telnet эсвэл rlogin-р хийгдэх шууд root нэвтрэлтүүдийг хаах pty-уудын тохиргоог insecure буюу аюултай гэж /etc/ttys файлд заасан эсэхийг шалгаарай. Хэрэв бусад нэвтрэх үйлчилгээнүүд болох sshd зэргийг ашиглаж байгаа бол шууд root нэвтрэлтүүдийг бас хаасан эсэхийг шалгаарай. Та үүнийг /etc/ssh/sshd_config файлыг засварлан PermitRootLogin тохируулгыг NO болгон зааж өгөөрэй. Хандах арга бүр — FTP зэрэг үйлчилгээнүүдээр ихэвчлэн эвдлэн ордог болохыг бодолцох хэрэгтэй. Шууд root нэвтрэлтүүд зөвхөн системийн консолоор хийгдэхэд зөвшөөрөгдөх ёстой. wheel Мэдээж систем админы хувьд та root уруу орж чадаж байх ёстой болохоор бид хэдэн цоорхой үлдээдэг. Гэхдээ эдгээр цоорхойнууд нь нэмэлт нууц үг шалгаж ажилладаг байхаар бид хийдэг. root-г хандах боломжтой байлгах нэг арга нь тохирох staff бүртгэлүүдийг wheel бүлэгт (/etc/group файлд) нэмэх явдал юм. wheel бүлэгт оруулсан staff-ийн гишүүдэд root уруу su хийхийг зөвшөөрдөг. Та staff-ийн гишүүдийг тэдгээрийн нууц үгийн оруулгад wheel бүлэгт оруулан байрлуулж анхнаас нь wheel хандалт өгч хэзээ ч болохгүй. Staff бүртгэлүүдийг staff бүлэгт оруулах ёстой бөгөөд тэгээд дараа нь /etc/group файлын wheel бүлэгт нэмэх ёстой. Зөвхөн root хандалт заавал шаардлагатай тийм staff-ийн гишүүдийг wheel бүлэгт оруулах ёстой. Kerberos зэрэг жинхэнээ шалгуулж нэвтрэх аргыг ашиглаж байх тохиолдолд заавал wheel бүлэгт оруулалгүйгээр root бүртгэл дэх Kerberos-ийн .k5login файлыг ашиглаж root уруу &man.ksu.1; хийхийг зөвшөөрөх бас боломжтой байдаг. Энэ нь магадгүй давуу шийдэл байж болох юм. Учир нь хэрэв халдагч таны нууц үгийн файлыг олж аван staff бүртгэлийг эвдлэн орж чадах бол wheel арга нь халдагчид root-г эвдэх боломжийг олгосон хэвээр байдаг юм. wheel аргатай байх нь огт аргагүй байхаас илүү боловч энэ нь заавал ч үгүй хамгийн аюулгүй сонголт бас биш юм. Бүртгэлийг бүрэн түгжихийн тулд &man.pw.8; тушаалыг ашиглах хэрэгтэй: &prompt.root;pw lock staff Энэ нь &man.ssh.1;-ийг оролцуулаад хэрэглэгчийг ямар ч арга ашиглан нэвтрэн орохыг хориглоно. Бүртгэлүүдэд хандахыг хориглох өөр нэг арга бол нууцлагдсан нууц үгийг ганц * тэмдэгтээр солих явдал юм. Энэ тэмдэгт нь нууцлагдсан нууц үгтэй хэзээ ч таарахгүй бөгөөд хэрэглэгчийн хандалтыг хаах болно. Жишээ нь доор дурдсан staff бүртгэлийг: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh Ийм болгон өөрчлөх хэрэгтэй: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh Энэ нь foobar хэрэглэгчийг ердийн аргууд ашиглан нэвтрэн орох боломжийг хаадаг. Энэ хандалт хязгаарлах арга нь Kerberos ашиглаж байгаа сайтууд эсвэл хэрэглэгч &man.ssh.1; ашиглан түлхүүрүүд тохируулсан тохиолдлууд зэрэгт ажилладаггүй. Эдгээр аюулгүй байдлын арга замууд нь бас таныг илүү хязгаарласан серверээс арай бага хязгаарласан машин уруу нэвтрэн орж байна гэж тооцдог. Жишээ нь хэрэв таны гол хайрцаг чинь бүх л төрлийн серверүүд ажиллуулж байвал таны ажлын компьютер чинь ямрыг ч ажиллуулах ёсгүй. Өөрийн компьютерийг боломжийн аюулгүй болгохын тулд та ерөөсөө сервергүй болтол аль болох цөөн сервер ажиллуулах хэрэгтэй бөгөөд та нууц үгээр хамгаалагдсан дэлгэц хоослогч ажиллуулах хэрэгтэй. Мэдээж ажлын компьютер уруу физик хандалт өгвөл халдагч ямар ч төрлийн аюулгүй байдлыг та хангасан байлаа гэсэн эвдэж чадна. Энэ нь таны бодох ёстой асуудлын нэг юм. Гэхдээ эвдлэн оролтуудын олонхи нь алсаас сүлжээгээр дамжин таны ажлын компьютер эсвэл серверүүдэд физик хандалт байхгүй хүмүүсээс ирдэг гэдгийг та бас л бодолцох хэрэгтэй юм. KerberosIV Kereberos мэтийг ашиглах нь танд staff бүртгэлийн нууц үгийг нэг газар өөрчлөх эсвэл хаах боломжийг олгох бөгөөд staff-ийн гишүүдийн бүртгэл байж болох бүх машинууд дээр нэн даруй бас үйлчилдэг. Хэрэв staff-ийн гишүүний бүртгэл эвдэгдсэн бол түүний нууц үгийг бүх машинууд дээр нэн даруй өөрчлөх тэр боломжийг дутуу үнэлэх ёсгүй юм. Тусдаа байгаа нууц үгүүдийг N машинууд дээр өөрчлөх нь зовлонтой байдаг. Мөн та Kerberos-д нууц үг дахин өгөлтийг ноогдуулж болох бөгөөд Kerberos тасалбарыг хэсэг хугацааны дараа дуусдагаар хийж болохоос гадна Kerberos систем нь тодорхой хугацааны (жишээ нь сар бүр) дараа хэрэглэгчийг шинэ нууц үг сонгохыг шаарддагаар бас тохируулж болдог. root-ажилладаг серверүүд болон suid/sgid хоёртын файлуудыг аюулгүй болгох ntalk comsat finger sandboxes sshd telnetd rshd rlogind Хянамгай сисадмин илүү ч үгүй дутуу ч үгүй зөвхөн өөрийн хэрэгтэй серверүүдийг ажиллуулдаг. Гуравдагч талын серверүүд ихэвчлэн хамгийн алдаатай байх хандлагатай гэдгийг санаж байх хэрэгтэй. Жишээ нь imapd эсвэл popper серверийн хуучин хувилбарыг ажиллуулна гэдэг нь универсал root тасалбарыг бүх дэлхийд өгч байна гэсэн үг юм. Та няхуур шалгаагүй сервер битгий ажиллуул. Олон серверүүд заавал root эрхээр ажиллах шаардлагагүй байдаг. Жишээ нь ntalk, comsat, болон finger дэмонуудыг тусгай хэрэглэгчийн sandboxes буюу хамгаалагдсан хязгаарлагдмал орчинд ажиллуулах боломжтой байдаг. Хамгаалагдсан хязгаарлагдмал орчин нь асар их төвгүүдийг давж хийгээгүй л бол төгс биш бөгөөд өмнө дурдсан сонгины хандлагаар аюулгүй байдалд хандах нь хэвээр байна: хэрэв хэн нэгэн нь хамгаалагдсан хязгаарлагдмал орчинд ажиллаж байгаа серверт эвдэн орж чадсан ч гэсэн тэд хамгаалагдсан хязгаарлагдмал орчныг бас эвдэн гарах хэрэг болно. Аль болох олон давхаргыг халдагч эвдлэх ёстой болох тусам тэдгээрийн амжилттай болох нь улам багасах болно. Урьд нь root цоорхойнууд нь системийн үндсэн серверүүдээс авахуулаад бараг л бүх root ажилладаг сервер дээр олдож байсан. Хэрэв таны ажиллуулдаг машин уруу хүмүүс зөвхөн sshd ашиглан нэвтэрдэг бөгөөд telnetd, rshd эсвэл rlogind хэзээ ч ашиглан нэвтэрдэггүй бол эдгээр үйлчилгээнүүдийг хаагаарай! Одоо &os; нь ntalkd, comsat, болон finger үйлчилгээнүүдийг хамгаалагдсан хязгаарлагдмал орчинд анхдагчаар ажиллуулдаг. Хамгаалагдсан хязгаарлагдмал орчинд ажиллуулж болох өөр нэг програм нь &man.named.8; юм. /etc/defaults/rc.conf нь named-г хамгаалагдсан хязгаарлагдмал орчинд ажиллуулахад шаардлагатай нэмэлт өгөгдлүүдийг тайлбар хэлбэрээр агуулсан байдаг. Таны шинэ систем эсвэл байгаа системээ шинэчилж байгаагаас хамааран тэдгээр хамгаалагдсан хязгаарлагдмал орчинд ашиглагдах тусгай хэрэглэгчийн бүртгэлүүд суулгагдаагүй байж болох юм. Хянамгай сисадмин судалгаа хийж серверүүдийг хамгаалагдсан хязгаарлагдмал орчинд аль болох ажиллуулдаг. sendmail Хамгаалагдсан хязгаарлагдмал орчинд ерөнхийдөө ажилладаггүй хэд хэдэн серверүүд байдаг: sendmail, popper, imapd, ftpd, болон бусад. Эдгээрийн зарим шиг бас өөр серверүүд байдаг боловч тэдгээрийг суулгах нь таны хүсэж байгаагаас илүү (амархан байх гэсэн асуудал энд сөхөгдөж байна) их ажиллагаа шаардаж магадгүй юм. Та эдгээр серверүүдийг магадгүй root эрхээр ажиллуулж тэдгээрт учирч болох эвдрэн оролтуудыг илрүүлэх өөр арга замуудад найдах хэрэгтэй болж болох юм. Системийн өөр нэг том боломжтой root цоорхойнууд бол системд суусан suid-root болон sgid хоёртын файлууд юм. rlogin зэрэг эдгээрийн ихэнх нь /bin, /sbin, /usr/bin, эсвэл /usr/sbin сангуудад байрладаг. Юу ч 100% аюулгүй байдаггүй боловч системийн анхдагч suid болон sgid хоёртын файлууд нь боломжийн хэрээр аюулгүй гэж тооцогддог. Гэсэн хэдий ч эдгээр хоёртын файлуудад root цоорхойнууд үе үе олддог. xterm-г (энэ нь ихэвчлэн suid байдаг) эмзэг болгосон root цоорхойнууд 1998 онд Xlib-д олджээ. Харамсахаасаа өмнө аюулгүй байж байсан нь дээр учраас хянамгай сисадмин зөвхөн staff ажиллуулах ёстойгоор staff зөвхөн хандаж чадах тусгай бүлэгт зөвшөөрч suid хоёртын файлуудыг хязгаарладаг бөгөөд хэн ч ашигладаггүй suid хоёртын файлуудыг ажиллуулж болохгүй болгодог (chmod 000). Дэлгэцгүй серверт ер нь xterm хоёртын файл хэрэгцээгүй юм. Sgid хоёртын файлууд нь бас л аюултай юм. Хэрэв халдагч sgid-kmem хоёртын файлыг эвдэж чадвал тэр /dev/kmem-г уншиж чадах бөгөөд ингэснээр нууц үгтэй дурын бүртгэлийг эвдэн орж шифрлэсэн нууц үгийн файлыг уншихад хүргэдэг. Бас kmem бүлгийг эвдсэн халдагч secure буюу аюулгүй аргаар дамжин нэвтрэн орсон хэрэглэгчдийн ашиглаж байгаа pty-уудаар илгээгдсэн гарын товчнуудын даралтуудыг хянаж чаддаг. tty бүлгийг эвдсэн халдагч бараг дурын хэрэглэгчийн tty-д бичиж чадна. Хэрэв хэрэглэгч гар дуурайх боломж бүхий терминал програм эсвэл эмулятор ажиллуулж байгаа бол хэрэглэгчийн терминалыг тушаал буцаан харуулахаар болгодог өгөгдлийн урсгалыг халдагч үүсгэж дараа нь тэр тушаалыг тэр хэрэглэгчийн эрхээр ажиллуулдаг. Хэрэглэгчийн бүртгэлүүдийг аюулгүй болгох Хэрэглэгчийн бүртгэлүүдийг аюулгүй болгох нь ихэвчлэн хамгийн хэцүү байдаг. Та өөрийн staff-д ширүүн хандалтын хязгаарлалтууд оногдуулж тэдгээрийн нууц үгүүдийг од болгож болох боловч та ердийн хэрэглэгчийн бүртгэлүүдийг яг ингэж хязгаарлаж чадахгүй байж болох юм. Хэрэв та хангалттай хяналттай байх юм бол таны аз болж хэрэглэгчийн бүртгэлүүдийг зөвөөр аюулгүй болгож чадна. Хэрэв үгүй бол та тэдгээр бүртгэлүүдийг хянахдаа ердөө л илүү сонор сэрэмжтэй байх хэрэгтэй. ssh болон Kerberos-г хэрэглэгчийн бүртгэлүүдэд ашиглах нь нэмэлт удирдлага болон техникийн дэмжлэг шаардлагатайгаас болоод илүү асуудалтай байдаг боловч энэ нь шифрлэсэн нууц үгийн файлыг бодох юм бол маш сайн шийдэл хэвээр байдаг. Нууц үгийн файлыг аюулгүй болгох Цорын ганц итгэлтэй арга бол аль болох олон нууц үгүүдийг од болгон тэдгээр бүртгэлүүдэд хандахын тулд ssh эсвэл Kerberos ашигла. Шифрлэгдсэн нууц үгийн файлыг (/etc/spwd.db) зөвхөн root уншиж чаддаг боловч халдагч root-бичих хандалт олж авч чадаагүй ч гэсэн тэр файлд унших эрх олж авах боломжтой байж болох юм. Таны аюулгүй байдлын скриптүүд нууц үгийн файлд хийгдсэн өөрчлөлтүүдийг үргэлж шалгаж тайлагнах шаардлагатай (доорх Файлын бүрэн бүтэн байдлыг шалгах хэсгийг үзнэ үү). Цөмийн гол хэсэг, түүхий төхөөрөмжүүд болон файлын системүүдийг аюулгүй болгох Хэрэв халдагч root-г эвдсэн бол тэр юуг ч хийж чадах боловч зарим ашиг сонирхлууд байдаг. Жишээ нь орчин үеийн ихэнх цөмүүдэд пакет шиншлэх төхөөрөмжийн драйвер бүтээгдсэн байдаг. &os;-д энэ нь bpf төхөөрөмж гэж нэрлэгддэг. Халдагч ердөө буулган авсан машин дээрээ пакет шиншлэгчийг ажиллуулахыг оролддог. Та халдагчид энэ боломжийг өгөх хэрэггүй бөгөөд ихэнх системүүдэд bpf төхөөрөмжийг эмхэтгэн оруулах шаардлагагүй юм. sysctl Гэхдээ bpf төхөөрөмжийг хаасан ч гэсэн та /dev/mem болон /dev/kmem файлуудад бас санаа тавих хэрэгтэй. Энэнээс болоод халдагч түүхий (raw) төхөөрөмжүүдэд бичиж чадсан хэвээр байна. Мөн цөмийн бас нэг боломж болох модуль ачаалагч гэж нэрлэгддэг &man.kldload.8; байдаг. Самбаатай халдагч KLD модуль ашиглаад өөрийн bpf төхөөрөмж эсвэл бусад шиншлэх төхөөрөмжийг ажиллаж байгаа цөмд суулгадаг. Эдгээр асуудлуудаас зайлсхийхийн тулд та цөмийг илүү өндөр аюулгүй байдлын түвшинд ядаж аюулгүйн түвшин 1-д ажиллуулах хэрэгтэй. Аюулгүй түвшин sysctl тушаалаар kern.securelevel хувьсагчийн тусламжтай тохируулагдаж болно. Аюулгүйн түвшинг 1 болгосны дараа түүхий төхөөрөмжүүдэд бичих хандалт хийхийг хориглох бөгөөд schg зэрэг chflags тугууд үйлчлэх болно. Мөн та чухал эхлүүлэх хоёртын файлууд, сангууд болон скрипт файлууд, ер нь аюулгүйн түвшин заагдах хүртэл ажиллаж байгаа бүгдэд schg туг байгаа эсэхийг шалгах хэрэгтэй. Энэ нь хэтэрхий болж болох бөгөөд таныг илүү өндөр аюулгүйн түвшинд ажиллаж байгаа үед системийг шинэчлэхийг бүр илүү төвөгтэй болгодог юм. Та буулт хийж системийн бүх файл болон санд schg тугийг зааж өгөлгүйгээр системийг өндөр аюулгүйн түвшинд ажиллуулж болох юм. Өөр нэг боломж нь / болон /usr санг ердөө л зөвхөн уншихаар холбох явдал юм. Хамгаалах зүйлдээ хэт ширүүн байх нь булаан эзлэлтийн бүх чухал илрүүлэлтийг бас болиулж болохыг санахад илүүдэхгүй. Файлын бүрэн бүтэн байдлыг шалгах нь: Хоёртын файлууд, Тохиргооны файлууд, гэх мэт. Тэр мөч ирэхэд, та зөвхөн системийн гол тохиргоо болон хяналтын файлуудаа ая тухын хүчин зүйл урьтахаас хамаагүй өмнө хамгаалж чадна. Жишээ нь chflags тушаал ашиглан / болон /usr сангууд дахь ихэнх файлуудад schg битийг тохируулах нь магадгүй үр ашиггүй байж болох бөгөөд учир нь ингэснээр файлуудыг хамгаалахын хажуугаар бас илрүүлэх цонхыг хаадаг юм. Таны аюулгүй байдлын сонгины сүүлийн давхарга нь илрүүлэлт бөгөөд энэ нь хамгийн чухал юм. Хэрэв та боломжит халдагчдыг илрүүлж чадахгүй л бол аюулгүй байдлын бусад үлдсэн асуудлуудын талаар бодоод ч бараг хэрэггүй юм (эсвэл бүр дэмий юм, аюулгүй байдлыг танд буруу ойлгуулахад хүргэдэг). Сонгины ажлын хагас нь халдагчийг үйлдэл дээр нь барихын тулд түүнийг зогсоохын оронд харин удаашруулах явдал юм. Халдлагыг илрүүлэх хамгийн сайн арга бол өөрчлөгдсөн, алга болсон, эсвэл гэнэтийн файлуудыг хайх явдал юм. Өөрчлөгдсөн файлуудыг хайх хамгийн сайн арга бол тэдгээрийг өөр (ихэвчлэн төвлөрсөн) хязгаарлагдмал хандалттай системээс хайх явдал юм. Өөрийн аюулгүй байдлын скриптийг нэмэлт аюулгүй байдал хангасан хязгаарлагдмал хандалттай систем дээр бичих нь тэдгээрийг боломжит халдагчдад бараг харагдуулдаггүй бөгөөд энэ нь чухал юм. Давуу талыг хамгийн ихээр авахын тулд ерөнхийдөө хязгаарлагдмал хандалттай хайрцагт бусад машинуудад хандах тэр ач холбогдолтой хандалтыг өгөх хэрэгтэй. Үүнийг ихэвчлэн бусад машинуудын зөвхөн унших NFS экспортыг хязгаарлагдмал хандалттай хайрцагт өгөх эсвэл ssh түлхүүр хослолыг тохируулж хязгаарлагдмал хандалттай хайрцгийг бусад машинууд уруу ssh хийхийг зөвшөөрөх замаар хийдэг. Өөрийн сүлжээний урсгалыг тооцохгүй юм бол NFS нь хамгийн харагддаггүй арга юм — энэ нь клиент хайрцаг бүр дэх файлын системүүдийг монитор хийхийг танд зөвшөөрч бараг л илэрдэггүй. Хэрэв таны хязгаарлагдмал хандалттай сервер нь клиент хайрцагнууд уруу hub буюу салаалагч эсвэл чиглүүлэлтийн хэд хэдэн давхаргаар дамжин холбогдсон бол NFS арга нь хэтэрхий аюултай (сүлжээний хувьд) байж болох бөгөөд ssh-ийг ашиглах нь түүний гаргадаг аудит мөрийн замуудтай байсан ч гэсэн магадгүй илүү сонголт байж болох юм. Монитор хийгдэх клиент систем уруу хандахад хамгийн багаар бодоход унших эрхийг та хязгаарлагдмал хандалттай хайрцагт өгсний дараа яг мониторыг хийхдээ скрипт бичих хэрэгтэй. Өгөгдсөн NFS холболтод &man.find.1; болон &man.md5.1; зэрэг энгийн системийн хэрэгслүүд ашиглан та скриптүүд бичиж болно. Клиент хайрцгийн файлуудад өдөрт нэг удаа физикээр md5 хийж /etc болон /usr/local/etc сангууд дахь хяналтын файлуудыг бүр илүү давтамжтайгаар шалгаж байх нь зүйтэй юм. Хязгаарлагдмал хандалттай машины зөв гэж тооцсон md5 мэдээлэлтэй харьцуулахад тарахгүй файлууд олдвол сисадминд үүнийг очиж шалгахыг хашгиран мэдээлэх ёстой. Аюулгүй байдлын сайн скрипт нь тохирохгүй suid хоёртын файлууд болон / болон /usr зэрэг системийн хуваалтууд дээрх шинээр үүссэн эсвэл устгагдсан файлуудыг бас шалгадаг. NFS биш ssh-ийг ашиглаж байх үед аюулгүй байдлыг скрипт бичих нь бүр илүү хэцүү байдаг. Та скриптүүдийг харагдуулж ажиллуулахын тулд тэдгээрийг клиент хайрцаг уруу үндсэндээ scp хийх хэрэгтэй бөгөөд аюулгүй байдлаа бодох юм бол та тэдгээр скриптүүдийн ашигладаг хоёртын файлуудыг (find гэх зэрэг) бас scp хийх хэрэгтэй юм. Клиент хайрцаг дээрх ssh клиент аль хэдийн эвдэгдсэн байж болох юм. Аюултай холболтоор ажиллаж байгаа бол ssh-г ашиглах нь шаардлагатай байж болох боловч бас түүнтэй ажиллахад бүр илүү хэцүү байдаг юм. Аюулгүй байдлын сайн скрипт нь .rhosts, .shosts, .ssh/authorized_keys гэх зэрэг MD5 шалгалтын хүрээний гадуур байх хэрэглэгч болон staff-ийн гишүүдийн хандалтын тохиргооны файлууд дахь өөрчлөлтүүдийг бас шалгадаг. Хэрэв та асар их хэрэглэгчийн дискний зайтай бол тэдгээр хуваалтууд дээр байгаа файл бүр дээр ажиллахад хэт удаж болох юм. Энэ тохиолдолд suid хоёртын файлуудыг хаах холболтын тугуудыг зааж өгөх нь зүйтэй юм. nosuid нь таны хайж байгаа тэр тохируулга юм. Энэ давхаргын зорилго нь эвдлэн оролтын оролдлогуудыг амжилттай эсвэл амжилтгүй болсноос үл хамааран илрүүлэх явдал учраас ямар ч гэсэн ядаж долоо хоногт нэг удаа та тэдгээр файлуудыг магадгүй шалгаж байх хэрэгтэй юм. Процессийн бүртгэл хийх нь (&man.accton.8;-г үзнэ үү) эвдлэн оролтын дараах үнэлэх арга замууд болон тусалж болох харьцангуй бага ачаалал бүхий үйлдлийн системийн боломж юм. Энэ нь эвдлэн орсны дараа файлыг хөндөөгүй хэвээр гэж үзэн халдагч систем уруу хэрхэн эвдлэн орсныг мөрдөхөд ялангуяа ашигтай байдаг. Эцэст нь аюулгүй байдлын скриптүүд нь бүртгэлийн файлуудыг процесс хийх ёстой бөгөөд бүртгэлүүд өөрсдөө аль болох аюулгүй байдлаар үүсгэгдэх ёстой бөгөөд алсын syslog нь их ашигтай байж болох юм. Халдагч өөрийн мөрийг арилгахыг оролдох бөгөөд эхний эвдлэн оролтын арга болон хугацааг мөрдөхөд сисадмины хувьд бүртгэлийн файлууд нь маш чухал байдаг юм. Бүртгэлийн файлуудын байнгын бичлэгийг хадгалах нэг арга нь системийн консолыг сериал порт уруу ажиллуулж консолуудыг хянаж аюулгүй машин дээр мэдээллийг цуглуулах явдал юм. Параной буюу хэт зовнил Бага зэргийн хэт зовнил буруудахгүй. Дүрэм болгож тав тухтай байдлыг алдагдуулдаггүй дурын тооны аюулгүй байдлын боломжуудыг сисадмин нэмж болох бөгөөд зарим анхаарлыг бодолцон тав тухтай байдалд нөлөөлөх аюулгүй байдлын боломжуудыг бас нэмж болох юм. Бүр илүү чухал нь аюулгүй байдлын администратор үүнийг бага зэрэг хольж хэрэглэж болно — хэрэв та энэ баримтад дурдсан заавруудыг үгчлэн ашиглавал энэ баримтыг уншсан ирээдүйн халдагчид та өөрийн арга замуудыг заан өгч байна гэсэн үг юм. Үйлчилгээг Зогсоох Халдлагууд Үйлчилгээг Зогсоох (DoS) Энэ хэсэг нь Үйлчилгээг Зогсоох халдлагуудыг хамарна. DoS халдлага нь ихэвчлэн пакетийн халдлага байдаг. Таны сүлжээг дүүргэж байгаа орчин үеийн хууран мэхэлсэн пакетийн халдлагуудын эсрэг нэг их юм хийж чадахгүй ч гэсэн халдлагууд таны серверүүдийг унагахгүйн тулд та ерөнхийдөө хохирлыг хязгаарлаж болно: Серверийн fork хийлтийг хязгаарлах. Springboard буюу бусад халдлагуудыг хязгаарлах (ICMP хариу халдлагууд, ping цацалт, гэх мэт.). Цөмийн чиглүүлэлтийн кэшийг хэт ачаалах. Нийтлэг DoS халдлагын дүр зураг бол fork хийгдэж байгаа серверт халдаж түүнээр асар их хүүхэд процесс үүсгүүлж эцсийн эцэст хост системийн хувьд санах ой, файлын тодорхойлогчууд гэх мэтүүд дуусч зогсоход хүргэдэг. inetd (&man.inetd.8;-г үзнэ үү) нь энэ төрлийн халдлагыг хязгаарлах хэд хэдэн тохируулгатай. Машиныг зогсоохоос хамгаалах боломжтой боловч ерөнхийдөө үйлчилгээг халдлагад өртүүлэхгүй байх боломжгүйг энд тэмдэглэх нь зүйтэй юм. inetd гарын авлагын хуудсыг анхааралтай уншиж , , болон тохируулгуудад ялангуяа анхаарлаа хандуулаарай. Хууран мэхэлсэн IP халдлагууд нь inetd дахь тохируулгыг хуурах учраас ихэвчлэн тохируулгуудын хослолыг ашиглах шаардлагатай. Зарим дан серверүүд өөрийн fork хийгдэхийг хязгаарлах параметрүүдтэй байдаг. Sendmail нь тохируулгатай байдаг бөгөөд энэ нь Sendmail-ийг ачаалал хязгаарлах тохируулгатай ажиллуулж ачааллын хоцрогдол үүсгэснээс хавьгүй илүүтэйгээр ажилладаг. Та Sendmail-г ажиллуулахдаа хүссэн ачааллыг даахаар гэхдээ компьютерийг унагахаар их хэмжээний тоогоор Sendmail-үүдийг ажиллуулах биш түүнээс багаар MaxDaemonChildren параметрийг хангалттай өндрөөр тавьж өгөх хэрэгтэй. Мөн sendmail-ийг дарааллын горимоор () ажиллуулах болон дэмонг (sendmail -bd) дараалалтай (sendmail -q15m) ажиллуулдгаас тусад нь ажиллуулах нь чухал юм. Хэрэв та шууд илгээх горимыг хүсэж байгаа бол та дарааллыг зэргээр бүр бага интервалаар ажиллуулах боломжтой боловч MaxDaemonChildren тохируулгыг боломжийн утгаар хоорондоо холбоотой амжилтгүйтлүүдээс sendmail-ийг хамгаалахын тулд зааж өгсөн эсэхээ шалгаарай. Syslogd-д шууд халдаж болох учраас аль болох тохируулгыг эсвэл тохируулгыг ашиглахыг танд зөвлөдөг. Шууд халдлага хийгдэж болох TCP Wrapper-ийн буцах identd зэрэг буцан холбогддог үйлчилгээнүүдийн хувьд та маш хянамгай байх хэрэгтэй. Ийм учраас та TCP Wrapper-ийн буцах identd боломжийг ерөнхийдөө ашиглах хэрэггүй юм. Та өөрийн захын чиглүүлэгчүүд дээрээ дотоод үйлчилгээнүүд уруугаа гаднаас хандуулахгүй болгож галт ханаар хамгаалах нь зүйтэй юм. Үүний цаадах санаа нь гаднаас ирж болзошгүй сүлжээ дүүргэх халдлагаас өөрийн LAN-г хамгаалах явдал бөгөөд сүлжээн дээр тулгуурласан root эрхийг буулгахаас дотоод үйлчилгээнүүдийг хамгаалах зүйлс тийм их биш юм. exclusive буюу хамааруулаагүй галт ханыг үргэлж тохируулах хэрэгтэй, өөрөөр хэлбэл A, B, C, D болон M-Z портуудаас бусад бүгдийг галт ханаар хамгаалах хэрэгтэй. Ингэснээр та named (хэрэв та бүсийн хувьд анхдагч бол), ntalkd, sendmail болон бусад Интернэтээс хандах үйлчилгээнүүд зэрэг зарим нэг тусгай үйлчилгээнүүдийн портуудаас бусад бүх бага дугаарын портуудыг галт ханаар хамгаалж чадах юм. Хэрэв та галт ханыг өөр аргаар — inclusive буюу хамааруулсан эсвэл зөвшөөрсөн галт хана маягаар тохируулахыг оролдвол хэд хэдэн үйлчилгээнүүдийг хаахаа мартаж магадгүй юм, эсвэл та шинэ дотоод үйлчилгээ нэмээд галт ханаа шинэчлэхээ мартаж болох юм. Та галт хана дээр зөвшөөрсөнтэй адил үйлдлийг нэвтрүүлэхийн тулд бага дугаарын портуудыг нээлгүйгээр өндөр дугаарын портуудыг онгойлгож болох юм. Мөн &os; нь динамик холболтод хэрэглэгддэг портуудыг sysctl-ийн төрөл бүрийн net.inet.ip.portrange хувьсагчуудаар (sysctl -a | fgrep portrange) хянах боломжийг танд олгодгийг бас тэмдэглэх нь зүйтэй юм. Энэ нь бас таны галт ханын тохиргооны төвөгтэй байдлыг амарчилдаг юм. Жишээ нь та ердийн 4000-аас 5000 хүртэлх портууд болон 49152-оос 65535 хүртэлх өндөр дугаарын портуудыг ашигладаг бол 4000-аас бага бүгдийг өөрийн галт хана дээр хаах хэрэгтэй (мэдээж Интернэтээс ханддаг хэдэн тусгай портуудаас бусад). Өөр нийтлэг DoS халдлагуудын нэг нь springboard халдлага юм — сервер, дотоод сүлжээ эсвэл бусад машиныг хариу үйлдэл хийхийг нь ихэсгэж хэт ачаалахад хүргэдэг халдлага юм. Ийм маягийн хамгийн нийтлэг халдлага нь ICMP ping broadcast буюу цацалт юм. Халдагч таны LAN-ий цацах хаяг уруу илгээсэн ping пакетийнхаа эхлэл IP хаягийг халдахыг хүсэж байгаа машиныхаа IP хаягаар сольж хуурдаг. Хэрэв таны захын чиглүүлэгчүүд цацах хаяг уруу илгээх ping пакетуудыг зогсоохоор тохируулагдаагүй бол таны LAN хангалттай хариу үүсгэн хууран мэхэлсэн эхлэл хаяг уруу илгээж, ялангуяа халдагч хэдэн арван цацах хаягууд уруу өөр өөр хэдэн арван сүлжээнүүдээр дамжин энэ башир аргаа ашигласан үед, хохирогчийг дүүргэдэг. 120 мегабайтаас илүү хэмжээний цацах халдлага одоогоор хэмжигдээд байна. Энэ төрлийн хоёр дахь нийтлэг халдлага нь ICMP-ийн алдаа тайлагнах системийн эсрэг халдлага юм. ICMP алдааны мэдэгдэл үүсгэдэг пакетуудыг бүтээж халдагч серверийн орж ирж байгаа сүлжээг дүүргэж ингэснээр серверийг өөрийн гарах сүлжээг ICMP хариунуудаар дүүргэхэд хүргэдэг. Энэ төрлийн халдлага нь ялангуяа хэрэв сервер үүсгэж байгаа ICMP хариунуудаа хангалттай хурднаар шавхан гаргаж чадахгүй байгаа бол серверийг санах ойгүй болгож сүйрүүлж бас болох юм. sysctl-ийн net.inet.icmp.icmplim хувьсагчийг ашиглан эдгээр халдлагуудыг хязгаарлах хэрэгтэй. Springboard төрлийн халдлагуудын сүүлийн гол ангилал нь udp цуурай үйлчилгээ зэрэг зарим дотоод inetd үйлчилгээнүүдтэй холбоотой юм. Халдагч UDP пакетийг хууран мэхэлж A болон B сервер нь хоёулаа таны LAN-д байгаа тийм A серверийн цуурай порт дээрх эхлэл хаягаар болон төгсгөл хаягийг B серверийн цуурай порт дээрх хаягаар сольдог. Уг хоёр сервер дараа нь энэ ганц пакетийг хоорондоо шидэлцдэг. Эдгээр серверүүд болон тэдгээрийн LAN-г энэ маягаар халдагч хэдхэн пакетуудыг хатган оруулан хэт ачаалж чаддаг. Үүнтэй адил асуудлууд дотоод chargen портод бас байдаг. Чадварлаг сисадмин эдгээр бүх дотоод inetd тест үйлчилгээнүүдийг хаадаг. Хууран мэхэлсэн пакетийн халдлагуудыг цөмийн чиглүүлэлтийн кэшийг хэт ачаалахад хэрэглэж болдог. net.inet.ip.rtexpire, rtminexpire, болон rtmaxcache sysctl параметрүүдийг үзнэ үү. Дурын эхлэл IP хаягийг ашигласан хууран мэхэлсэн пакетийн халдлага нь чиглүүлэлтийн хүснэгтэд түр зуур кэш хийгдсэн чиглүүлэлтийг цөмөөр үүсгүүлэхэд хүргэдэг бөгөөд энэ нь netstat -rna | fgrep W3 тушаалаар харагддаг. Эдгээр чиглүүлэлтүүд нь ихэвчлэн 1600 секунд орчим хугацааны дотор дуусдаг. Хэрэв цөм кэш хийгдсэн чиглүүлэлтийн хүснэгт хэтэрхий том болсныг илрүүлэх юм бол rtexpire динамикаар багасгадаг боловч rtminexpire-с бага болтол хэзээ ч багасгадаггүй. Хоёр асуудал байдаг: Бага ачаалагдсан сервер гэнэт халдлагад өртөхөд цөм хангалттай хурдан хариу үйлдэл хийдэггүй. rtminexpire хувьсагч нь үргэлжилсэн халдлагыг цөм дааж чадахаар хангалттай бага байдаггүй. Хэрэв таны серверүүд Интернэтэд T3 эсвэл илүү хурдаар холбогдсон бол &man.sysctl.8;-оор rtexpire болон rtminexpire хувьсагчуудыг хоёуланг гараар дарж бичихдээ хянамгай байх хэрэгтэй. Аль ч параметрийг (машиныг сүйрүүлэхийг та хүсээгүй л бол) хэзээ ч битгий 0 болгоорой. Эдгээр параметрүүдийг хоёуланг нь 2 секунд болгох нь чиглүүлэлтийн хүснэгтийг халдлагаас хамгаалахад хангалттай байх ёстой. Kerberos болон SSH-тэй холбоотой хандалтын асуудлууд ssh KerberosIV Хэрэв та Kerberos болон ssh-г хоёуланг ашиглахаар бол цөөн хэдэн асуудлуудыг дурдах хэрэгтэй. Kerberos 5 нь жинхэнийг шалгах маш сайн нэвтрэлтийн протокол боловч түүнийг ашигласан telnet болон rlogin-д байдаг алдаанууд нь энэ хоёр програмыг хоёртын урсгалтай ажиллахад тохиромжгүй болгодог. Мөн тохируулгыг ашиглахгүй л бол анхдагчаар Kerberos нь сессийг шифрлэдэггүй. ssh нь бүгдийг шифрлэдэг. Ssh нь анхдагчаар шифрлэсэн түлхүүрүүдээ дамжуулдгаас бусад бүх л талаараа зэгсэн сайн ажилладаг. Энэ нь юу гэсэн үг вэ гэхээр та хэрэв системийн бусад хэсэгт хандах боломж олгодог түлхүүрүүд бүхий аюулгүй ажлын компьютертай бөгөөд та аюултай машин уруу ssh хийвэл таны түлхүүрүүд ашиглагдах боломжтой гэсэн үг юм. Яг түлхүүрүүд нь өөрсдөө ил гардаггүй боловч ssh нь таны нэвтэрсэн хугацааны туршид зориулж дамжуулах порт суулгадаг бөгөөд хэрэв халдагч аюулгүй машин дээрх root-г эвдсэн бол тэрхүү портыг таны түлхүүрүүдийг ашиглахын тулд хэрэглэн таны түлхүүрээр тайлагдах өөр бусад машинуудад хандах боломжийг олж авах боломжтой юм. Бид staff нэвтрэлтүүдийн хувьд аль болох ssh-г Kerberos-той цуг ашиглахыг зөвлөдөг. Ssh нь Kerberos-ийн дэмжлэгтэй эмхэтгэгдэж болдог. Энэ нь ил гарсан байж болзошгүй ssh түлхүүрүүдэд найдах таны найдварыг багасгахын хамт нууц үгүүдийг Kerberos-оор хамгаалдаг. Ssh түлхүүрүүд нь аюулгүй машинуудын автоматчилагдсан ажлуудад (Kerberos-оор хийхэд таарахгүй) зөвхөн хэрэглэгдэх ёстой. Мөн бид таныг ssh-ийн тохиргоондоо key-forwarding буюу түлхүүр дамжуулалтыг болиулах эсвэл ssh-ийн authorized_keys файлдаа зөвхөн тусгайлсан машинуудаас нэвтрэхэд түлхүүрийг ашиглаж болохоор болгож зөвшөөрдөг from=IP/DOMAIN тохируулгыг ашиглахыг зөвлөдөг. Билл Свингл Хэсгүүдийг дахин бичиж шинэчилсэн DES, MD5, болон Crypt аюулгүй байдал crypt crypt Blowfish DES MD5 &unix; систем дээрх хэрэглэгч бүрийн хувьд нууц үг бүртгэлтэй нь холбоотой байдаг. Мэдээж эдгээр нууц үгүүд нь зөвхөн хэрэглэгч ба үйлдлийн системд мэдэгдэж байх ёстой. Эдгээр нууц үгүүдийг нууцлаг байлгахын тулд тэдгээрийг one-way hash буюу үл буцах хэш гэгддэг шифрлэхэд амархан боловч буцааж болдоггүй аргаар шифрлэдэг. Өөрөөр хэлбэл хормын өмнө мэдээж гэж хэлсэн бидний хэлсэн үг яг жинхэнэдээ үнэн биш юм: үйлдлийн систем өөрөө нууц үгийг жинхэнэдээ мэддэггүй. Энэ нь зөвхөн нууц үгийн шифрлэсэн хэлбэрийг мэддэг. plain-text буюу ердийн уншигдах текст хэлбэрийн нууц үгийг авах цорын ганц арга нь боломжит нууц үгүүдийн орон зайгаас балмадаар хүчлэн хайх явдал юм. Харамсалтай нь &unix; бий болсон тэр үед нууц үгийг аюулгүй аргаар шифрлэх цорын ганц арга нь DES, Data Encryption Standard буюу Өгөгдөл Шифрлэх Стандарт дээр үндэслэсэн байлаа. Энэ нь АНУ-д оршин сууж байсан хэрэглэгчдийн хувьд тийм ч асуудалтай биш байсан юм, гэхдээ DES-ийн эх код АНУ-аас гадагшаа экспорт хийгдэж болохгүй байсан учир &os; нь АНУ-ын хуулийг дагахын хажуугаар DES-ийг ашигласан хэвээр байсан бусад бүх &unix; төрлүүдтэй нийцтэй байх арга замыг хайж олоход хүрсэн юм. Үүний шийдэл нь АНУ-ын хэрэглэгчид DES сангуудыг суулгаж ашиглах боломжтой мөртлөө олон улсын хэрэглэгчид гадагш экспорт хийгдэж болох шифрлэх аргатай бас байхаар шифрийн сангуудыг хуваасан явдал байлаа. Ингэж &os; нь MD5-ийг өөрийн анхдагч шифрлэх аргаа болгон ашиглах болсон юм. MD5 нь DES-ээс илүү аюулгүй нууцлаг гэгддэг бөгөөд DES-ийг суулгах нь үндсэндээ нийцтэй байх шалтгаануудын улмаас зориулагдсан юм. Өөрийн Crypt арга замыг таних нь Одоогоор шифрийн сан DES, MD5 болон Blowfish хэш функцуудыг дэмждэг. Анхдагчаар &os; нь MD5 ашиглан нууц үгүүдийг шифрлэдэг. &os; аль шифрлэх аргыг тохируулж ашиглаж байгааг мэдэх хялбар байдаг. /etc/master.passwd файл дахь шифрлэсэн нууц үгийг шалгах нь нэг арга юм. MD5 хэшээр шифрлэгдсэн нууц үгүүд нь DES-р шифрлэгдсэнийгээ бодох юм бол урт бөгөөд $1$ тэмдэгтээр бас эхэлдэг. $2a$ тэмдэгтээр эхэлсэн нууц үгүүд Blowfish хэш функцаар шифрлэгдсэн байдаг. DES мөр нь ямар нэг тусгайлан таньж болох шинж тэмдэггүй байдаг боловч тэд MD5 нууц үгүүдээс богино бөгөөд $ тэмдэгт ордоггүй 64 тэмдэгттэй цагаан толгойгоор кодчилогддог, тиймээс долларын тэмдэгтээр эхлээгүй харьцангуй богино мөр ихэвчлэн DES нууц үг байдаг. Шинэ нууц үгүүдэд ашиглагдах нууц үгийн хэлбэр нь нэвтрэлтийн passwd_format боломжийн тусламжтай /etc/login.conf файлд хянагддаг бөгөөд энэ хувьсагч нь des, md5 эсвэл blf утгуудыг авдаг. Нэвтрэлтийн боломжуудын талаар дэлгэрэнгүй мэдээллийг &man.login.conf.5; гарын авлагын хуудаснаас үзнэ үү. Нэг удаагийн нууц үгүүд нэг удаагийн нууц үгүүд аюулгүй байдал нэг удаагийн нууц үгүүд Анхдагчаар &os; OPIE (One-time Passwords In Everything буюу Бүхэнд зориулсан нэг удаагийн нууц үгүүд) дэмжлэгтэй байдаг бөгөөд энэ нь MD5 хэшийг анхдагчаар ашигладаг. Бид гурван өөр төрлийн нууц үгийг доор хэлэлцэх болно. Эхнийх нь таны ердийн &unix; загварын эсвэл Kerberos нууц үг юм; бид үүнийг &unix; нууц үг гэж нэрлэх болно. Хоёр дахь төрөл нь OPIE &man.opiekey.1; програмаар үүсгэгдэж &man.opiepasswd.1; програм болон нэвтрэлт хүлээх мөр хүлээн авах нэг удаагийн нууц үг юм; бид үүнийг нэг удаагийн нууц үг гэх болно. Сүүлийн төрөл нууц үг бол opiekey програмд (заримдаа opiepasswd програмууд) өгдөг нууцлаг нууц үг бөгөөд үүнийг ашиглан дээрх програмууд нэг удаагийн нууц үг үүсгэдэг; бид үүнийг нууцлаг нууц үг гэх буюу эсвэл зүгээр л шалгагдаагүй нууц үг гэх болно. Нууцлаг нууц үг нь таны &unix; нууц үгтэй ямар ч холбоогүй юм; тэдгээр нь адил байж болох боловч ингэхийг зөвлөдөггүй. OPIE нууцлаг нууц үгүүд нь хуучин &unix; нууц үгүүд шиг 8 тэмдэгтэд хязгаарлагддаггүй &os; дээр стандарт нэвтрэх нууц үг уртаараа 128 тэмдэгт хүртэл байж болдог. бөгөөд таны хүссэн хэмжээний урттай байж болдог. Зургаа эсвэл долоон үг бүхий өгүүлбэрээс тогтох нууц үгүүд нэлээн элбэг байдаг. Ихэнх хэсгийн хувьд OPIE систем &unix;-ийн нууц үгийн системээс бүр мөсөн ангид ажилладаг. Нууц үгээс гадна OPIE-д чухал өгөгдлийн өөр хоёр хэсэг байдаг. Нэг нь seed буюу үр эсвэл key буюу түлхүүр гэгддэг бөгөөд 2 үсэг болон таван тооноос тогтдог. Нөгөөдөх нь давталтын тоо буюу 1-ээс 100 хүртэлх тоо юм. OPIE нэг удаагийн нууц үгийг үр болон нууцлаг нууц үгийг нийлүүлэн MD5 хэшийг давталтын тоогоор ашиглан үүсгэж үр дүнг нь зургаан богино Англи үг болгодог. Эдгээр зургаан Англи үг нь таны нэг удаагийн нууц үг юм. Нэвтрэлт шалгах систем (үндсэндээ PAM) ашигласан хамгийн сүүлийн нэг удаагийн нууц үгийг хадгалж байдаг бөгөөд хэрэглэгчийн өгсөн нууц үгийн хэш өмнөх нууц үгтэй таарч байвал хэрэглэгчийг нэвтрүүлдэг. Үл буцах хэш ашиглагддаг болохоор хэрэв амжилттайгаар ашиглагдсан нууц үгийг олж авсан бол дараа дараагийн нэг удаагийн нууц үгүүдийг үүсгэх боломжгүй байдаг; хэрэглэгч болон нэвтрэлтийн програмыг хамгийн сүүлийн хэлбэрт адилхан байлгаж байхын тулд давталтын тоо амжилттай нэвтрэлт хийгдэх бүрийн дараа багасаж байдаг. Давталтын тоо 1 хүрэх үед OPIE дахин хийгдэх хэрэгтэй болно. Систем болгоны хувьд хэдэн програмууд байдаг бөгөөд тэдгээрийг бид энд хэлэлцэх болно. opiekey програм давталтын тоо, үр болон нууцлаг нууц үгийг хүлээн авч нэг удаагийн нууц үг эсвэл нэг удаагийн нууц үгүүдийн үргэлжилсэн жагсаалтыг үүсгэдэг. opiepasswd програмыг OPIE-г эхлүүлэх болон нууц үг, давталтын тоо эсвэл үр өөрчлөхөд ашигладаг; энэ нь нууцлаг нэвтрэх үгс аль эсвэл давталтын тоо, үр болон нэг удаагийн нууц үгийг авдаг. opieinfo програм тохирох итгэмжлэлүүдийн файлуудыг (/etc/opiekeys) шалгаж ажиллуулсан хэрэглэгчийн одоогийн давталтын тоо болон үрийг дэлгэцэд гаргадаг. Бид дөрвөн өөр төрлийн үйлдлийн талаар хэлэлцэх болно. Эхнийх нь аюулгүй холболтоор opiepasswd ашиглаж нэг удаагийн нууц үгүүдийг эхний удаа тохируулах эсвэл өөрийн нууц үг эсвэл үрийг өөрчлөх үйлдэл юм. Хоёр дахь үйлдэл нь opiepasswd-г аюултай холболтоор, opiekey тушаалыг аюулгүй холболтоор ашиглаж адил үйлдлийг хийх явдал юм. Гурав дахь нь opiekey-г аюултай холболтоор ашиглан нэвтрэн орох үйлдэл юм. Дөрөв дэх нь opiekey-г ашиглан хэд хэдэн түлхүүрүүд үүсгэх үйлдэл бөгөөд гадагшаа аюулгүй холболтуудгүй газрууд уруу явахдаа тэдгээр түлхүүрүүдийг бичин авч эсвэл хэвлэн аваад өөртөө авч явж болох юм. Аюулгүй холболт эхлүүлэх OPIE-г эхний удаа эхлүүлэхдээ opiepasswd тушаалыг ажиллуул: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED Enter new secret pass phrase: эсвэл Enter secret password: мөрүүд дээр та нууц үг эсвэл өгүүлбэр оруулах ёстой. Энэ нь таны нэвтрэхдээ ашиглах нууц үг биш гэдгийг санах хэрэгтэй, үүнийг ашиглаж таны нэг удаагийн нэвтрэх түлхүүрийг үүсгэдэг. ID мөр таны тухайн үеийн параметрүүд болох таны нэвтрэх нэр, давталтын тоо болон үрийг өгдөг. Нэвтрэн орох үед систем эдгээр параметрүүдийг санаж танд тэдгээрийг санах шаардлагагүйгээр буцаан үзүүлдэг. Сүүлийн мөр нь тэдгээр параметрүүд болон таны нууцлаг нууц үгт харгалзах нэг удаагийн нууц үгийг өгдөг; хэрэв та нэн даруй дахин нэвтэрвэл энэ нэг удаагийн нууц үг нь таны ашиглах тэр нууц үг юм. Аюултай холболт эхлүүлэх Өөрийн нууцлаг нууц үгийг аюултай холболтоор эхэлж өгөхдөө эсвэл өөрчлөхдөө opiekey ажиллуулж болох тийм газар уруу аюулгүй холболттой байж байх шаардлагатай; энэ нь таны итгэж байгаа машин дээр бүрхүүлийн тушаал хүлээх мөр хэлбэрээр байж болно. Та бас давталтын тоог (100 боломжийн утга байж болох юм) бодож өгөх хэрэгтэй бөгөөд та өөрөө үр бодож олох эсвэл дурын үүсгэснийг ашиглах хэрэгтэй. Аюултай холболтоор (таны эхлүүлж байгаа машин уруу) opiepasswd тушаалыг ашигла: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Анхдагч үрийг хүлээж авах бол Return дар. Дараа нь хандах нууц үгийг оруулахын өмнө аюулгүй холболт уруугаа орж адил параметрүүдийг өгөөрэй: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Одоо аюултай холболт уруугаа шилжиж үүсгэсэн нэг удаагийн нууц үгээ тохирох програм уруу хуулаарай. Нэг удаагийн нууц үг ганцыг үүсгэх нь OPIE-г эхлүүлэн тохируулж нэвтэрсний дараа танд иймэрхүү тушаал хүлээх мөр харуулагдана: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> otp-md5 498 gr4269 ext Password: Энэ дашрамд тэмдэглэн хэлэхэд OPIE тушаал хүлээх мөрүүд ашигтай боломжтой байдаг: хэрэв та нууц үг хүлээх мөр дээр Return дарвал хүлээх мөр цуурайг идэвхжүүлж таны юу бичиж байгааг танд харуулдаг. Та хэвлэсэн зүйлээсээ харж магадгүй нууц үгийг гараараа бичиж оруулахыг оролдож байгаа бол энэ маш ашигтай байж болох юм. MS-DOS Windows MacOS Энэ үед нэвтрэлт хүлээх мөрөнд хариулахын тулд та өөрийн нэг удаагийн нууц үгийг үүсгэх хэрэгтэй болно. Үүнийг opiekey тушаал итгэн ажиллуулж чадах тийм систем дээрээ хийх хэрэгтэй. (DOS, &windows; болон &macos;-д зориулсан эдгээрийн хувилбарууд байдаг) Эдгээрт давталтын тоо болон үр тушаалын мөрийн тохируулга хэлбэрээр хэрэгтэй байдаг. Та нэвтрэн орж байгаа машиныхаа нэвтрэлт хүлээх мөрөөс эдгээрийг шууд хуулан тавьж болох юм. Итгэсэн систем дээрээ: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Одоо та өөрийн нэг удаагийн нууц үгтэй болсон болохоор нэвтрэлтээ үргэлжлүүлж болно. Нэг удаагийн нууц үг олныг үүсгэх нь Заримдаа та итгэсэн машин эсвэл аюулгүй холболт уруу хандах боломжгүй тийм газар очих хэрэгтэй болдог. Энэ тохиолдолд opiekey тушаал ашиглаж хэд хэдэн нэг удаагийн нууц үгүүдийг урьдчилан үүсгэж хэвлэн биедээ авч явах боломжтой юм. Жишээ нь: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI нь дараалсан таван түлхүүрийг үүсгэхийг, нь сүүлийн давталтын тоог хэд байх ёстойг зааж өгч байгаа юм. Эдгээр нь ашиглах бололцоотойг урвуу дарааллаар дэлгэцэнд харуулдгийг тэмдэглэх нь зүйтэй. Хэрэв та хэт санаа зовниж байгаа бол та үр дүнг гараар бичиж авахыг хүсэж болох юм; эсвэл lpr уруу хуулан авч тавьж болох юм. Мөр бүр давталтын тоо болон нэг удаагийн нууц үгийг харуулж байгааг анхаараарай; та нууц үгүүдийг хэрэглэх бүртээ тэдгээрийг арилгаж энэ хэвлэсэн арга тань ашигтай хэвээр болохыг мэдэж болох юм. &unix; нууц үгүүдийг ашиглахыг хязгаарлах нь OPIE нь &unix; нууц үгүүдийн ашиглалтыг нэвтрэлтийн сессийн IP хаяг дээр тулгуурлан хязгаарлаж чаддаг. Тохирох файл нь /etc/opieaccess бөгөөд энэ файл нь анхдагчаар байдаг. Энэ файлын талаар болон үүнийг ашигласнаар та аюулгүй байдлын ямар зүйлсүүдийг бодолцож анхаарах ёстой талаар дэлгэрэнгүй мэдээллийг &man.opieaccess.5;-с шалгана уу. Энд жишээ opieaccess файл байна: permit 192.168.0.0 255.255.0.0 Энэ мөр нь &unix; нууц үгүүдийг ямар ч үед ашиглахын тулд эхлэл IP хаягийг (хууран мэхлэхэд хүрч болох тийм эмзэг) заагдсан утга болон багтай тааруулах боломжийг хэрэглэгчдэд олгодог. opieaccess дахь аль ч дүрэм таарахгүй байгаа бол анхдагчаар OPIE биш нэвтрэлтүүдийг хааж үгүйсгэдэг. Том Рөүдс Бичсэн TCP Гүйцэтгэлийг хялбаршуулагчид TCP Гүйцэтгэлийг хялбаршуулагчид &man.inetd.8;-г мэддэг хэн бүхэн TCP Гүйцэтгэлийг хялбаршуулагчдын талаар заримдаа сонссон байх. Гэхдээ цөөн хүмүүс энэ боломжийн сүлжээний орчин дахь ашигтай талыг бүрэн ойлгодог юм шиг санагддаг. Хүн бүхэн сүлжээний холболтууд зохицуулах галт хана суулгахыг хүсдэг юм шиг санагддаг. Галт хана олон төрлийн хэрэглээтэй боловч холболт үүсгэгч уруу текст илгээх зэрэг зарим зүйлсийг галт хана хийж - чаддаггүй. Энд дурдсан TCP програм энэ мэтийг болон + чаддаггүй. Энд дурдсан TCP Гүйцэтгэлийг хялбаршуулагчид энэ мэтийг болон үүнээс илүүг хийдэг. Дараагийн хэдэн хэсэгт TCP Гүйцэтгэлийг хялбаршуулагчдын олон боломжуудыг хэлэлцэх бөгөөд боломжтой үед нь жишээ тохиргооны мөрийг үзүүлэх болно. TCP Гүйцэтгэлийг хялбаршуулагчид програм хангамж нь - inetd-ийн чадваруудыг сервер бүрийн + inetd-ийн чадваруудыг сервер бүрийн хувьд түүний доор хянагдаж болохоор дэмжин өргөтгөдөг. Энэ аргыг ашиглан бүртгэл хөтлөх дэмжлэг нэмэх, холболтууд уруу мэдэгдэл буцаах, дэмонд зөвхөн дотоод холболтуудыг хүлээн авахыг зөвшөөрөх гэх мэт үйлдлүүдийг хийх боломжтой. Эдгээр боломжуудын заримыг галт хана суулган тохируулж хийж болох боловч энэ нь зөвхөн хамгаалалтын нэмэлт давхарга болохоос гадна галт ханын үзүүлж чаддагаас илүү хяналтыг олгодог юм. TCP Гүйцэтгэлийг хялбаршуулагчдын ийнхүү нэмэгдсэн ажиллагаа нь сайн галт ханыг солихоор зүйл гэж ойлгогдох ёсгүй юм. TCP Гүйцэтгэлийг хялбаршуулагчид нь галт хана эсвэл өөр бусад аюулгүй байдлыг нэмэгдүүлэгч програмуудын хамтаар ашиглагдаж системийн хувьд хамгаалалтын нэмэлт давхарга болон аятайхан үйлчлэх боломжтой юм. - Энэ нь inetd-ийн тохиргооны өргөтгөл болохоор + Энэ нь inetd-ийн тохиргооны өргөтгөл болохоор энэхүү баримтыг уншигч таныг inetd тохиргоо хэсгийг уншсан гэдэгт найдаж байна. &man.inetd.8;-ээр ажиллуулагдсан програмууд яг жинхэнээрээ дэмонууд биш боловч тэдгээрийг уламжлалаар дэмонууд гэдэг. Энэ ухагдахууныг бид энэ хэсэгт бас ашиглах болно. Эхний тохиргоо TCP Гүйцэтгэлийг хялбаршуулагчдыг &os;-д - ашиглахад байх цорын ганц шаардлага нь inetd серверийг + ашиглахад байх цорын ганц шаардлага нь inetd серверийг rc.conf файлаас тохируулгатай ажиллуулсан эсэхийг шалгах явдал юм; энэ нь анхдагч тохиргоо юм. Мэдээж /etc/hosts.allow файлын зөв тохиргоо бас байгааг хүлээж байдаг боловч эдгээр тохиолдлуудад &man.syslogd.8; системийн бүртгэлүүдэд мэдэгдлүүд шиддэг. Бусад TCP Гүйцэтгэлийг хялбаршуулагчдын шийдлүүдтэй харьцуулах юм бол hosts.deny файлыг хэрэглэхээ больсон. Тохиргооны бүх сонголтууд /etc/hosts.allow файлд байх шаардлагатай. Хамгийн амархан тохиргоогоороо бол дэмоны холболтын бодлогууд зөвшөөрөгдсөн эсвэл хаагдсаны аль нэгээр /etc/hosts.allow файл дахь тохируулгуудаас хамааран тохируулагддаг. &os; дээрх анхдагч - тохиргоо нь inetd-ээр эхэлсэн дэмон бүр уруу хийгдэх + тохиргоо нь inetd-ээр эхэлсэн дэмон бүр уруу хийгдэх холболтыг зөвшөөрдөг. Үүнийг өөрчлөх талаар зөвхөн үндсэн тохиргооны тухай дурдсаны дараа хэлэлцэх болно. Үндсэн тохиргоо ихэвчлэн дэмон : хаяг : үйлдэл хэлбэрийг авдаг. Энд байгаа дэмон нь inetd-ийн эхлүүлсэн дэмоны нэр юм. Хаяг нь зөв хостын нэр, address хаяг эсвэл дөрвөлжин хаалтан ([ ]) доторх IPv6 хаяг байж болно. Үйлдэл талбар нь allow буюу зөвшөөрөх эсвэл deny буюу эрхийг хориглох эсвэл хандалтыг хаахын аль нэг байна. Тохиргоо эхний тохирсон дүрэм журмын дагуу ажилладаг гэдгийг санах хэрэгтэй, энэ нь тохирох дүрмийг тохиргооны файлаас өсөх дарааллаар хайна гэсэн үг юм. Тохирох дүрэм олдвол тэр дүрэм ашиглагдаж хайх процесс зогсоно. Бусад хэд хэдэн тохируулгууд байдаг боловч тэдгээрийг энэ хэсгийн сүүлд тайлбарлах болно. Хялбар тохиргооны мөр ганцхан тэр мэдээллийн дагуу амархнаар хийгдэж болно. Жишээ нь mail/qpopper дэмоноор дамжин хийгдэж болох POP3 холболтуудыг зөвшөөрөхийн тулд дараах мөрүүд hosts.allow файлд нэмж хийгдэх хэрэгтэй: # This line is required for POP3 connections: qpopper : ALL : allow - Энэ мөрийн нэмснийхээ дараа inetd-г дахин эхлүүлэх + Энэ мөрийг нэмснийхээ дараа inetd-г дахин эхлүүлэх хэрэгтэй. Үүнийг &man.kill.1; тушаал эсвэл /etc/rc.d/inetd-г restart параметртай ашиглан хийж болно. Дэвшилтэт тохиргоо TCP Гүйцэтгэлийг хялбаршуулагчид нь бас дэвшилтэт тохируулгуудтай байдаг; тэдгээр нь холболтуудтай хэрхэн ажиллахыг илүүтэйгээр хянах боломжийг олгодог. Зарим тохиолдолд тодорхой хостууд эсвэл дэмон холболтууд уруу тайлбар буцаах нь зүйтэй санаа байж болох юм. Бусад тохиолдолд магадгүй бүртгэлийн файл бичигдэх ёстой эсвэл цахим захидал администратор уруу илгээгдэж болох юм. Бусад тохиолдлууд үйлчилгээг зөвхөн дотоод холболтууддаа ашиглахыг шаардаж болох юм. Эдгээр нь бүгдээрээ орлуулагддаг тэмдэгтүүд, өргөтгөх тэмдэгтүүд болон гадаад тушаалыг ажиллуулах зэрэг тохиргооны сонголтуудын тусламжтай хийгдэх боломжтой юм. Дараагийн хоёр хэсэгт эдгээр тохиолдлуудын талаар бичсэн байгаа. Гадаад тушаалууд Холболтыг хааж түүнийг тогтоохыг оролдсон хүн уруу шалтгааныг нь илгээх тохиолдол гарчээ гэж бодъё. Үүнийг яаж хийх вэ? Энэ үйлдлийг тохируулга ашиглан хийх боломжтой. Холболт тогтоохоор оролдоход тохируулга бүрхүүлийн тушаал эсвэл скрипт ажилуулахаар дуудагддаг. hosts.allow файлд үүний жишээ аль хэдийн орсон байдаг: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." Энэ жишээ нь You are not allowed to use daemon from hostname. буюу Та дэмоныг hostname-с ашиглах зөвшөөрөлгүй. гэсэн мэдэгдлийг хандалтын файлд урьдаар тохируулагдаагүй дэмон бүрийн хувьд буцаадаг. Энэ нь тогтоогдсон холболт дөнгөж салсны дараа холболтыг эхлүүлэгч уруу хариултыг буцааж илгээхэд маш их ашигтай байдаг. Буцсан мэдэгдэл бүр " тэмдэгтүүд дотор заавал байх шаардлагатай; энэ дүрмэнд ямар нэг жич зөвшөөрөл байхгүй. Хэрэв халдагч эсвэл бүлэг халдагчид эдгээр дэмонуудыг холболт хийх хүсэлтээр цутгаж чадах юм бол серверийн эсрэг үйлчилгээг зогсоох халдлага явуулах боломжтой байж болох юм. Өөр нэг боломж нь эдгээр тохиолдлуудад тохируулгыг ашиглах явдал юм. тохируулгын нэгэн адил тохируулга нь холболтуудыг сохроор хааж гадаад бүрхүүлийн тушаалууд эсвэл скриптүүдийг ажиллуулахад ашиглагдаж болно. тохируулгаас ялгаатай тал нь нь холболт тогтоосон хүн уруу хариулт буцааж илгээдэггүй. Жишээ нь дараах тохиргооны мөр байжээ гэж бодъё: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny Энэ нь *.example.com домэйноос ирсэн бүх холболтын оролдлогуудаас татгалзахын зэрэгцээ хостын нэр, IP хаяг болон тэдний хандалт хийхийг оролдсон дэмонг /var/log/connections.log файл уруу бүртгэнэ. Дээр тайлбарласан орлуулах тэмдэгтүүдээс гадна, өөрөөр хэлбэл %a тэмдэгтээс гадна бусад цөөн хэдэн тэмдэгтүүд бас байдаг. Бүрэн жагсаалтыг &man.hosts.access.5; гарын авлагын хуудаснаас үзнэ үү. Орлуулагддаг тэмдэгтүүдийн тохиргоонууд Энэ хүртэл ALL жишээ бүх л жишээнүүдэд ашиглагдлаа. Ажиллагааг арай цаашлуулж өргөтгөх бусад тохируулгууд байдаг. Жишээ нь ALL нь дэмон, домэйн эсвэл IP хаягийн аль нэгтэй тааруулах зорилгоор ашиглагдаж болох юм. Өөр нэг орлуулагддаг тэмдэгт нь IP хаягаа өөрчлөн хуурсан байж болох дурын хостыг тааруулах PARANOID тохируулга юм. Өөрөөр хэлбэл paranoid буюу хэт зовнил нь өөрийн хостын нэрээс өөр IP хаягтай машинаас холболт хийгдэх бүр түүнд тохирох үйлдлийг тодорхойлоход ашиглагдаж болох юм. Дараах жишээ энэ хэлэлцүүлэгт арай илүү ойлголт өгч магадгүй юм: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny Энэ жишээн дээр sendmail уруу хийгдэж байгаа өөрийнхөө хостын нэрээс өөр IP хаягтай холболтын бүх хүсэлтүүдээс татгалзан хааж байна. Хэрэв клиент эсвэл сервер эвдэрхий DNS суулгацтай бол PARANOID-ийг ашиглах нь серверүүдийг ноцтойгоор зэрэмдэг болгож болох юм. Иймд администраторын зохион байгуулалт болон хуваарилалт хийхийг зөвлөж байна. Орлуулагддаг тэмдэгтүүдийн талаар болон тэдэнтэй холбоотой ажиллагааны талаар дэлгэрэнгүйг &man.hosts.access.5; гарын авлагын хуудаснаас үзээрэй. Тусгай тохиргооны аль ч мөрүүдийн өмнө дээрх нь ажиллана, эхний тохиргооны мөр hosts.allow файлд тайлбар болгон хаагдах шаардлагатай. Үүнийг энэ хэсгийн эхэнд тэмдэглэж хэлсэн байгаа. Марк Мюррей Хойно дурдсан хүний бичсэн дээр тулгуурлан хувь нэмэр болгон оруулсан Марк Дэйпоз Хувь нэмэр болгон оруулсан <application>KerberosIV</application> Kerberos нь хэрэглэгчид өөрсдийгөө нууцлаг серверийн үйлчилгээнүүдийн тусламжтайгаар таниулан нэвтрэх боломжийг олгодог сүлжээний нэмэлт систем/протокол юм. Алсын нэвтрэлт, алсын хуулбар, нууцлаг систем хоорондох файл хуулбарлалт болон бусад аюул ихтэй үйлдлүүд зэрэг үйлчилгээнүүд харьцангуй аюулгүй хийгдэж илүү хяналт хийж болохоор болсон. Дараах заавруудыг &os;-тэй цуг түгээгддэг Kerberos-ийг хэрхэн тохируулах гарын авлага болгон хэрэглэж болох юм. Гэхдээ та бүрэн тайлбарын талаар харгалзах гарын авлагын хуудаснуудад хандаж үзэх шаардлагатай. <application>KerberosIV</application> суулгах нь MIT KerberosIV суулгах нь Kerberos нь &os;-ийн нэмэлт бүрэлдэхүүн хэсэг юм. Энэ програм хангамжийг суулгах хамгийн амархан арга нь &os; эхэлж суулгах үед sysinstall-д krb4 эсвэл krb5 түгээлтийг сонгон суулгах явдал юм. Энэ нь Kerberos-ийн eBones (KerberosIV) эсвэл Heimdal (Kerberos5) шийдлүүдийг суулгах болно. Эдгээр нь АНУ/Канадаас гадна хөгжүүлэгдсэн учраас АНУ-ын криптограф код дээрх экспортын хязгаарлагдмал хяналтын үед бусад улсуудын системийн эзэмшигчдэд ашиглагдах боломжтой болсон юм. Иймээс эдгээр шийдлүүд нь орсон байдаг. Үүнээс гадна Kerberos-ийн MIT шийдэл портуудын цуглуулгын security/krb5 санд байдаг. Эхний мэдээллийн бааз үүсгэх Энэ нь Kerberos сервер дээр зөвхөн хийгддэг. Эхлээд хуучин Kerberos мэдээллийн баазууд байгаа эсэхийг шалгаарай. Та /etc/kerberosIV сан уруу орж зөвхөн дараах файлууд байгааг шалгаарай: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms Хэрэв аль нэг нэмэлт файлууд (principal.* эсвэл master_key зэрэг) байвал kdb_destroy тушаал ашиглаж хуучин Kerberos мэдээллийн баазыг устгах эсвэл хэрэв Kerberos ажиллахгүй байгаа бол ердөө л нэмэлт файлуудыг устгах хэрэгтэй. Та одоо өөрийн Kerberos хүрээг (realm) зааж өгөхдөө krb.conf болон krb.realms файлуудыг засварлах шаардлагатай. Энэ тохиолдолд хүрээ нь EXAMPLE.COM болох бөгөөд сервер нь grunt.example.com болох юм. Бид krb.conf файлыг засварлаж эсвэл үүсгэнэ: &prompt.root; cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov Энэ тохиолдолд бусад хүрээнүүд тэнд байх хэрэггүй. Тэдгээр нь энд машиныг хэрхэн олон хүрээнүүдийг мэдэхээр хийгдэх жишээ маягаар байгаа болно. Хялбараа бодоод та тэдгээрийг оруулахгүйг хүсэж болох юм. Эхний мөр нь систем ажиллах хүрээг нэрлэж байна. Бусад мөрүүд нь хүрээ/хост оруулгуудыг агуулна. Мөр дэх эхнийх нь хүрээ бөгөөд хоёр дахь нь түлхүүр түгээх төв болж байгаа хүрээн дэх хост юм. Хостын нэрийн дараах admin server нь хост бас удирдах мэдээллийн баазаар хангаж байна гэсэн үг юм. Эдгээр ухагдахуунуудын тайлбаруудын талаар Kerberos-ийн гарын авлагын хуудаснуудаас зөвлөгөө авна уу. Одоо бид grunt.example.com-г EXAMPLE.COM хүрээ уруу нэмэх ёстой бөгөөд бас EXAMPLE.COM хүрээний .example.com домэйн дэх бүх хостуудыг оруулан нэмж өгөх хэрэгтэй. krb.realms файл дараах байдлаар шинэчлэгдэх болно: &prompt.root; cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Дахин хэлэхэд бусад хүрээнүүд тэнд байх шаардлагагүй. Тэдгээр нь энд машиныг хэрхэн олон хүрээнүүдийг мэдэхээр хийгдэх жишээ маягаар байгаа болно. Хялбараа бодоод та тэдгээрийг оруулахгүйг хүсэж болох юм. Эхний мөр нь тусгай системийг нэрлэгдсэн хүрээ уруу оруулж байна. Бусад мөрүүд нэрлэгдсэн хүрээнд тухайн дэд домэйны системүүдийг хэрхэн анхдагчаар болгож байгааг харуулна. Одоо бид мэдээллийн сан үүсгэхэд бэлэн боллоо. Энэ нь зөвхөн Kerberos сервер (эсвэл Түлхүүр Түгээх Төв) дээр ажиллах ёстой. kdb_init тушаал ажиллуулж үүнийг хийнэ: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: Одоо бид локал машин дээрх серверүүд авч болгохоор болгохын тулд түлхүүрийг хадгалах хэрэгтэй. kstash тушаал ашиглаж үүнийг хийнэ: &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Энэ нь шифрлэгдсэн мастер нууц үгийг /etc/kerberosIV/master_key-д хадгална. Бүгдийг ажиллахаар болгох KerberosIV эхний эхлүүлэлт Kerberos-оор аюулгүй болгогдох систем бүрийн хувьд хоёр удирдагч мэдээллийн баазад нэмэгдэх шаардлагатай. Тэдгээрийн нэрс нь kpasswd болон rcmd байна. Эдгээр хоёр удирдагч нь систем бүрийн хувьд хувь системийн нэртэй тохиолдлуудын хамтаар хийгдэнэ. Эдгээр kpasswd болон rcmd дэмонууд нь бусад системүүдэд Kerberos нууц үгнүүдийг өөрчилж &man.rcp.1;, &man.rlogin.1; болон &man.rsh.1; зэрэг тушаалуудыг ажиллуулахыг зөвшөөрдөг. Одоо эдгээр оруулгуудыг нэмэцгээе: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Серверийн файлыг үүсгэх Одоо бид машин бүр дээр үйлчилгээнүүдийг тодорхойлдог бүх тохиолдлуудыг гаргаж авах хэрэгтэй. Энэ зорилгоор бид ext_srvtab тушаалыг ашиглана. Энэ нь файл үүсгэх бөгөөд түүнийг Kerberos-ийн клиент бүрийн /etc сан уруу аюулгүйн үүднээс хуулах эсвэл шилжүүлэх хэрэгтэй. Энэ файл нь сервер болон клиент бүр дээр байх хэрэгтэй бөгөөд Kerberos-ийн ажиллагаанд шийдвэрлэх зүйл болдог. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Одоо, энэ тушаал зөвхөн түр зуурын файл үүсгэдэг бөгөөд тэр файлын нэрийг бүх серверүүд авч чадахаар srvtab болгон нэрлэх шаардлагатай. &man.mv.1; тушаал ашиглаж эх систем дээрх байрлал уруу шилжүүл: &prompt.root; mv grunt-new-srvtab srvtab Хэрэв файл нь клиент системд зориулагдсан бөгөөд сүлжээ нь аюулгүй биш гэж бодогдвол client-new-srvtab файлыг шилжүүлж болох зөөвөрлөгч уруу хуулж физик аюулгүйн үүднээс тээвэрлэж болно. Үүнийг клиентийн /etc сан дотор srvtab болгон нэрлэж 600 горимд байгаа эсэхийг шалгаарай: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Мэдээллийн санг нутагшуулах Бид одоо зарим хэрэглэгчийг мэдээллийн баазад оруулах хэрэгтэй. Эхлээд jane хэрэглэгчид зориулсан оруулгыг үүсгэе. Үүнийг kdb_edit тушаал ашиглаж хийнэ: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Бүгдийг тест хийх Эхлээд бид Kerberos дэмонууд ажиллуулах шаардлагатай. Хэрэв та өөрийн /etc/rc.conf файлыг зөв засварласан бол дахин ачаалахад энэ нь автоматаар хийгдэх ёстойг санаарай. Энэ нь зөвхөн Kerberos сервер дээр шаардлагатай. kerberos-ийн клиентүүд хэрэгтэй зүйлээ автоматаар /etc/kerberosIV сангаас авах болно. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! Одоо бид kinit тушаал ашиглаж бидний дээр үүсгэсэн jane ID-д зориулсан тасалбарыг авахыг оролдож болно: &prompt.user; kinit jane MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: Токенууд бидэнд үнэхээр байгаа эсэхийг klist ашиглан үзэхийг оролдоорой: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Одоо kpasswd дэмон Kerberos-ийн мэдээллийн баазад нэвтрэлтийн зөвшөөрөл авч чадах эсэхийг шалгахын тулд нууц үгийг &man.passwd.1; ашиглан өөрчлөхийг оролдоорой: &prompt.user; passwd realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command> зөвшөөрлүүдийг нэмэх Kerberos нь root зөвшөөрлүүд хэрэгтэй хэрэглэгч бүрд өөрсдийнх нь тусдаа &man.su.1; нууц үгийг өгөхийг бидэнд зөвшөөрдөг. Одоо бид &man.su.1;-аар танигдан зөвшөөрөгдсөн ID-г root уруу нэмж болно. Үүнийг root-г удирдагчтай холбосон тохиолдолтой байснаар хянаж болно. kdb_edit ашиглан Kerberos-ийн мэдээллийн баазад jane.root оруулгыг бид үүсгэж болно: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Одоо үүнийг ажиллаж байгааг шалгаж токенуудыг авахыг оролдоорой: &prompt.root; kinit jane.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: Одоо бид хэрэглэгчийг root-ийн .klogin файлд нэмэх хэрэгтэй: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM Одоо &man.su.1; хийхийг оролдоод үз: &prompt.user; su Password: тэгээд ямар токенууд бидэнд байгааг хараарай: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM Бусад тушаалуудыг ашиглах Өмнөх жишээн дээр бид jane гэж нэрлэгдсэн удирдагчийг root тохиолдолтой үүсгэсэн. Энэ нь удирдагчтай адил нэртэй хэрэглэгч дээр үндэслэсэн бөгөөд энэ нь Kerberos-ийн анхдагч юм; root-ийн гэр сан дахь .klogin файлд шаардлагатай оруулгууд байвал <username>.root хэлбэрийн <principal>.<instance> нь тэр <username>-г root уруу &man.su.1; хийхийг зөвшөөрдөг: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM хэрэв хэрэглэгч үүнтэй адил хэлбэрийн өөрийн гэр сангийн мөрүүдтэй бол: &prompt.user; cat ~/.klogin jane@EXAMPLE.COM jack@EXAMPLE.COM Энэ нь өөрсдийгөө jane эсвэл jack гэж таниулсан (kinit-ийн тусламжтай, дээр дурдсаныг үз) EXAMPLE.COM хүрээний хэнд ч &man.rlogin.1;, &man.rsh.1; эсвэл &man.rcp.1; ашиглан энэ систем (grunt) дээрх jane-ий бүртгэл эсвэл файлуудад хандахыг зөвшөөрдөг. Жишээ нь jane одоо өөр систем уруу Kerberos ашиглан нэвтрэн орж байна: &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Эсвэл jack яг тэр машин дээрх jane бүртгэл уруу нэвтрэн орж байна (jane дээрхтэй адил .klogin-ийг тохируулсан бөгөөд Kerberos хариуцсан хүн удирдагч jack-ийг хоосон тохиолдолтой тохируулсан): &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Тиллмэн Хоожсон Хойно дурдсан хүний бичсэн дээр тулгуурлан хувь нэмэр болгон оруулсан Марк Мюррей Хувь нэмэр болгон оруулсан <application>Kerberos5</application> &os;-5.1-ээс хойшх &os;-ийн хувилбар бүр зөвхөн Kerberos5-д зориулсан дэмжлэгийг оруулсан байдаг. Kerberos5 нь орсон цорын ганц хувилбар болохоор түүний тохиргоо олон талаараа KerberosIV-д байдагтай адил байдаг. Дараах мэдээлэл &os;-5.0-с хойшх хувилбар дахь Kerberos5-тай хамаатай. KerberosIV багцыг ашиглахыг хүсэж байгаа хэрэглэгчид security/krb4 портыг суулгаж болно. Kerberos нь хэрэглэгчид өөрсдийгөө нууцлаг серверийн үйлчилгээнүүдийн тусламжтайгаар таниулан нэвтрэх боломжийг олгодог сүлжээний нэмэлт систем/протокол юм. Алсын нэвтрэлт, алсын хуулбар, нууцлаг систем хоорондох файл хуулбарлалт болон бусад аюул ихтэй үйлдлүүд зэрэг үйлчилгээнүүд харьцангуй аюулгүй хийгдэж илүү хяналт хийж болохоор болсон. Kerberos нь хэн бэ гэдгийг шалгах прокси систем юм. Энэ нь бас итгэгдсэн гуравдагч нэвтрэлт таних систем гэж тайлбарлагдаж болно. Kerberos нь зөвхөн нэг функцыг хангадаг — сүлжээн дээр хэрэглэгчдэд өөрсдийгөө аюулгүйгээр таниулах боломжийг хангаж өгдөг. Энэ нь шалгаж таних функцууд (хэрэглэгчдийн хийхийг зөвшөөрдөг) эсвэл аудит функцуудын (тэдгээр хэрэглэгчид юу хийснийг) үүргийг гүйцэтгэдэггүй. Клиент болон сервер өөрийгөө таниулж батлахаар Kerberos-г ашигласны дараа тэд бизнесээ бодож өөрсдийн бүх холболтуудаа шифрлэж нууцлал болон бүрэн бүтэн байдлаа хадгалан баталгаажуулж болно. Иймээс Kerberos-ийг нэвтрэлт танилт болон аудит үйлчилгээнүүдийг хангадаг бусад аюулгүй байдлын аргуудтай цуг ашиглахыг маш ихээр зөвлөдөг. Дараах заавруудыг &os;-д зориулан түгээгдсэн Kerberos-ийг хэрхэн тохируулах гарын авлага болгон ашиглаж болно. Гэхдээ та тохирох гарын авлагын хуудаснуудаас бүрэн тайлбарын талаар лавлах хэрэгтэй. Kerberos-ийн суулгацыг үзүүлэх зорилгоор төрөл бүрийн нэрийн талбарууд дараах байдлаар зохицуулагдана: DNS домэйн (бүс) нь example.org байна. Kerberos хүрээ нь EXAMPLE.ORG байна. Хэрэв та дотооддоо ажиллуулах бодолтой байсан ч гэсэн Kerberos-ийг суулгаж тохируулахдаа жинхэнэ домэйны нэрүүдийг ашиглана уу. Энэ нь DNS-ийн асуудлуудыг тойрон гарч бусад Kerberos хүрээнүүдтэй хийх хоорондын үйлдлийг баталгаажуулдаг. Түүх Kerberos5 түүх Kerberos-ийг MIT анх сүлжээний аюулгүй байдлын асуудлуудын шийдэл болгож хийсэн. Kerberos протокол нь хүчирхэг криптографыг ашигладаг бөгөөд клиент нь аюултай сүлжээний холболтоор өөрийгөө хэн бэ гэдгийг серверт (болон эсрэгээр) баталж чадах боломжийг олгодог. Kerberos нь сүлжээний танин шалгах протоколын нэрээс гадна програмыг (жишээ нь Kerberos телнет) шийдвэрлэж байгаа програмуудыг тайлбарласан тайлбар бас болдог. Протоколын одоогийн хувилбар нь 5 бөгөөд RFC 1510-д тайлбарласан байдаг. Өргөн хүрээний үйлдлийн системүүдийг хамарсан энэ протоколын хэд хэдэн чөлөөтэй шийдлүүд байдаг. Kerberos анх хөгжүүлэгдсэн Массачусетсийн Технологийн Институт (MIT) нь өөрийн Kerberos багцыг хөгжүүлсээр байна. Энэ багц нь US-д криптограф бүтээгдэхүүн болж нийтлэг хэрэглэгддэг бөгөөд энэ нь түүхээс авч үзэхэд US-ын экспортын дүрэм журмуудаас болсон юм. MIT Kerberos нь порт (security/krb5) хэлбэрээр байдаг. Heimdal Kerberos нь өөр шийдлийн 5-р хувилбар бөгөөд экспортын дүрэм журмуудыг тойрон гарах зорилгоор US-ээс гадна хамааралгүйгээр хөгжүүлэгдсэн ( бөгөөд ихэвчлэн арилжааны бус &unix; төрлүүдэд орсон байдаг) юм. Heimdal Kerberos түгээлт нь порт (security/heimdal) хэлбэрээр байдаг бөгөөд үүний хамгийн бага суулгац үндсэн &os; суулгацад орсон байдаг. Аль болох олон үзэгчдийг хамрахын тулд эдгээр зааврууд нь &os;-д орсон Heimdal түгээлтийг ашиглаж байна гэж тооцдог. Heimdal <acronym>KDC</acronym> суулгаж тохируулах Kerberos5 Түлхүүр Түгээх Төв Түлхүүр Түгээх Төв (KDC) нь Kerberos-ийн хангадаг төвлөрсөн нэвтрэлт таних үйлчилгээ юм — энэ нь Kerberos тасалбарууд өгдөг компьютер юм. KDC нь Kerberos хүрээний бусад бүх компьютеруудад итгэгдсэн гэж тооцогддог бөгөөд аюулгүй байдлын санаа зовнилыг дээшлүүлдэг. Kerberos серверийг ажиллуулж байхад маш цөөн тооцооллын эх үүсвэрийг шаарддаг боловч аюулгүй байдлын шалтгаанаас болоод зөвхөн KDC болон ажиллах тусдаа зориулагдсан машинтай байхыг зөвлөдгийг санаарай. KDC-г тохируулж эхлэхдээ таны /etc/rc.conf файлд KDC болж ажиллах зөв тохиргоо хийгдсэн эсэхийг шалгаарай (өөрийн системийн хувьд та замуудыг өөрчлөх хэрэгтэй байж болох юм): kerberos5_server_enable="YES" kadmind5_server_enable="YES" Дараа нь бид таны Kerberos тохиргооны файл /etc/krb5.conf-г тохируулна: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Энэ /etc/krb5.conf файл нь таны KDC нь бүрэн баталгаажсан хостын нэр kerberos.example.org-тэй байна гэж үзэж байгааг санаарай. Хэрэв таны KDC өөр хостын нэртэй бол та өөрийн бүсийн файлдаа CNAME (alias)-ийг нэмэх хэрэгтэй. Зөв тохируулсан BIND DNS сервер бүхий том сүлжээнүүдэд өмнөх жишээ нь: [libdefaults] default_realm = EXAMPLE.ORG болж дараах мөрүүдийг example.org бүсийн файлд нэмж цэгцэлж болно: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG Kerberos үйлчилгээнүүдийг хэрэглэгчдэд хүртээмжтэй болгохын тулд та эсвэл бүрэн тохируулсан /etc/krb5.conf файлтай эсвэл хамгийн багаар тохируулсан /etc/krb5.conf файл болон зөв тохируулсан DNS сервертэй байх ёстой. Дараа нь бид Kerberos мэдээллийн бааз үүсгэнэ. Энэ мэдээллийн бааз нь мастер нууц үгээр шифрлэсэн бүх удирдагчдын түлхүүрүүдийг агуулдаг. Та энэ нууц үгийг тогтоох шаардлагагүй, энэ нь файлд (/var/heimdal/m-key) хадгалагдах болно. Мастер түлхүүр үүсгэхийн тулд kstash тушаалыг ажиллуулж нууц үгээ оруулаарай. Мастер түлхүүр үүсгэгдсэний дараа та мэдээллийн баазыг kadmin програмыг -l тохируулгатай (локал гэсэн утгатай) ашиглан эхлүүлж болно. Энэ тохируулга нь kadmin-д мэдээллийн баазын файлыг kadmind сүлжээний үйлчилгээгээр дамжилгүйгээр шууд өөрчлөхийг заадаг. Энэ нь мэдээллийн бааз үүсэхээс өмнө түүн уруу хандахыг оролдох асуудлыг (яг л өндөг, тахианы аль нь түрүүлж гарсан гэж маргадаг тэр асуудлын адил) зохицуулдаг. kadmin хүлээх мөртэй болсныхоо дараа та өөрийн хүрээнүүдийн эхний мэдээллийн санг init тушаал ашиглан үүсгээрэй. Эцэст нь kadmin-ы горимд байхдаа өөрийн эхний удирдагчийг add тушаал ашиглан үүсгээрэй. Одоохондоо удирдагчийн хувьд анхдагч тохируулгуудыг сонгоорой, та тэдгээрийг сүүлд нь modify тушаал ашиглан өөрчилж чадна. Та аль ч тушаал хүлээх мөрөнд ? тушаал ашиглаж байгаа боломжит тохируулгуудыг харж болохыг санаарай. Мэдээллийн сан үүсгэлтийн жишээ сесс доор байна: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Одоо KDC үйлчилгээнүүдийг эхлүүлэх цаг болжээ. Үйлчилгээнүүдийг эхлүүлэхдээ /etc/rc.d/kerberos start болон /etc/rc.d/kadmind start тушаалуудыг ажиллуулна. Энэ үед танд ямар ч kerberos хийгдсэн дэмон байхгүйг санаарай, гэхдээ та KDC-ийн өөрийнх нь тушаалын мөрөөс үүсгэсэн удирдагчид (хэрэглэгч) зориулсан тасалбарыг авч жагсаан KDC-г ажиллаж байгаа гэдгийг та баталж чадаж байх ёстой: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Та дууссаныхаа дараа тасалбарыг буцааж болно: &prompt.user; k5destroy Серверийг <application>Kerberos</application> хийн Heimdal үйлчилгээнүүдтэй идэвхжүүлэх Kerberos5 үйлчилгээнүүдийг идэвхжүүлэх Эхлээд бидэнд Kerberos-ийн тохиргооны файл /etc/krb5.conf-ийн хуулбар хэрэг болно. Ингэхийн тулд KDC-ээс түүнийг аюулгүй аргаар (&man.scp.1; зэрэг сүлжээний хэрэгслүүд эсвэл физикээр уян диск ашиглан) клиент компьютер уруу ердөө л хуулах хэрэгтэй. Дараа нь танд /etc/krb5.keytab файл хэрэгтэй. Энэ нь Kerberos хийгдсэн дэмонууд бүхий сервер болон ажлын станц хоёрын гол ялгаа юм — сервер нь keytab файлтай байх шаардлагатай. Энэ файл нь өөрийг нь зөвшөөрдөг серверийн хост түлхүүр болон өөрсдийнхөө нэрийг (identity) шалгах KDC-г агуулдаг. Хэрэв түлхүүр нь нийтэд мэдэгдвэл серверийн аюулгүй байдал эвдэрч болох учир энэ нь сервер уруу аюулгүйн үүднээс дамжуулагдах ёстой. Энэ нь шууд утгаараа FTP зэрэг цэвэр текст сувгаар дамжуулах нь маш буруу гэсэн үг юм. Ихэвчлэн сервер уруу keytab файлыг kadmin тушаал ашиглан дамжуулдаг. Энэ нь тохиромжтой байдаг бөгөөд учир нь та бас хостын удирдагчийг (krb5.keytab файлын KDC төгсгөл) kadmin тушаал ашиглан үүсгэх хэрэгтэй болдог. Та тасалбарыг аль хэдийн авсан байх ёстой бөгөөд энэ тасалбар нь kadmind.acl файлын kadmin интерфэйсийг ашиглаж болохоор зөвшөөрөгдсөн байх ёстойг санаарай. Heimdal-ийн мэдээллийн хуудаснуудын (info heimdal) Алсын удирдлага гэсэн гарчигтай хэсгээс хандалт хянах жагсаалтуудыг дизайн хийх талаар дэлгэрэнгүйг үзнэ үү. Хэрэв та алсын kadmin хандалтыг идэвхжүүлэхийг хүсэхгүй байгаа бол та KDC уруу ердөө л аюулгүйгээр холбогдож (локал консолоор, &man.ssh.1; эсвэл Kerberos &man.telnet.1;) удирдлагыг локалаар өөр дээрээсээ kadmin -l тушаал ашиглан хийж болно. /etc/krb5.conf файлыг суулгасны дараа та Kerberos серверээс kadmin тушаалыг ашиглаж болно. add --random-key тушаал нь серверийн хост удирдагчийг нэмэх боломжийг танд олгох бөгөөд ext тушаал нь серверийн хост удирдагчийг өөрийн keytab уруу задлах боломжийг танд олгоно. Жишээ нь: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit ext тушаал нь (extract гэдгийг богиноор илэрхийлнэ) задалсан түлхүүрийг анхдагчаар /etc/krb5.keytab файлд хадгалдаг. Хэрэв таны хувьд KDC дээр kadmind ажиллахгүй байгаа бөгөөд (магадгүй аюулгүй байдлын шалтгаануудаас болоод) тэгээд kadmin уруу алсаас хандах боломжгүй бол та хост удирдагчийг (host/myserver.EXAMPLE.ORG) шууд KDC дээр нэмж дараа нь доор дурдсантай адилаар түүнийг түр зуурын файл уруу (KDC дээрх /etc/krb5.keytab файлыг дарж бичихээс сэргийлж) задалж болно: &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Та дараа нь keytab-ийг аюулгүйгээр (жишээ нь scp эсвэл уян диск ашиглан) сервер компьютер уруу хуулж болно. KDC дээрх keytab-ийг дарж бичихээс сэргийлж keytab нэрийг анхдагч бишээр зааж өгсөн эсэхээ шалгаарай. Энэ мөчид хүрэх үед таны сервер KDC-тэй (krb5.conf файлтай учраас) холбогдож чадах бөгөөд (krb5.keytab файлтай учраас) өөрийгөө таниулан баталж чадна. Одоо та зарим нэг Kerberos үйлчилгээнүүдийг идэвхжүүлэхэд бэлэн болжээ. Энэ жишээн дээр бид telnet үйлчилгээг /etc/inetd.conf файлд доор дурдсантай төстэй мөрийг оруулан идэвхжүүлж дараа нь &man.inetd.8; үйлчилгээг /etc/rc.d/inetd restart тушаалын тусламжтай дахин ачаалах болно: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user Хамгийн чухал нь -a төрөл (нэвтрэлт танихад) хэрэглэгчид тохируулагдсан. Илүү дэлгэрэнгүйг &man.telnetd.8; гарын авлагын хуудаснаас лавлана уу. Клиентийг <application>Kerberos</application> хийн Heimdal үйлчилгээтэйгээр идэвхжүүлэх Kerberos5 клиентүүдийг тохируулах Клиент компьютерийг тохируулах нь маш амархан. Kerberos тохиргоо хийгдсэний дараа танд зөвхөн /etc/krb5.conf-д байрлах Kerberos тохиргооны файл хэрэгтэй. Үүнийг ердөө л аюулгүйгээр клиент компьютер уруу KDC-ээс хуулна. Клиентээсээ kinit, klist, болон kdestroy тушаалуудыг үүсгэсэн удирдагчийнхаа хувьд тасалбар олж авах, үзүүлэх, болон дараа нь устгахад ашиглахыг оролдон клиент компьютераа тест хийгээрэй. Та Kerberos програмуудыг ашиглан Kerberos хийгдсэн серверүүд уруу холбогдож чадах ёстой бөгөөд хэрэв ингэж ажиллаж болохгүй байгаа бөгөөд тасалбар олж авах нь асуудалтай байгаа бол энэ нь клиент эсвэл KDC-тэй холбоотой биш сервертэй холбоотой асуудал юм. telnet зэрэг програмыг тест хийж байх үед таны нууц үг цэвэр текстээр бишээр илгээгдэж байгааг шалгахын тулд пакет шиншлэгч (&man.tcpdump.1; зэрэг) ашиглаад үзээрэй. telnet-ийг бүх өгөгдлийн урсгалыг шифрлэдэг (ssh-тэй адил) -x тохируулгатай ашиглахыг оролдоорой. Төрөл бүрийн гол биш Kerberos клиент програмууд нь бас анхдагчаар суудаг. Энэ нь үндсэн Heimdal суулгацын хамгийн бага мөн чанар юм: telnet нь цорын ганц Kerberos хийгдсэн үйлчилгээ юм. Heimdal порт нь зарим нэг дутуу програмуудыг нэмдэг: ftp, rsh, rcp, rlogin болон бусад цөөн хэдэн нийтлэг биш програмуудын Kerberos хийгдсэн хувилбаруудыг нэмдэг. MIT порт нь бас Kerberos клиент програмуудын бүрэн цуглуулгыг агуулдаг. Хэрэглэгчийн тохиргооны файлууд: <filename>.k5login</filename> болон <filename>.k5users</filename> .k5login .k5users Хүрээн дэх хэрэглэгчийн хувьд ихэнхдээ өөрсдийнх нь Kerberos удирдагчийг (tillman@EXAMPLE.ORG зэрэг) локал хэрэглэгчийн бүртгэлд (tillman зэрэг локал бүртгэл) харгалзуулж өгсөн байдаг. telnet зэрэг клиент програмууд ихэвчлэн хэрэглэгчийн нэр эсвэл удирдагчийг шаарддаггүй. Гэхдээ хааяа нэг та харгалзах Kerberos удирдагчгүй хэн нэгэнд зориулж локал хэрэглэгчийн бүртгэлд хандах хандалтыг өгөхийг хүсэж болох юм. Жишээ нь tillman@EXAMPLE.ORG магадгүй локал хэрэглэгчийн бүртгэл webdevelopers-д хандах хандалт хэрэгтэй байж болох юм. Бусад удирдагчид бас энэ локал бүртгэлд хандах хэрэгтэй байж болох юм. .k5login болон .k5users файлууд нь хэрэглэгчдийн гэрийн сангуудад байрладаг бөгөөд .hosts болон .rhosts файлуудын хүчирхэг хослолын нэгэн адилаар энэ асуудлыг шийдэн ашиглагдаж болох юм. Жишээ нь хэрэв .k5login нь дараах агуулгатайгаар: tillman@example.org jdoe@example.org локал хэрэглэгч webdevelopers-ийн гэр санд байрлаж байвал энд жагсаагдсан хоёр удирдагч хоёулаа хуваалцсан нууц үгийн шаардлагагүйгээр тэр бүртгэл уруу хандах хандалттай болох юм. Эдгээр тушаалуудын гарын авлагын хуудаснуудыг уншихыг зөвлөж байна. ksu гарын авлагын хуудас .k5users файлын тухай тайлбарладгийг тэмдэглэх нь зүйтэй юм. <application>Kerberos</application>-той холбоотой арга, зальнууд болон алдааг олж засварлах Kerberos5 алдааг олж засварлах Heimdal эсвэл MIT Kerberos портууд ашиглах үед таны PATH орчны хувьсагч клиентийн програмуудын Kerberos хувилбаруудыг системийн хувилбаруудаас өмнө жагсаасан байхыг шаарддаг. Таны хүрээний бүх компьютерууд цагийн тохиргоонуудаа адилаар тохируулсан уу? Хэрэв үгүй бол нэвтрэлт танилт амжилтгүй болж болох юм. нь NTP ашиглан цагийг хамгийн сүүлийн хэлбэрт аваачиж адил болгож тохируулах талаар тайлбарладаг. MIT болон Heimdal нь хоорондоо сайн ажилладаг. kadmin-аас бусад талаараа сайн ажилладаг, учир нь энэ програмын протокол стандартчилагдаагүй. Та хэрэв өөрийн хостын нэрийг өөрчилбөл бас өөрийн host/ удирдагчийг өөрчилж өөрийн keytab-ийг шинэчлэх хэрэгтэй. Энэ нь бас Апачигийн www/mod_auth_kerb-д хэрэглэгддэг www/ удирдагч зэрэг тусгай keytab оруулгуудад хамаатай юм. Таны хүрээний бүх хостууд DNS-д (эсвэл хамгийн багадаа /etc/hosts-ийн хувьд) танигдаж (урагш болон эсрэгээр танигдаж) байх ёстой. CNAME-үүд ажиллах боловч A болон PTR бичлэгүүд зөв бөгөөд байрандаа байж байх ёстой. Алдааны мэдэгдэл нь тийм ч ойлгогдохоор байдаггүй, жишээ нь: Kerberos5 refuses authentication because Read req failed: Key table entry not found буюу орчуулбал Унших Req амжилтгүй болсон болохоор Kerberos5 нь нэвтрэлт танилтаас татгалзаж байна. Таны KDC-ийн хувьд магадгүй клиент маягаар харьцаж байгаа зарим үйлдлийн системүүд setuid root болохын тулд ksu тушаалд зөвшөөрлүүдийг тохируулдаггүй. Энэ нь ksu ажиллахгүй гэсэн үг бөгөөд аюулгүй байдлын хувьд сайн боловч залхаамаар байдаг. Энэ нь KDC-ийн алдаа биш юм. MIT Kerberos-той байхад хэрэв та анхдагч 10 цагаас арай урт амьдрах хугацаа бүхий тасалбартай удирдагчийг зөвшөөрөхийг хүсвэл kadmin дээр modify_principal тушаал ашиглан өөрчлөхийг хүссэн удирдагч болон krbtgt удирдагчийн maxlife-ийг өөрчлөх шаардлагатай. Дараа нь удирдагч -l тохируулгыг kinit-тай ашиглаж илүү урт амьдрах хугацаатай тасалбарыг авах хүсэлт илгээж болох юм. Хэрэв та өөрийн KDC дээр алдааг олж засварлахын тулд пакет шиншлэгч ажиллуулж дараа нь ажлын станцаасаа kinit-ийг ажиллуулахад kinit-ийг ажилласан даруй таны TGT илгээгдэхийг — таныг бүр нууц үгээ бичихээс өмнө та харах болно! Үүний тайлбар нь Kerberos сервер чөлөөтэйгээр TGT-ийг (Ticket Granting Ticket буюу Тасалбар Баталгаажуулах Тасалбар) ямар ч танигдаагүй хүсэлтэд дамжуулдаг; гэхдээ TGT бүр хэрэглэгчийн нууц үгээс гарсан түлхүүр болон шифрлэгдсэн байдаг. Тийм болохоор хэрэглэгч өөрсдийн нууц үгийг бичихэд тэр нь KDC уруу илгээгддэггүй бөгөөд харин kinit-ийн аль хэдийн олж авсан TGT-г буцааж шифрлэхэд (decrypt) ашиглагддаг. Хэрэв буцааж шифрлэх процесс хүчинтэй хугацаа бүхий хүчинтэй тасалбарыг гаргаж авбал хэрэглэгч хүчинтэй Kerberos итгэмжлэлүүдтэй байна. Эдгээр итгэмжлэлүүд нь ирээдүйд Kerberos сервертэй аюулгүй холболтууд хийхэд зориулагдсан сессийн түлхүүр болон бас Kerberos серверийн өөрийнх нь түлхүүрээр шифрлэгдсэн тасалбар-баталгаажуулах тасалбарыг агуулдаг. Шифрлэлтийн хоёр дахь давхарга нь хэрэглэгчид мэдэгддэггүй, гэхдээ энэ нь TGT бүрийн жинхэнийг шалгахыг Kerberos серверт зөвшөөрч байгаа тэр зүйл юм. Хэрэв та урт амьдрах хугацаатай (жишээ нь долоо хоног) тасалбар ашиглахыг хүсэж байгаа бөгөөд та тасалбар хадгалагдаж байгаа машин уруу OpenSSH ашиглан холбогдож байгаа бол Kerberos тохируулга no гэж sshd_config тохиргооны файлд байгаа эсэхийг шалгаарай, тэгэхгүй бол таны тасалбарууд таныг гарах үед устгагдах болно. Хостын удирдагчид илүү урт амьдрах хугацаатай тасалбартай бас байж болно гэдгийг санаарай. Хэрэв таны хэрэглэгчийн удирдагч долоо хоног амьдрах хугацаатай бөгөөд гэхдээ таны холбогдож байгаа хост 9 цаг амьдрах хугацаатай бол та кэшдээ хугацаа нь дууссан хостын удирдагчтай болж тасалбарын кэш хүссэнээр ажиллахгүй болох болно. Тусгайлсан муу нууц үгүүдийг ашиглуулахгүйн тулд (kadmind тушаалын гарын авлагын хуудас үүнийг товчхон тайлбарладаг) krb5.dict файлыг тохируулахдаа нууц үгийн бодлого тавигдсан удирдагчдад энэ нь зөвхөн хамаатайг санах хэрэгтэй. krb5.dict файлуудын хэлбэр хялбар байдаг: нэг мөрт нэг үг (string) байна. /usr/share/dict/words симболын холбоос үүсгэх нь ашигтай байж болох юм. <acronym>MIT</acronym> портоос ялгаатай талууд MIT болон Heimdal суулгацуудын гол ялгаа нь өөр (гэхдээ орлуулж болох) тушаалууд болон өөр протоколууд ашигладаг kadmin програмтай холбоотой юм. Хэрэв таны KDC нь MIT бол та Heimdal kadmin програмыг ашиглаж өөрийн KDC-г алсаас (эсвэл эсрэг чиглэлд энэ зорилгоор) удирдаж чадахгүй болдог учир энэ нь их хамаатай юм. Клиент програмууд нь бас шал өөр өөр тушаалын мөрийн тохируулгууд авч адил үүргийг гүйцэтгэж болох юм. MIT Kerberos вэб сайт () дээрх заавруудыг дагахыг зөвлөж байна. Замын асуудлуудаас болгоомжлоорой: MIT порт нь анхдагчаар /usr/local/ уруу суудаг бөгөөд хэрэв таны PATH орчны хувьсагч системийн сангуудыг эхлээд жагсаадаг бол жирийн системийн програмууд MIT-ийн оронд ажиллаж болохыг санаарай. telnetd болон klogind-ээр нэвтрэх нэвтрэлтүүд нэг л хачин байдаг тэр шалтгааныг ойлгохыг хүсвэл &os;-ийн хангадаг MIT security/krb5 портын суулгасан /usr/local/share/doc/krb5/README.FreeBSD файлыг унших хэрэгтэй. Хамгийн чухал нь кэш файл дахь буруу зөвшөөрлүүдийг зөв болгох нь дамжуулагдсан итгэмжлүүдийн эзэмшилтийг зөвөөр солих login.krb5 хоёртын файлыг нэвтрэлт танилтад ашиглахыг шаарддаг. rc.conf файл дараах тохиргоог агуулж засварлагдсан байх бас шаардлагатай: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" MIT керберосд зориулсан програмууд /usr/local санд хоёртын файлуудыг суулгадаг болохоор ингэж хийгддэг. <application>Kerberos</application> дахь хязгааруудыг багасгах Kerberos5 хязгаарууд болон дутагдлууд <application>Kerberos</application> нь бүгдийг эсвэл юуг ч биш гэсэн арга юм Сүлжээнд идэвхжүүлэгдсэн үйлчилгээ бүр Kerberos-тэй ажиллахаар засварлагдсан (эсвэл сүлжээний халдлагуудын эсрэг аюулгүй байдлыг хангасан) байх шаардлагатай, тэгэхгүй бол хэрэглэгчдийн итгэмжлэлүүд хулгайлагдаж дахин ашиглагдаж болох юм. Үүний нэг жишээ нь бүх алсын бүрхүүлүүдийг (жишээ нь rsh болон telnet) Kerberos хийн идэвхжүүлсэн мөртлөө нууц үгүүдийг цэвэр текстээр илгээдэг POP3 захидлын серверийг тэгж хувиргахгүй байх явдал юм. <application>Kerberos</application> нь ганц хэрэглэгчийн ажлын станцуудад зориулагдсан Олон хэрэглэгчийн орчинд Kerberos нь тийм ч аюулгүй биш юм. Энэ нь тасалбаруудыг бүх хэрэглэгчийн хувьд уншигдаж болох /tmp санд хадгалдаг учраас тэр юм. Хэрэв хэрэглэгч компьютераа хэд хэдэн бусад хүмүүстэй зэрэг харилцан хуваалцаж байвал (өөрөө хэлбэл олон-хэрэглэгч) хэрэглэгчийн тасалбаруудыг өөр хэрэглэгч хулгайлах (хуулан авах) боломжтой юм. Үүнийг -c файлын нэрийн тушаалын мөрийн тохируулгатай эсвэл (илүү зохимжтой) KRB5CCNAME орчны хувьсагчтайгаар даван гарч болох юм, гэхдээ ингэх нь их ховор байдаг. Зарчмын хувьд тасалбарыг хэрэглэгчдийн гэр санд хадгалж хялбар файлын зөвшөөрлүүдийг ашиглах нь энэ асуудлыг багасгадаг. KDC нь бүтэлгүйтлийн ганц цэг Дизайнаараа бол KDC нь мастер нууц үгийн мэдээллийн баазаас тогтох бөгөөд түүний нэгэн адил аюулгүй байх ёстой. KDC нь үүн дээр өөр ямар ч үйлчилгээнүүд ажиллуулсан байх ёсгүй бөгөөд физикээр аюулгүй байдлыг нь хангасан байх шаардлагатай. Kerberos нь ижил түлхүүрээр (мастер түлхүүр) шифрлэгдсэн бүх нууц үгүүдийг хадгалдаг бөгөөд тэр ижил түлхүүр нь эргээд KDC дээр файл маягаар хадгалагддаг учраас аюул өндөртэй байдаг. Тэмдэглэн хэлэхэд булаан эзлэгдсэн мастер түлхүүр нь хэн нэг нь айхаар тийм ч муу биш юм. Түлхүүр үг нь зөвхөн Kerberos мэдээллийн баазыг шифрлэхэд болон санамсаргүй тоо үүсгэгчийн үр болон хэрэглэгддэг. Таны KDC уруу хандахад аюулгүй л байж байвал халдагч мастер түлхүүрээр их юм хийж чадахгүй. Мөн нэмж хэлэхэд хэрэв KDC нь боломжгүй байвал (магадгүй үйлчилгээ зогсоох халдлага эсвэл сүлжээний асуудлуудаас болоод) сүлжээний үйлчилгээнүүд нь нэвтрэлт танилтыг хийж болохгүй болохоор хэрэглэгдэх боломжгүй болох бөгөөд нэг ёсны үйлчилгээ зогсоох халдлагын рецепт болох юм. Үүнийг олон KDC-тэй (нэг мастер болон нэг буюу хэд хэдэн боолууд) болон хоёрдогч эсвэл нэмэлт, эцсийн нэвтрэлт таних (PAM нь энэнд маш сайн) болгоомжтой шийдлийн тусламжтайгаар даван гарч болох юм. <application>Kerberos</application>-ийн дутагдлууд Kerberos нь хэрэглэгчид, хостууд болон үйлчилгээнүүдэд өөр хоорондоо бие биенээ таниулах боломжийг олгодог. Гэхдээ энэ нь KDC-г хэрэглэгчид, хостууд эсвэл үйлчилгээнүүдэд таниулах аргагүй юм. Энэ нь троян хийгдсэн kinit (жишээ нь) тушаал бүх хэрэглэгчийн нэрс болон нууц үгүүдийг бүртгэн бичиж авч болно гэсэн үг юм. security/tripwire ч юм уу эсвэл өөр бусад файлын системийн бүрэн бүтэн байдлыг шалгах хэрэгслүүд үүнийг арилгаж чадна. Эх сурвалжууд болон нэмэлт мэдээллүүд Kerberos5 гадаад эх сурвалжууд Kerberos-ийн FAQ Танин шалгах системийг дизайн хийх нь: Дөрвөн үзэгдэл дэх харилцан яриа (диалог) RFC 1510, Kerberos Сүлжээний Танин Шалгах Үйлчилгээ (V5) MIT Kerberos-ийн гэр хуудас Heimdal Kerberos-ийн гэр хуудас Том Рөүдс Бичсэн OpenSSL аюулгүй байдал OpenSSL Олон хэрэглэгчдийн хайдаг нэг боломж нь &os;-д байдаг OpenSSL багаж юм. OpenSSL нь ердийн холбооны давхарга дээр шифрлэлт дамжуулах давхаргыг хангаж өгдөг; ингэснээр түүнийг сүлжээний програмууд болон үйлчилгээнүүдтэй холбож өгөх боломжийг олгодог. OpenSSL-ийн зарим нэг хэрэглээнд захидлын клиентүүдийн шифрлэсэн нэвтрэлт, кредит картаар хийх төлбөрүүд гэх мэт вэб дээр тулгуурласан шилжүүлгүүд зэрэг олныг дурдаж болно. www/apache13-ssl болон mail/sylpheed-claws зэрэг олон портууд нь OpenSSL-тэй бүтээх эмхэтгэлийн дэмжлэгийг санал болгодог. Ихэнх тохиолдолд Портуудын Цуглуулга нь make хувьсагч WITH_OPENSSL_BASE-ийг yes гэж заагаагүй тохиолдолд security/openssl портыг бүтээхийг оролддог. &os;-д орсон OpenSSL-ийн хувилбар нь Secure Sockets Layer v2/v3 (SSLv2/SSLv3) буюу Аюулгүй Сокетуудын Давхаргын v2/v3 хувилбарууд, Transport Layer Security v1 (TLSv1) буюу Тээврийн Давхаргын Аюулгүй байдлын v1 хувилбарын сүлжээний аюулгүй байдлын протоколуудыг дэмждэг бөгөөд ерөнхий криптограф сан болон ашиглагдаж болох юм. OpenSSL нь IDEA алгоритмийг дэмждэг боловч Нэгдсэн Улсын патентуудаас болоод анхдагчаар хаалттай байдаг. Үүнийг ашиглахын тулд лицензийг шалгасан байх ёстой бөгөөд хэрэв хязгаарлалтуудыг хүлээн авах боломжтой бол MAKE_IDEA хувьсагчийг make.conf файлд заагж өгөх ёстой байдаг. OpenSSL-ийн хамгийн түгээмэл хэрэглээний нэг бол програм хангамжуудад зориулан ашиглах сертификатуудыг бэлдэх явдал юм. Эдгээр сертификатууд нь компани болон хувь хүмүүсийн итгэмжлэлүүдийг хүчинтэй бөгөөд луйврын биш гэдгийг баталгаажуулдаг. Хэрэв асуудалтай сертификат хэд хэдэн Certificate Authorities эсвэл CA-ууд буюу Сертификатын Эрх мэдэлтнүүдээр шалгагдаагүй бол ихэвчлэн анхааруулга үзүүлдэг. Сертификатын Эрх мэдэлтэн нь VeriSign зэрэг компани байдаг бөгөөд компаниуд эсвэл хувь хүмүүсийн итгэмжлэлүүдийг хүчин төгөлдөр болгохын тулд сертификатуудыг баталгаажуулж өгдөг. Энэ процесс нь өртөгтэй бөгөөд сертификатууд ашиглахад заавал ч үгүй шаардлага болдоггүй; гэхдээ энэ нь паранойд буюу хэт зовнисон хэрэглэгчдийн заримын санааг тайвшруулж болох юм. Сертификатуудыг үүсгэх нь OpenSSL сертификат үүсгэлт Сертификат үүсгэхийн тулд дараах тушаал байдаг: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name Common Name хүлээх мөрийн дараах хариу домэйны нэрийг харуулж байгааг анзаараарай. Энэ мөр нь шалгалт хийх зорилгоор серверийн нэрийг оруулахыг шаарддаг; домэйн нэрээс бусдыг байрлуулах нь ашиггүй сертификат үүсэхэд хүргэдэг. Бусал тохируулгууд, жишээ нь дуусах хугацаа, өөр шифрлэх алгоритмууд гэх мэт тохируулгууд байдаг. Бүрэн гүйцэд жагсаалтыг &man.openssl.1; гарын авлагын хуудсыг үзэн авч болно. Дээрх тушаалын ажилласан санд хоёр файл одоо байж байх ёстой. Сертификатын хүсэлт req.pem нь таны оруулсан итгэмжлэлүүдийг хүчин төгөлдөр болгож хүсэлтийг баталгаажуулан сертификатыг танд буцаах сертификатын эрх мэдэлтэн уруу илгээгдэж болно. Үүсгэгдсэн хоёр дахь файл нь cert.pem гэж нэрлэгдэн сертификатын хувийн түлхүүр болох бөгөөд ямар ч байсан гэсэн хамгаалагдсан байх ёстой; хэрэв энэ нь бусдын гарт орох юм бол таны (эсвэл таны серверийн) дүрд тоглон ашиглагдаж болох юм. CA-с гарын үсэг шаарддаггүй тохиолдолд өөрөө зурсан сертификатыг үүсгэж болно. Эхлээд RSA түрхүүр үүсгэх хэрэгтэй: &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 Дараа нь CA түлхүүр үүсгэ: &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key Сертификат үүсгэхийн тулд энэ түлхүүрийг ашигла : &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt Санд хоёр шинэ файл үүсэх ёстой: сертификатын эрх мэдэлтний гарын үсгийн файл myca.key болон сертификат өөрөө new.crt байна. Эдгээрийг зөвхөн root унших эрхтэй /etc санд байрлуулах шаардлагатай. Үүнд 0700 зөвшөөрөл байж болох бөгөөд түүнийг chmod хэрэгсэл ашиглан тохируулж болно. Сертификатуудыг ашиглах нь, жишээ Тэгэхээр эдгээр файлууд нь юу хийж чадах вэ? Сайн хэрэглээ болох нэг жишээ нь Sendmail MTA уруу хийгдэх холболтуудыг шифрлэх байж болно. Энэ нь локал MTA ашиглан захидал илгээх хэрэглэгчдийн цэвэр текст нэвтрэлтийн хэрэглээг болиулах юм. Зарим MUA-ууд нь хэрэв хэрэглэгчид дотроо сертификат суулгаагүй бол тэдэнд алдааг харуулдаг болохоор энэ нь ертөнц дээрх хамгийн шилдэг хэрэглээ биш юм. Сертификат суулгах тухай илүү мэдээллийг програм хангамжтай цуг ирсэн баримтаас үзэх хэрэгтэй. Дотоод .mc файл дотор дараах мөрүүдийг байрлуулах хэрэгтэй: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl Дээрх /etc/certs/ нь сертификат болон түлхүүр файлуудыг дотооддоо хадгалах сан юм. Сүүлийн хэдэн шаардлагууд нь дотоод .cf файлын дахин бүтээлт юм. Үүнийг /etc/mail сан дотроос make install тушаал бичин хийж болно. Ингэсний дараа make restart тушаалыг ажиллуулаарай, энэ нь Sendmail дэмонг эхлүүлэх ёстой. Хэрэв бүгд зүгээр болж өнгөрвөл /var/log/maillog файлд ямар ч алдаа бичигдэхгүй бөгөөд Sendmail процессийн жагсаалтад харуулагдана. Хялбар тест хийхийн тулд &man.telnet.1; хэрэгсэл ашиглан захидлын серверт холбогдох хэрэгтэй: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. Хэрэв STARTTLS мөр гарч ирвэл бүгд зөв ажиллаж байна. Ник Клэйтон
nik@FreeBSD.org
 Бичсэн IPsec IPsec дээгүүр VPN хийх FreeBSD гарц машинуудыг ашиглан Интернэтээр тусгаарлагдсан хоёр сүлжээний хооронд VPN үүсгэх. Хитэн М. Пандиа
hmp@FreeBSD.org
 Бичсэн IPsec-ийг ойлгох нь Энэ хэсэг IPsec-ийг тохируулах процессийг тайлбарлаж FreeBSD болон µsoft.windows; 2000/XP машинуудаас тогтох орчинд түүнийг ашиглан тэдгээрийг өөр хоорондоо аюулгүйгээр холбогдох нөхцөлийг бүрдүүлэх талаар зааварлах болно. IPsec-ийг тохируулахын тулд та өөрчлөн тохируулсан цөм бүтээх ухагдахууныг мэдсэн байх шаардлагатай (-г үзнэ үү). IPsec нь Интернэт Протокол (IP) давхаргын дээр суудаг протокол юм. Энэ нь хоёр буюу хэд хэдэн хостуудыг аюулгүй байдлаар (нэрээс нь харах юм бол) холбох боломжийг олгодог. FreeBSD IPsec сүлжээний стек нь IPv4 болон IPv6 протоколуудыг хоёуланг дэмждэг KAME шийдэл дээр үндэслэсэн. FreeBSD нь OpenBSD-ээс авсан Fast IPsec буюу Хурдан IPsec гэгддэг тоног төхөөрөмжөөр хурдасгасан IPsec стектэй. Энэ нь IPsec-ийн ажиллагааг оновчтой болгохын тулд &man.crypto.4; дэд системийн тусламжтайгаар криптограф тоног төхөөрөмжийг (аль болох бүх газар) хэрэглэдэг. Энэ нь шинэ дэд систем бөгөөд IPsec-ийн KAME хувилбарт байдаг бүх боломжуудыг дэмждэггүй. Гэхдээ тоног төхөөрөмжөөр хурдасгасан IPsec-ийг идэвхжүүлэхийн тулд өөрийн цөмийн тохиргооны файлдаа дараах цөмийн тохируулгыг нэмэх хэрэгтэй: цөмийн тохируулгууд FAST_IPSEC options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) IPsec-ийн KAME шийдлийн оронд Fast IPsec дэд системийг ашиглах боломж одоогоор байхгүйг тэмдэглэе. Дэлгэрэнгүй мэдээллийг &man.fast.ipsec.4; гарын авлагын хуудаснаас лавлана уу. Галт хануудад &man.gif.4; туннелийн төлөвийг бас зөв дагаж мөрдөх боломжийг олгохын тулд та өөрийн цөмийн тохиргооны файлдаа тохируулгыг идэвхжүүлэх хэрэгтэй: options IPSEC_FILTERGIF #filter ipsec packets from a tunnel IPsec ESP IPsec AH IPsec нь хоёр дэд протоколоос тогтоно: Encapsulated Security Payload (ESP) буюу Хайрцаглагдсан Аюулгүй байдлын ачаа нь гуравдагчийн нөлөөллөөс тэгш хэмт криптограф алгоритмийг (Blowfish, 3DES-тэй адил) ашиглан агуулгыг нь шифрлэж IP пакетийн өгөгдлийг хамгаалдаг. Authentication Header (AH) буюу Нэвтрэлт Танилтын Толгой нь аюулгүй хэш хийх функцаар IP пакетийн толгойн талбаруудыг хэш хийн криптограф хянах нийлбэрийг тооцоолон гуравдагч этгээдийн нөлөөлөл болон хууран мэхлэлтээс IP пакетийн толгойг хамгаалдаг. Үүний дараа пакет дахь мэдээллийг таниулахыг зөвшөөрөх хэшийг агуулсан нэмэлт толгой байдаг. ESP болон AH нь орчноосоо хамаараад хоёулаа цуг эсвэл тусдаа ашиглагдаж болно. VPN виртуал хувийн сүлжээ VPN IPsec нь хоёр хостын хоорондох урсгалыг шууд шифрлэх (Transport Mode буюу Тээвэрлэх Горим гэгддэг) буюу эсвэл хоёр корпорацийн сүлжээний хооронд аюулгүй холбоонд ашиглагдаж болох виртуал туннелиуд (Tunnel Mode буюу Туннелийн Горим гэгддэг) бүтээхэд хэрэглэгдэж болох юм. Сүүлийнх нь ерөнхийдөө Виртуал Хувийн Сүлжээ (VPN) гэгддэг. FreeBSD-ийн IPsec дэд системийн талаар дэлгэрэнгүй мэдээллийг &man.ipsec.4; гарын авлагын хуудаснаас лавлах хэрэгтэй. Өөрийн цөмдөө IPsec дэмжлэгийг нэмэхийн тулд та дараах тохируулгуудыг цөмийн тохиргоондоо нэмээрэй: цөмийн тохируулгууд IPSEC цөмийн тохируулгууд IPSEC_ESP options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) цөмийн тохируулгууд IPSEC_DEBUG Хэрэв IPsec дибаг хийх дэмжлэг заавал хэрэгтэй бол дараах цөмийн тохируулга бас нэмэгдсэн байх шаардлагатай: options IPSEC_DEBUG #debug for IP security Асуудал VPN-ийг байгуулахад ямар нэг стандарт байхгүй. VPN-үүд нь өөр өөрийн давуу болон сул талуудтай төрөл бүрийн технологиудыг ашиглан хийгдэж болно. Энэ хэсэг нь нэг тохиолдлын загвар үзүүлэх бөгөөд энэ тохиолдол дахь VPN-ийг хийхэд хэрэглэгдэх стратегиудыг харуулах болно. Тохиолдол: Интернэтэд холбогдсон, нэг юм шиг ажиллах хоёр сүлжээ VPN үүсгэх Угтвар нөхцөл дараах маягийн байна: Та хамгийн багадаа хоёр сайттай байна Хоёр сайт хоёулаа IP-г дотооддоо ашигладаг FreeBSD дээр нь ажилладаг гарц компьютераар хоёр сайт хоёулаа Интернэтэд холбогдсон. Хоёр сүлжээний гарц компьютер бүр хамгийн багаар бодоход нэг нийтийн IP хаягтай. Хоёр сүлжээний дотоод хаягууд нь нийтийн эсвэл хувийн IP хаягууд байж болох юм, энэ нь хамаагүй. Та гарц машин дээр хэрэв шаардлагатай бол NAT ажиллуулсан байж болох юм. Хоёр сүлжээний дотоод IP хаягууд мөргөлдөхгүй. Үүнийг ажиллуулахын тулд VPN технологи болон NAT-ийн хослолыг ашиглах нь онолын хувьд боломжтой боловч би үүнийг хар дарсан зүүд шигээр тохиргоо их төвөгтэй байх болов уу гэж бодож байна. Хоёр сүлжээ дотооддоо хоёулаа адилхан хувийн IP хаягийн хүрээ (өөрөөр хэлбэл хоёулаа 192.168.1.x) ашиглаж байгаа хоёр сүлжээг холбохыг оролдож байгаагаа хэрэв та мэдэх юм бол аль нэг сүлжээний IP-г дахин дугаарлах шаардлагатай болно. Сүлжээний бүтэц иймэрхүү харагдаж болох юм: Сүлжээ #1 [ Дотоод хостууд ] Хувийн Сүлжээ, 192.168.1.2-254 [ Win9x/NT/2K ] [ UNIX ] | | .---[fxp1]---. Хувийн IP, 192.168.1.1 | FreeBSD | `---[fxp0]---' Нийтийн IP, A.B.C.D | | -=-=- Интернэт -=-=- | | .---[fxp0]---. Нийтийн IP, W.X.Y.Z | FreeBSD | `---[fxp1]---' Хувийн IP, 192.168.2.1 | | Сүлжээ #2 [ Internal Hosts ] [ Win9x/NT/2K ] Хувийн Сүлжээ, 192.168.2.2-254 [ UNIX ] Хоёр нийтийн IP хаяг байгааг анзаарна уу. Нийтлэлийн туршид би эдгээрийг үсгээр орлуулан ашиглах болно. Энэ нийтлэлийн туршид тохиолдох эдгээр үсэгнүүдийн оронд өөрийн нийтийн хаягаар орлуулж тавиарай. Мөн дотроо хоёр гарц машин маань .1 IP хаягтай бөгөөд хоёр сүлжээ маань өөр өөр хувийн IP хаягийн хүрээтэйг (192.168.1.x болон 192.168.2.x) анхаарна уу. Хувийн сүлжээнүүд дэх бүх машинууд өөрсдийн анхдагч гарцдаа .1 машиныг ашиглахаар тохируулсан байгаа болно. Гол зорилго нь сүлжээ талаасаа авч үзэх юм бол сүлжээ болгон нөгөө сүлжээнийхээ машинуудыг яг л нэг чиглүүлэгчид холбоотой юм шиг харж чадан ажиллаж байх ёстой -- гэвч энэ чиглүүлэгч нь хааяа пакетуудыг гээдэг илүү удаан чиглүүлэгч байх юм. Энэ нь (жишээ нь) 192.168.1.20 машин дараах тушаалыг ажиллуулж ping 192.168.2.34 нэвт ажиллаж чадах ёстой гэсэн үг юм. &windows; машинууд өөр сүлжээн дээр байх машинуудыг харж файлын хуваалцал санг үзэх зэргийг хийж локал сүлжээн дээр байгаа машинуудыг харж үзэж чаддаг шигээр ажиллаж чадаж байх ёстой. Тэгээд бүх юм аюулгүй байх хэрэгтэй. Энэ нь хоёр сүлжээний хоорондох урсгал шифрлэгдэх ёстой гэсэн үг юм. Эдгээр хоёр сүлжээний хооронд VPN үүсгэх нь олон алхамтай процесс юм. Эдгээр нь: Интернэтийн дагуу хоёр сүлжээний хооронд виртуал сүлжээний холболт үүсгэнэ. Ажиллаж байгааг нь шалгаж &man.ping.8; зэрэг багажуудыг ашиглаж тест хийгээрэй. Хоёр сүлжээний хоорондох урсгал харагдахгүйгээр шифрлэгдэж шаардлагатай бол буцаан шифрлэгдэх тэр боломжийг бүрдүүлэх аюулгүй байдлын бодлогуудыг зааж өгөөрэй. Урсгал шифрлэгдэж байгааг эсэхийг шалгаж &man.tcpdump.1; зэрэг багажууд ашиглан тест хийгээрэй. VPN-ийн дагуу &windows; машинууд нэг нь нөгөөгөө харж байхыг зөвшөөрөх нэмэлт програм хангамжийг FreeBSD гарц машинууд дээр тохируулаарай. Алхам 1: <quote>виртуал</quote> сүлжээний холболт үүсгэн тест хийх Сүлжээ #1 дээрх гарц машин (A.B.C.D нийтийн IP хаягтай, 192.168.1.1 хувийн IP хаягтай) уруу та нэвтрэн орсон бөгөөд W.X.Y.Z IP хаягтай машины хувийн хаяг уруу нь ping 192.168.2.1 гэж тушаал ажиллуулъя гэж бодъё. Ингэж ажиллахын тулд юу болох ёстой вэ? Гарц машин 192.168.2.1 уруу яаж хүрэхээ мэдэх ёстой. Өөрөөр хэлбэл энэ нь 192.168.2.1 уруу хийгдсэн чиглүүлэлттэй байх хэрэгтэй. 192.168.x зэрэг хувийн IP хаягууд Интернэт дээр бараг үзэгдэх ёсгүй. Харин 192.168.2.1 уруу таны илгээсэн пакет бүр өөр пакет дотор орсон байх ёстой. Энэ пакет нь A.B.C.D машинаас ирсэн маягаар байх ёстой бөгөөд W.X.Y.Z уруу илгээгдэх ёстой. Энэ процессийг encapsulation буюу хайрцаглалт гэж нэрлэдэг. Энэ пакет нь W.X.Y.Z дээр ирээд unencapsulated буюу буцааж ялгагдан 192.168.2.1 уруу хүргэгдэх хэрэгтэй. Та үүнийг хоёр сүлжээний хоорондох туннель гэж ойлгож болно. Туннелийн хоёр амсар нь A.B.C.D болон W.X.Y.Z IP хаягууд бөгөөд туннельд түүгээр дамжин өнгөрөх хувийн IP хаягуудыг мэдэгдсэн байх шаардлагатай. Туннель нь нийтийн Интернэтээр хувийн IP хаягтай урсгалыг дамжуулахад хэрэглэгдэнэ. Энэ туннель нь ерөнхий интерфэйс эсвэл FreeBSD дээрх gif төхөөрөмж ашиглан үүсгэгддэг. Таны бодсоноор гарц машин бүр дээрх gif интерфэйс нь дөрвөн IP хаягтай байхаар тохируулагдсан байх шаардлагатай; хоёр нь нийтийн IP хаяг, хоёр нь хувийн IP хаяг. Хоёр машины хувьд gif төхөөрөмжийн дэмжлэг &os;-ийн цөмд эмхэтгэгдсэн байх шаардлагатай. Та дараах мөрийг: device gif хоёр машины цөмийн тохиргооны файлд хийн дараа нь эмхэтгэн суулгаж дахин ачаалснаар үүнийг хийж болно. Туннелийг тохируулах нь хоёр алхамтай процесс юм. Эхлээд туннельд ямар гадаад (эсвэл нийтийн) IP хаягууд байгааг &man.ifconfig.8; ашиглан мэдэгдэх ёстой. Тэгээд дараа нь хувийн IP хаягуудыг &man.ifconfig.8; тушаал ашиглан тохируулах ёстой. Сүлжээ #1 дэх гарц машин дээр туннелийг тохируулахын тулд та дараах тушаалуудыг ашиглах болно. &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 tunnel A.B.C.D W.X.Y.Z &prompt.root; ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff Нөгөө нэг гарц машин дээр та адил тушаалуудыг гэхдээ IP хаягуудын дарааллыг эсрэгээр тавин ажиллуулна. &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 tunnel W.X.Y.Z A.B.C.D &prompt.root; ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff Та дараа нь: ifconfig gif0 ажиллуулж тохиргоог харж болно. Жишээ нь сүлжээ #1 дээрх гарц машин дээр та үүнийг харах болно: &prompt.root; ifconfig gif0 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 tunnel inet A.B.C.D --> W.X.Y.Z inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff Эндээс харахад A.B.C.D болон W.X.Y.Z физик хаягуудын хооронд туннель үүссэн бөгөөд туннелээр зөвшөөрөгдөх урсгал нь 192.168.1.1 болон 192.168.2.1-ийн хооронд байна. Энэ нь бас хоёр машин дээрх чиглүүлэлтийн хүснэгтэд бас оруулга нэмсэн байх бөгөөд та үүнийг netstat -rn тушаал ашиглан шалгаж болно. Доорх гаралт нь сүлжээ #1 дэх гарц машиных юм. &prompt.root; netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire ... 192.168.2.1 192.168.1.1 UH 0 0 gif0 ... Flags утгын харуулж байгаагаар энэ нь хостын чиглүүлэлт бөгөөд энэ нь гарц бүр нөгөө гарц уруу хэрхэн хүрэхээ мэдэх боловч тэд харин өөрсдийнхөө харгалзах сүлжээнүүд уруу хэрхэн хүрэхээ мэдэхгүй гэсэн үг юм. Энэ асуудлыг удахгүй засварлах болно. Энэ нь хоёр машин дээр хоёулан дээр нь галт хана ажиллаж гэсэн үг юм. Таны VPN урсгалын хувьд үүнийг тойрон гарах шаардлагатай. Та хоёр сүлжээний хоорондох бүх урсгалыг зөвшөөрөх юм уу эсвэл VPN-ий хоёр төгсгөлийг нэгээс нөгөөг хамгаалах галт ханын дүрмүүдийг оруулж болох юм. Хэрэв VPN-ээр өнгөрөх бүх урсгалыг зөвшөөрөхөөр галт ханыг тохируулах юм бол энэ нь тест хийхийг ихээхэн амарчлах болно. Та дараа нь хэзээ ч галт ханаа илүү чангаруулж болно. Хэрэв та &man.ipfw.8; тушаалыг гарц машинууд дээр ашиглаж байгаа бол дараах ipfw add 1 allow ip from any to any via gif0 тушаал нь хоёр төгсгөлийн цэгийн хоорондох бүх урсгалыг таны галт ханын бусад дүрмүүдийг хөндөлгүйгээр зөвшөөрөх болно. Мэдээж та энэ тушаалыг хоёр гарц хост дээр хоёулан дээр ажиллуулах хэрэгтэй болно. Нэг гарц машинаас нөгөө уруугаа ping хийхийг зөвшөөрөхөд хангалттай. 192.168.1.1 дээр та дараах ping 192.168.2.1 тушаалыг ажиллуулж хариу хүлээж авахаас гадна мөн нөгөө гарц машин дээрээс бас ингэж хийж чадаж байх ёстой. Гэхдээ та хоёр сүлжээний дотоод машинууд уруу арай хүрч чадахгүй байх ёстой. Энэ нь чиглүүлэлтээс болж байгаа юм -- гарц машинууд бие бие уруугаа хэрхэн хүрэхээ мэдэж байгаа боловч нэг нэгнийнхээ цаана байгаа сүлжээнд хэрхэн хүрэхийг мэдэхгүй. Энэ асуудлыг шийдэхийн тулд та гарц машин бүр дээр статик чиглүүлэлт нэмэх хэрэгтэй. Эхний гарц дээр хийх тушаал нь: route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 Энэ нь 192.168.2.0 сүлжээний хостуудад хүрэхийн тулд пакетуудыг 192.168.2.1 хост уруу илгээ гэж байна. Та үүнтэй адил тушаалыг нөгөө гарц дээр бас ажиллуулах хэрэгтэй бөгөөд гэхдээ 192.168.1.x хаягуудыг ашиглах ёстой. Одоо нэг сүлжээн дэх хостуудын IP урсгал нөгөө сүлжээний хостуудад хүрэх боломжтой болно. Энэ нь одоо хоёр сүлжээний хооронд VPN-ий гуравны хоёрыг үүсгэж байгаа бөгөөд аль болох виртуалаар үүсгэгдсэн сүлжээ юм. Энэ нь одоохондоо хувийн биш байгаа. Та үүнийг &man.ping.8; болон &man.tcpdump.1; ашиглан тест хийж болно. Гарц хост уруу нэвтрэн орж дараах тушаалыг ажиллуулна tcpdump dst host 192.168.2.1 Тэр хост дээрээ өөр сессээр дараах тушаалыг ажиллуулна ping 192.168.2.1 Та иймэрхүү гаралтыг харах болно: 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply Эндээс харахад ICMP мэдэгдлүүд нааш цааш шифрлэгдэлгүй явж байна. Хэрэв та пакетуудаас өгөгдлийн байтуудыг илүүтэйгээр авахын тулд &man.tcpdump.1; уруу параметрийг өгч ашигласан бол илүү мэдээлэл та харж болох юм. Энэ нь мэдээж хүлээн авах боломжгүй зүйл юм. Дараагийн хэсэгт хоёр сүлжээний хоорондох холболтыг бүх урсгал нь автоматаар шифрлэгдэхээр аюулгүй болгох талаар хэлэлцэх болно. Дүгнэн хэлэхэд: Хоёр цөмийг device gif мөртэйгөөр тохируулна. Гарц хост #1 дээрх /etc/rc.conf файлд засвар хийн дараах мөрүүдийг нэмнэ (шаардлагатай тохиолдолд IP хаягуудыг сольно). gif_interfaces="gif0" gifconfig_gif0="A.B.C.D W.X.Y.Z" ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" static_routes="vpn" route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" Хоёр хост дээрх гарц скриптийг (/etc/rc.firewall, эсвэл үүнтэй адил) засварлаж доор дурдсаныг нэмнэ. ipfw add 1 allow ip from any to any via gif0 IP хаягуудын дарааллыг эсрэгээр болгон гарц хост #2 дээрх /etc/rc.conf файлд адил өөрчлөлтийг хийнэ. Алхам 2: Холболтыг аюулгүй болгох Холболтыг аюулгүй болгохын тулд бид IPsec-ийг ашиглах болно. IPsec нь хоёр хостыг шифрлэлтийн түлхүүр дээр зөвшилцүүлж дараа нь уг хоёр хостын хооронд өгөгдлийг шифрлэхийн тулд энэ түлхүүрийг ашиглах арга замыг өгдөг. Энд тохиргооны хоёр талбарыг бодолцох хэрэгтэй. Ашиглах шифрлэлтийн арга зам дээр хоёр хост зөвшилцөх тийм арга зам байх ёстой. Хоёр хост энэ арга зам дээр зөвшилцсөний дараа тэдгээрийн хооронд аюулгүй байдлын нэгдэл байна гэж үздэг. Аль урсгалыг шифрлэх ёстойг заах арга зам байх ёстой. Мэдээж та өөрийн бүх гарч байгаа урсгалаа шифрлэхийг хүсэхгүй байх -- та зөвхөн VPN-ий хэсэг болсон урсгалыг шифрлэхийг хүснэ. Аль урсгалыг шифрлэхийг тодорхойлохын тулд хийгдэх дүрмүүд нь security policies буюу аюулгүй байдлын бодлогууд гэгдэнэ. Аюулгүй байдлын нэгдлүүд болон аюулгүй байдлын бодлогуудын ажиллагааг цөм хангаж байдаг бөгөөд хэрэглэгчдийн талбарын програмуудаар засварлагдаж болно. Гэхдээ үүнийг хийхийн өмнө IPsec болон Encapsulated Security Payload (ESP) буюу Хайрцаглагдсан Аюулгүй байдлын Ачаа протоколыг цөм дэмжихээр та тохируулах хэрэгтэй. Цөмийг: цөмийн тохируулгууд IPSEC options IPSEC options IPSEC_ESP тохируулгатай тохируулан дахин эмхэтгэж суулгаад ачаалан үүнийг хийнэ. Урьдын адил та хоёр гарц машин дээрх цөмийн хувьд үүнийг хийх ёстой. IKE Аюулгүй байдлын нэгдлүүдийг тохируулах үед танд хоёр сонголт байна. Шифрлэлтийн алгоритм, шифрлэлтийн түлхүүрүүд гэх зэргүүдийг сонгож тэдгээр нэгдлүүдийг хоёр хостын хооронд гараараа тохируулж болох бөгөөд эсвэл эдгээрийг хийх Internet Key Exchange protocol (IKE) буюу Интернэтийн Түлхүүр Солилцох протоколыг шийддэг дэмонуудыг та ашиглаж болно. Би сүүлийнхийг зөвлөж байна. Өөр бусдыг тооцохгүй юм бол үүнийг тохируулах нь амархан. IPsec аюулгүй байдлын бодлогууд setkey Аюулгүй байдлын бодлогуудыг засварлах болон үзүүлэхдээ &man.setkey.8;-г ашиглан хийдэг. Адилтгах юм бол setkey нь цөмийн аюулгүй байдлын бодлогын хүснэгтүүдэд &man.route.8; цөмийн чиглүүлэлтийн хүснэгтүүдэд зориулагдсан шиг зориулагдсан байна. setkey нь бас одоогийн аюулгүй байдлын нэгдлүүдийг үзүүлж чадах бөгөөд адилтган цааш үргэлжлүүлбэл энэ нь бас netstat -r тушаалын нэгэн адил болох юм. FreeBSD-ээр аюулгүй байдлын нэгдлүүдийг удирдах дэмонуудын хувьд хэд хэдэн сонголт байдаг. Энэ нийтлэл нь эдгээрийн нэг &os;-ийн Портуудын цуглуулгын security/ipsec-tools-д байдаг racoon-ийг хэрхэн ашиглах талаар тайлбарлах болно. racoon racoon програм хангамж хоёр гарц машин дээр хоёулан дээр нь ажиллах ёстой. Энэ нь хост бүр дээр VPN-ий нөгөө төгсгөлийн IP хаяг болон нууц түлхүүртэйгээр (таны сонгох түлхүүр байх бөгөөд хоёр гарц машин дээр ижил байх ёстой) тохируулагддаг. Дараа нь хоёр дэмон нэг нэгэндээ хандаж тэдгээр нь өөрсдөө хэн хэн гэж хэлснээ (таны тохируулсан нууц түлхүүрийг ашиглан) баталгаажуулдаг. Дэмонууд дараа нь шинэ нууц түлхүүрийг үүсгэж түүнийг ашиглан VPN-ээр урсгалыг шифрлэдэг. Тэд энэ нууцаа үе үе өөрчилдөг бөгөөд халдагч түлхүүрүүдийн аль нэгийг эвдсэн ч (цагаа тулахаар энэ нь онолын хувьд бараг боломжгүй зүйл) гэсэн энэ нь халдагчид муу юм хийх боломж олгодоггүй -- түлхүүрийг эвдэх тэр үед хоёр дэмон өөр түлхүүрийг сонгосон байна. racoon-ий тохиргооны файл ${PREFIX}/etc/racoon-д байрлана. Та энд тохиргооны файлыг олох ёстой бөгөөд түүнд нэг их өөрчлөлт хийгдэх ёсгүй. Таны өөрчлөх шаардлагатай racoon-ий тохиргооны файлын өөр нэг бүрэлдэхүүн хэсэг нь pre-shared key буюу урьдчилан хуваалцсан түлхүүр юм. racoon-ий анхдагч тохиргоо үүнийг ${PREFIX}/etc/racoon/psk.txt-д байгаа гэж боддог. Урьдчилан хуваалцсан түлхүүр нь таны урсгалыг VPN-ийн дагуу шифрлэх түлхүүр биш бөгөөд харин энэ нь ердөө л түлхүүр удирдах дэмонуудыг нэг нь нөгөөдөө итгэхийг зөвшөөрөх токен гэдгийг тэмдэглэж хэлэх нь зүйтэй юм. psk.txt нь таны ажиллаж байгаа алсын сайт бүрийн мөрийг агуулсан байна. Хоёр сайт бүхий энэ жишээн дээр psk.txt файл бүр нэг мөрийг агуулсан байна (VPN-ий төгсгөлүүд бүр зөвхөн нөгөө төгсгөлтэйгээ ажилладаг). Гарц хост #1 дээр энэ мөр иймэрхүү харагдах ёстой: W.X.Y.Z secret Энэ нь алсын төгсгөлийн нийтийн IP хаяг, хоосон зай, тэгээд нууц үгийг илэрхийлэх текст мэдээлэл байна. Мэдээж та өөрийн түлхүүртээ secret гэдгийг ашиглах ёсгүй -- нууц үгийг сонгох энгийн дүрэм энд үйлчилнэ. Гарц хост #2 дээр энэ мөр иймэрхүү харагдах ёстой A.B.C.D secret Энэ нь алсын төгсгөлийн IP хаяг болон адилхан нууц түлхүүр байна. psk.txt нь racoon ажиллахаас өмнө 0600 (өөрөөр хэлбэл root-д зөвхөн унших/бичих) горимд байна. Та racoon-ийг хоёр гарц машин дээр ажиллуулах ёстой. Та бас UDP-ээр ISAKMP (Internet Security Association Key Management Protocol буюу Интернэтийн Аюулгүй байдлын Нэгдлийн Түлхүүр Удирдах Протокол) порт уруу зөөгдөх IKE урсгалыг зөвшөөрөх галт ханын зарим дүрмүүдийг нэмэх хэрэгтэй. Дахин хэлэхэд энэ нь таны галт ханын дүрмийн олонлогт нэлээн эрт байх шаардлагатай. ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp racoon ажилласны дараа та нэг гарц хостоос нөгөө гарц хост уруу ping хийж үзэж болно. Холболт нь шифрлэгдээгүй байх боловч racoon дараа нь аюулгүй байдлын нэгдлүүдийг хоёр хостын хооронд тохируулна -- энэ нь хором болж өнгөрч болох бөгөөд ping тушаал хариу өгч эхлэх хүртэл богино саатал маягаар танд харагдаж болох юм. Аюулгүй байдлын нэгдэл тохируулагдсаны дараа та үүнийг &man.setkey.8; ашиглан үзэж болно. setkey -D тушаалыг аль нэг хост дээр ажиллуулж аюулгүй байдлын нэгдлийн мэдээллийг харна. Энэ нь асуудлын нэг хагас нь юм. Нөгөө нэг хагас нь өөрийн аюулгүй байдлын бодлогуудыг тохируулах явдал юм. Ухаалаг аюулгүй байдлын бодлогыг үүсгэхийн тулд энэ хүртэл юуг хийснээ эргэн харцгаая. Энэ хэлэлцээ нь холболтын төгсгөлийн хоёулангийнх нь хувьд авч үзнэ. Таны гадагш илгээх IP пакет бүр пакетийн тухай өгөгдлийг агуулах толгойтой байдаг. Толгой нь эхлэл болон төгсгөлийн IP хаягуудыг агуулдаг. Бидний мэдэж байгаагаар 192.168.x.y зэрэг хувийн IP хаягууд нийтийн Интернэт дээр ил гарах ёсгүй. Харин тэд эхлээд өөр пакет дотор хайрцаглагдах ёстой. Энэ пакет нь хувийн хаягуудын оронд солигдсон нийтийн эхлэл болон төгсгөл IP хаягуудтай байх ёстой. Тэгэхээр хэрэв таны гарч байгаа пакет иймэрхүү харагдаж эхэлбэл: .----------------------. | Src: 192.168.1.1 | | Dst: 192.168.2.1 | | <other header info> | +----------------------+ | <packet data> | `----------------------' Дараа нь өөр нэг пакетийн дотор энэ нь хайрцаглагдан иймэрхүү харагдах болно: .--------------------------. | Src: A.B.C.D | | Dst: W.X.Y.Z | | <other header info> | +--------------------------+ | .----------------------. | | | Src: 192.168.1.1 | | | | Dst: 192.168.2.1 | | | | <other header info> | | | +----------------------+ | | | <packet data> | | | `----------------------' | `--------------------------' Энэ хайрцаглалт нь gif төхөөрөмжөөр хийгдэнэ. Пакет нь гадна талдаа жинхэнэ IP хаягуудтай байх бөгөөд бидний эхний пакет Интернэт уруу гарах пакет дотор орсон байгааг харж болно. Мэдээж бид VPN-үүдийн хоорондох бүх урсгалыг шифрлэхийг хүснэ. Та үүнийг иймэрхүүгээр үгчлэн хэлж болно: Хэрэв пакет A.B.C.D-с гарч W.X.Y.Z уруу чиглэсэн бол шаардлагатай аюулгүй байдлын нэгдлүүдийг ашиглан шифрлэнэ. Хэрэв пакет нь W.X.Y.Z-с ирж A.B.C.D уруу чиглэсэн бол шаардлагатай аюулгүй байдлын нэгдлүүдийг ашиглан буцааж шифрлэнэ. Ингэж хэлэхэд ер нь бараг л зөв, ойрхон байна, гэхдээ бас тийм ч зөв биш юм. Хэрэв та үүнийг хийсэн бол W.X.Y.Z-с гарсан болон түүн уруу чиглэсэн, бүр VPN-ий хэсэг ч биш бүх урсгал шифрлэгдэх болно. Та яг үүнийг хүсээгүй байх. Зөв бодлого нь дараах маягаар байна Хэрэв пакет A.B.C.D-с гарч тэр пакет нь өөр пакет дотор орон хайрцаглагдан W.X.Y.Z уруу чиглэсэн бол шаардлагатай аюулгүй байдлын нэгдлүүдийг ашиглан шифрлэнэ. Хэрэв пакет нь W.X.Y.Z-с ирж тэр пакет нь өөр пакет дотор орон хайрцаглагдан A.B.C.D уруу чиглэсэн бол шаардлагатай аюулгүй байдлын нэгдлүүдийг ашиглан буцааж шифрлэнэ. Нарийн өөрчлөлт, гэхдээ хэрэгтэй нэгэн. Аюулгүй байдлын бодлогууд нь бас &man.setkey.8; ашиглагдан заагдана. &man.setkey.8; нь бодлого тодорхойлох тохиргооны хэлтэй байна. Та тохиргооны заавруудыг stdin-ээс оруулж болох бөгөөд эсвэл тохиргооны заавруудыг агуулах файлын нэрийг зааж өгөх тохируулгыг ашиглаж болно. Гарц хост #1-ийн (A.B.C.D гэсэн нийтийн IP хаягтай) тохиргоо W.X.Y.Z уруу чиглэсэн бүх гарах урсгалыг хүчээр шифрлэхийн тулд: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Эдгээр тушаалуудыг файлд (өөрөөр хэлбэл /etc/ipsec.conf) хийгээд ажиллуулаарай &prompt.root; setkey -f /etc/ipsec.conf нь бид аюулгүй бодлогын мэдээллийн санд дүрэм нэмэхийг хүсэж байгааг &man.setkey.8;-д хэлж өгч байна. Энэ мөрийн бусад нь энэ бодлогод аль пакет таарахыг заана. A.B.C.D/32 ба W.X.Y.Z/32 нь энэ бодлого хамаарах сүлжээ болон хостуудыг таних IP хаягууд болон сүлжээний багууд юм. Энэ тохиолдолд эдгээр хоёр хостуудын хоорондох урсгалд үүнийг хамааруулахыг бид хүсэж байна. нь энэ бодлого зөвхөн бусад пакетуудыг хайрцаглах пакетуудад хамаатай гэдгийг цөмд хэлнэ. тохируулга нь энэ бодлого гарах пакетуудад хамаатайг хэлэх бөгөөд тохируулга нь пакет нууцлагдахыг хэлж байна. Хоёр дахь мөр нь энэ пакет хэрхэн шифрлэгдэхийг заана. нь ашиглагдах протокол байхад нь пакетийг цаашаагаа IPsec пакет дотор орж хайрцаглалт хийгдэхийг заана. A.B.C.D болон W.X.Y.Z-ийн давхардсан хэрэглээ нь ашиглах аюулгүй байдлын нэгдлийг сонгоход хэрэглэгдэх бөгөөд төгсгөлийн тохируулга энэ дүрмэнд таарсан пакетуудыг шифрлэх ёстойг зааж байна. Энэ дүрэм нь зөвхөн гарч байгаа пакетуудтай таарна. Ирж байгаа пакетийн хувьд танд үүнтэй адил дүрэм хэрэгтэй. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; Энэ тохиолдолд -ийн оронд тохируулгыг ашиглаж шаардлагын дагуу IP хаягуудыг эсрэгээр болгосныг хараарай. Нөгөө нэг гарц хостод (W.X.Y.Z нийтийн IP хаягтай) үүнтэй адил дүрмүүд хэрэгтэй. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Төгсгөлд нь та ESP болон IPENCAP пакетуудыг нааш цааш зөвшөөрөх галт ханын дүрмүүдийг нэмэх хэрэгтэй. Эдгээр дүрмүүдийг хост бүр дээр нэмэх шаардлагатай. ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Дүрмүүд нь тэгш хэмт учир адилхан дүрмүүдийг та гарц хост бүр дээр ашиглаж болно. Одоо гарч байгаа пакетууд үүнтэй адил харагдах болно: .------------------------------. --------------------------. | Src: A.B.C.D | | | Dst: W.X.Y.Z | | | <other header info> | | Encrypted +------------------------------+ | packet. | .--------------------------. | -------------. | contents | | Src: A.B.C.D | | | | are | | Dst: W.X.Y.Z | | | | completely | | <other header info> | | | |- secure | +--------------------------+ | | Encap'd | from third | | .----------------------. | | -. | packet | party | | | Src: 192.168.1.1 | | | | Original |- with real | snooping | | | Dst: 192.168.2.1 | | | | packet, | IP addr | | | | <other header info> | | | |- private | | | | +----------------------+ | | | IP addr | | | | | <packet data> | | | | | | | | `----------------------' | | -' | | | `--------------------------' | -------------' | `------------------------------' --------------------------' Тэдгээрийг VPN-ий хамгийн төгсгөлд хүлээн авах үед тэдгээр нь эхлээд буцаан шифрлэгдэнэ (racoon-аар тохиролцсон аюулгүй байдлын нэгдлүүдийг ашиглан). Тэдгээр нь үүний дараа хоёр дахь давхаргыг гаргах gif интерфэйс уруу орж хамгийн дотор байрлах пакеттай үлдэх хүртэл боловсруулагдаад дотоод сүлжээ руу аялах болно. Өмнө дурдсаны адил та &man.ping.8; тестийг ашиглан аюулгүй байдлыг шалгаж болно. Эхлээд A.B.C.D гарц машин уруу нэвтрэн орж дараах тушаалыг ажиллуулна: tcpdump dst host 192.168.2.1 Тэр хост дээрээ өөр сессээр дараах тушаалыг ажиллуулна ping 192.168.2.1 Энэ удаад та доор дурдсантай адил гаралтыг харах ёстой: XXX tcpdump output Одоо эндээс харах юм бол &man.tcpdump.1; нь ESP пакетуудыг үзүүлж байна. Хэрэв та тэдгээрийг тохируулгатай шалгахыг оролдвол шифрлэлтээс болоод (мэдээж) нууцлаг харагдах болно. Баяр хүргэе. Та дөнгөж сая алсын хоёр сайтын хооронд VPN тохирууллаа. Дүгнэн хэлэхэд Хоёр цөмийг хоёуланг нь дараах тохируулгатай тохируулна: options IPSEC options IPSEC_ESP security/ipsec-tools суулгана. Алсын хостын IP хаяг болон тэдгээрийн мэддэг нууц түлхүүрийн оруулгыг нэмж ${PREFIX}/etc/racoon/psk.txt файлыг хоёр гарц хост дээр хоёулан дээр засварлана. Энэ файлын горим 0600 байгааг шалгаарай. Хост бүр дээрх /etc/rc.conf файлд дараах мөрүүдийг нэмээрэй: ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" Хост бүр дээр шаардлагатай spadd мөрүүдийг агуулсан /etc/ipsec.conf файл үүсгэна. 1-р гарц хост дээр энэ нь ийм байна: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; 2-р гарц хост дээр энэ нь ийм байна: spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Хост бүр дээр IKE, ESP, болон IPENCAP урсгалыг зөвшөөрөх галт ханын дүрмүүд нэмээрэй: ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Өмнөх хоёр алхам VPN-ийг эхлүүлэн ажиллуулахад хангалттай байх ёстой. Сүлжээ бүрийн машинууд өөр хоорондоо IP хаягуудаараа хандах боломжтой болох бөгөөд холболтын дагуух бүх урсгал автоматаар аюулгүй шифрлэгдэх болно. Шерн Ли Хувь нэмэр болгон оруулсан OpenSSH OpenSSH аюулгүй байдал OpenSSH OpenSSH нь алсын машинуудад аюулгүйгээр хандах сүлжээний холболтын хэрэгслүүдийн олонлог юм. rlogin, rsh, rcp, болон telnet-ийг энэ програмаар шууд орлуулан ашиглаж болно. Мөн TCP/IP холболтууд аюулгүйгээр SSH-ээр туннель хийгдэж/дамжуулагдаж болдог. OpenSSH нь сэм чагналт, холболт булаан авалт, болон бусад сүлжээний түвшний халдлагуудыг үр дүнтэйгээр устгаж бүх трафикийг шифрлэдэг. OpenSSH-г OpenBSD төсөл дэмжиж байдаг бөгөөд бүх сүүлийн үеийн алдааны засварууд болон шинэчлэлтүүд бүхий SSH v1.2.12 дээр тулгуурласан байдаг. Энэ програм нь SSH протокол 1 болон 2-той хоёулантай нь нийцтэй. OpenSSH-ийг ашиглах давуу тал &man.telnet.1; эсвэл &man.rlogin.1; ашиглаж байх үед сүлжээгээр илгээгдэж байгаа өгөгдөл цэвэр, шифрлэгдээгүй хэлбэрээр байдаг. Сүлжээний шиншлэгчид клиент болон серверийн хооронд хаана ч байсан гэсэн таны хэрэглэгч/нууц үгийн мэдээлэл эсвэл таны сессээр дамжсан өгөгдлийг хулгайлж чадна. OpenSSH нь ийм асуудлаас хамгаалж төрөл бүрийн нэвтрэлт таних болон шифрлэх аргуудыг санал болгодог. sshd-г идэвхжүүлэх OpenSSH идэвхжүүлэх sshd нь стандарт &os; суулгацын явцад харуулагдах тохируулга юм. sshd идэвхжсэн эсэхийг харахдаа rc.conf файлаас дараах мөрийг шалгаарай: sshd_enable="YES" Энэ нь дараагийн удаа таны систем эхлэхэд OpenSSH-д зориулсан &man.sshd.8; дэмон програмыг дуудна. Мөн /etc/rc.d/sshd &man.rc.8; скрипт ашиглан OpenSSH-г эхлүүлэх боломжтой байдаг: /etc/rc.d/sshd start SSH клиент OpenSSH клиент &man.ssh.1; хэрэгсэл &man.rlogin.1;-тэй адил ажилладаг. &prompt.root; ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* Нэвтрэлт нь rlogin эсвэл telnet ашиглан үүсгэгдсэн сесс шиг үргэлжлэх болно. SSH нь хэрэглэгч холбогдоход серверийн жинхэнэ эсэхийг шалгахын тулд түлхүүр хээ шалгах системийг хэрэглэдэг. Хэрэглэгч зөвхөн эхний удаа холбогдоход yes гэж оруулахыг шаардана. Дараа дараагийн нэвтрэлт оролдлогууд бүгд хадгалсан хээ шалгах түлхүүртэй харьцуулагдан шалгагддаг. Хэрэв хадгалсан хээ нь дараа дараагийн нэвтрэлтийн оролдлогуудаас хүлээн авсан хээнээс өөр бол SSH клиент нь танд түгшүүр өгнө. Хээнүүд ~/.ssh/known_hosts файлд эсвэл SSH v2-ийн хээнүүд ~/.ssh/known_hosts2 файлд хадгалагдана. Анхдагчаар OpenSSH серверүүдийн сүүлийн үеийн хувилбарууд зөвхөн SSH v2 холболтуудыг хүлээн авдаг. Клиент нь хэрэв боломжтой бол 2-р хувилбарыг ашиглах бөгөөд боломжгүй бол 1-р хувилбарыг ашигладаг. эсвэл тохируулгуудыг 1-р эсвэл 2-р хувилбаруудад зориулан дамжуулан клиентэд зөвхөн аль нэгийг ашиглахыг хүчилж болно. 1-р хувилбарын нийцтэй байдал нь клиентэд хуучин хувилбаруудтай нийцтэй байх зорилгоор дэмжигдсэн байдаг. Аюулгүй хуулбарлалт OpenSSH аюулгүй хуулбарлалт scp &man.scp.1; тушаал &man.rcp.1;-тэй адил ажилладаг; энэ нь файлыг алсын машинаас эсвэл машин уруу, ялгаатай нь аюулгүйгээр хуулдаг. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Өмнөх жишээн дээр энэ хостын хувьд хээ нь аль хэдийн хадгалагдсан болохоор &man.scp.1;-ийг энд ашиглах үед шалгагддаг. &man.scp.1;-ээр дамжуулсан нэмэлт өгөгдлүүд нь &man.cp.1;-тэй адил бөгөөд эхний нэмэлт өгөгдөлд файл эсвэл файлууд, хоёр дахь дээр очих файлыг зааж өгдөг. Файл нь сүлжээгээр SSH-ээр татагддаг болохоор файлын нэг эсвэл хэд хэдэн нэмэлт өгөгдлүүд хэлбэрийг авдаг. Тохиргоо OpenSSH тохиргоо OpenSSH дэмон болон клиентийн системийн дагуух тохиргооны файлууд /etc/ssh санд байрладаг. ssh_config клиентийн тохируулгуудыг тохируулдаг бөгөөд sshd_config нь дэмонг тохируулдаг. Мөн (анхдагчаар /usr/sbin/sshd) болон rc.conf тохируулгууд тохиргооны түвшнүүдийг илүүтэйгээр хангадаг. ssh-keygen Нууц үгүүдийг ашиглахын оронд &man.ssh-keygen.1; нь хэрэглэгчийг шалгаж танихад DSA эсвэл RSA түлхүүрүүдийг үүсгэхэд хэрэглэгдэж болно: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com &man.ssh-keygen.1; нь шалгаж танихад хэрэглэгдэх нийтийн болон хувийн түлхүүр хослолыг үүсгэнэ. Хувийн түлхүүр ~/.ssh/id_dsa эсвэл ~/.ssh/id_rsa-д хадгалагдах бөгөөд харин нийтийн түлхүүр нь ~/.ssh/id_dsa.pub эсвэл ~/.ssh/id_rsa.pub-д DSA болон RSA түлхүүрийн төрлүүдэд зориулагдан хадгалагддаг. Тохируулга нь ажиллахын тулд нийтийн түлхүүр нь алсын машины ~/.ssh/authorized_keys файлд DSA болон RSA түлхүүрүүдийн хоёулангийнх нь хувьд хийгдэх ёстой байдаг. Үүнтэй адилаар нийтийн түлхүүрүүдийн RSA хувилбар нь ~/.ssh/authorized_keys файлд бас хийгдэх ёстой. Энэ нь нууц үгүүдийн оронд SSH түлхүүрүүдийг ашиглан алсын машин уруу холбогдохыг зөвшөөрөх болно. Хэрэв нэвтрэх үгнүүд &man.ssh-keygen.1;-д ашиглагдаж байгаа бол хувийн түлхүүрийг хэрэглэхийн тулд хэрэглэгчээс нууц үгийг нэвтрэх болгонд асуудаг. &man.ssh-agent.1; нь урт нэвтрэх үгнүүдийг дахин дахин оруулах тэр зовлонг зөөллөж чадах бөгөөд хэсэгт тайлбарлагдсан байгаа болно. Төрөл бүрийн тохируулгууд болон файлууд нь таны систем дээр байгаа OpenSSH-ийн хувилбаруудаас шалтгаалан өөр өөр байдаг; асуудалтай учрахгүйн тулд та &man.ssh-keygen.1; гарын авлагын хуудаснаас лавлах хэрэгтэй. ssh-agent болон ssh-add &man.ssh-agent.1; болон &man.ssh-add.1; хэрэгслүүд нь нэвтрэх үгнүүдийг дахин дахин бичүүлэлгүйгээр SSH түлхүүрүүдийг санах ойд дуудан ашиглаж болох аргуудаар хангадаг. &man.ssh-agent.1; хэрэгсэл нь түүн уруу дуудагдсан хувийн түлхүүр(үүд) ашиглан жинхэнэ эсэхийг шалгах танилтыг зохицуулна. &man.ssh-agent.1; нь өөр програмыг ачаалахад хэрэглэгдэх ёстой. Хамгийн хялбартаа энэ нь бүрхүүл эсвэл илүү дэвшилттэйгээр ашиглавал цонхны удирдагч ажиллуулж болох юм. &man.ssh-agent.1;-ийг бүрхүүлд ашиглахын тулд үүнийг эхлээд бүрхүүлтэй цуг нэмэлт өгөгдөл маягаар ажиллуулах шаардлагатай. Хоёрдугаарт хэн бэ гэдэг мэдээллийг (identity) &man.ssh-add.1;-г ажиллуулан нэмэх хэрэгтэй бөгөөд түүнд хувийн түлхүүрийн нэвтрэх үгнүүдийг өгөх хэрэгтэй. Эдгээр алхмууд хийгдсэний дараа хэрэглэгч харгалзах нийтийн түлхүүр суулгагдсан дурын хост уруу &man.ssh.1; хийж чадах болно. Жишээ нь: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; X11 дээр &man.ssh-agent.1; хэрэглэхийн тулд &man.ssh-agent.1;-ийн дуудлага ~/.xinitrc-д байх шаардлагатай. Ингэснээр X11-д ачаалагдсан бүх програмуудад &man.ssh-agent.1;-ийн үйлчилгээнүүдийг үзүүлэх болно. Жишээ ~/.xinitrc файл иймэрхүү харагдах болно: exec ssh-agent startxfce4 Энэ нь &man.ssh-agent.1;-ийг ажиллуулах бөгөөд тэр нь эргээд X11 эхлэх бүрт XFCE-ийг ажиллуулна. Ингэж хийгдсэний дараа өөрчлөлтүүд нь үйлчлэхийн тулд X11 дахин эхэлсний хойно өөрийн SSH түлхүүрүүдийг бүгдийг ачаалахын тулд ердөө л &man.ssh-add.1;-ийг ажиллуулаарай. SSH туннель хийх OpenSSH туннель хийх OpenSSH нь шифрлэгдсэн сессийн үед өөр протоколыг хайрцаглах туннель үүсгэх чадвартай байдаг. Дараах тушаал telnet-д зориулж туннель үүсгэхийг &man.ssh.1;-д хэлж өгнө: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; ssh тушаал дараах тохируулгуудтай хэрэглэгдэнэ: ssh-ийг протоколын 2-р хувилбарыг ашиглахыг зааж өгнө. (хэрэв та хуучин SSH серверүүдтэй ажиллаж байгаа бол үүнийг битгий ашиглаарай) Тушаал байхгүй эсвэл зөвхөн туннель гэдгийг заана. Хэрэв үүнийг орхивол ssh ердийн сесс эхлүүлнэ. ssh-ийг ард, далд ажиллуулахыг заана. Локал туннелийг localport:remotehost:remoteport загвараар зааж өгнө. Алсын SSH сервер. SSH туннель нь сонсох сокетийг localhost-ийн заагдсан порт дээр үүсгэн ажилладаг. Дараа нь локал хост/порт дээр хүлээн авсан дурын холболтыг SSH-ээр дамжуулан заасан алсын хост болон порт уруу илгээдэг. Жишээн дээр localhost дээрх 5023 порт нь алсын машины localhost дээрх 23 порт уруу дамжуулагдаж байна. 23 нь telnet учир энэ нь SSH туннелээр аюулгүй telnet сесс үүсгэнэ. SMTP, POP3, FTP гэх зэрэг ямар ч аюултай TCP протоколуудын гүйцэтгэлийг хялбаршуулахад үүнийг ашиглаж болно. SMTP-д зориулан SSH ашиглан аюулгүй туннель үүсгэх &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP Үүнийг &man.ssh-keygen.1; болон нэмэлт хэрэглэгчийн бүртгэлүүдтэй цуг илүү үл үзэгдэх/төвөггүй SSH туннель хийх орчин үүсгэхэд ашиглаж болно. Түлхүүрүүд нь нууц үг бичихийн оронд ашиглагдаж болох бөгөөд туннелиуд нь тусдаа хэрэглэгч маягаар ажиллаж чадна. SSH туннелийн практик жишээнүүд POP3 сервер уруу аюулгүй хандах Ажил дээр чинь гаднаас холболтууд хүлээн авах SSH сервер байна. Бас тэр оффисийн сүлжээнд POP3 сервер ажиллуулж байгаа захидлын сервер байна. Таны гэр болон оффисийн хоорондын сүлжээ болон сүлжээний зам итгэж болохоор эсвэл итгэж болохооргүй байж магадгүй юм. Ийм учраас та өөрийн захидлыг аюулгүй аргаар шалгах хэрэгтэй юм. Үүний шийдэл нь өөрийн оффисийн SSH сервер уруу SSH холболт үүсгэж захидлын сервер уруу туннель хийх явдал юм. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** Туннель эхлэн ажилласны дараа та өөрийн захидлын клиентийнхээ POP3 хүсэлтүүдийг localhost-ийн 2110 порт уруу илгээхээр зааж өгч болно. Эндэх холболт туннелээр аюулгүйгээр дамжин mail.example.com уруу илгээгдэнэ. Хэцүү галт ханыг тойрон гарах Зарим сүлжээний администраторууд хэтэрхий чанга галт ханын дүрэм ашиглан зөвхөн ирж байгаа холболтууд төдийгүй гарч байгаа холболтуудыг ч бас шүүдэг. Танд алсын машинуудад зөвхөн SSH болон вэбээр аялах 22 болон 80-р портуудад хандах боломжийг өгсөн байж болох юм. Та хөгжим цацдаг Ogg Vorbis сервер зэрэг өөр (магадгүй ажилдаа холбоогүй) үйлчилгээ уруу хандахыг магадгүй хүсэж болох юм. Хэрэв энэ Ogg Vorbis сервер нь 22 эсвэл 80-аас бусад өөр порт дээр цацаж байгаа бол та түүнд хандаж чадахгүй юм. Үүний шийдэл нь таны сүлжээний галт ханаас гаднах машин уруу SSH холболт үүсгэж үүнийг Ogg Vorbis сервер уруу туннель хийхэд ашиглах явдал юм. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* Таны урсгал хүлээн авах клиент одоо localhost-ийн 8888 порт уруу заагдах бөгөөд тэр цаашаагаа галт ханыг амжилттайгаар гэтлэн music.example.com уруу дамжуулагдана. <varname>AllowUsers</varname> хэрэглэгчийн тохируулга Ямар хэрэглэгчид хаанаас орохыг хязгаарлаж өгөх нь зүйтэй юм. AllowUsers тохируулга нь үүнд хүрэх сайн арга юм. Жишээ нь root хэрэглэгчийг зөвхөн 192.168.1.32-оос орохыг зөвшөөрөхийн тулд доор дурдсантай адил тохируулгыг /etc/ssh/sshd_config файлд хийх нь зүйтэй юм: AllowUsers root@192.168.1.32 admin хэрэглэгчийг хаанаас ч орохыг зөвшөөрөхийн тулд ердөө л хэрэглэгчийн нэрийг өөрийг нь жагсааж өгнө: AllowUsers admin Олон хэрэглэгчид нэг мөрөнд жагсаагдах шаардлагатай: AllowUsers root@192.168.1.32 admin Та энэ машин уруу нэвтрэх хэрэгцээтэй хэрэглэгч бүрийг жагсааж өгөх нь чухал юм, тэгэхгүй бол тэдгээр нь орж чадахгүй болно. /etc/ssh/sshd_config-д өөрчлөлтүүд хийснийхээ дараа &man.sshd.8;-д өөрийн тохиргооны файлуудыг дахин дуудахыг дараах тушаалыг ажиллуулж та хэлж өгөх ёстой: &prompt.root; /etc/rc.d/sshd reload Нэмэлт унших материалууд OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; Том Рөүдс Хавь нэмэр болгон оруулсан ACL Файлын системийн хандалт хянах жагсаалтууд Хормын хувилбарууд зэрэг файлын системийн өргөжүүлэлтүүдийн хамтаар FreeBSD 5.0 болон сүүлийн хувилбарууд Файлын системийн хандалт хянах жагсаалтуудын (ACL-ууд) аюулгүй байдлыг санал болгодог. Хандалт Хянах Жагсаалтууд нь стандарт &unix; зөвшөөрлийн загварыг маш нийцтэй (&posix;.1e) аргаар өргөтгөдөг. Энэ боломж нь администраторт илүү төвөгтэй аюулгүй байдлын загвар болон түүний давуу талыг ашиглахыг зөвшөөрдөг. UFS файлын системүүдэд ACL дэмжлэгийг идэвхжүүлэхийн тулд дараах: options UFS_ACL тохируулгыг цөмд эмхэтгэх шаардлагатай. Хэрэв энэ тохируулга эмхэтгэгдээгүй бол ACL-ууд дэмжих файлын системийг холбохыг оролдоход анхааруулах мэдэгдэл дэлгэцэд гардаг. Энэ тохируулга GENERIC цөмд орсон байдаг. ACL-ууд нь файлын систем дээр өргөтгөсөн шинж чанаруудыг идэвхжүүлсэн дээр тулгуурладаг. Өргөтгөсөн шинж чанарууд нь дараа үеийн &unix; файлын систем UFS2-д төрөлхийн дэмжигдсэн байдаг. UFS1 дээр өргөтгөсөн шинж чанаруудыг тохируулахад UFS2 дээр тохируулахтай харьцуулбал илүү удирдлагын зардал шаардлагатай байдаг. UFS2 дээрх өргөтгөсөн шинж чанаруудын ажиллагаа нь бас бодитойгоор илүү байдаг. Иймээс UFS2-г UFS1-ийн оронд хандалт хянах жагсаалтуудад ашиглахыг ерөнхийдөө зөвлөдөг. ACL-ууд нь /etc/fstab файлд нэмэгдэж өгч болох холбох үеийн удирдлагын тугаар идэвхтэй болдог. Файлын системийн толгой дахь супер блокийн ACL-ууд тугийг өөрчлөхийн тулд &man.tunefs.8;-ийг ашиглан шургуу замаар холбох үеийн тугийг автоматаар зааж өгч болно. Ерөнхийдөө хэд хэдэн шалтгааны улмаас супер блокийн тугийг ашиглах нь дээр байдаг: Холбх үеийн ACL-ууд туг дахин холболтоор өөрчлөгддөггүй (&man.mount.8; ), зөвхөн бүрэн гүйцэд &man.umount.8; хийгдэж шинэ &man.mount.8; хийгдсэний дараа болно. Энэ нь бас файлын системийг ашиглаж байх үед дарааллыг нь өөрчилж болохгүй гэсэн үг юм. fstab-д мөр байхгүй байсан ч гэсэн эсвэл төхөөрөмжүүдийн дараалал өөрчлөгдсөн ч гэсэн супер блокийн тугийг тохируулах нь файлын системийг үргэлж ACL-уудыг идэвхтэйгээр холбоход хүргэдэг. Энэ нь файлын системийг ACL-уудыг идэвхжүүлэлгүйгээр санамсаргүйгээр холбохоос хамгаалдаг бөгөөд ингэж санамсаргүй холбох нь ACL-уудыг буруугаар албадаж тэгснээр аюулгүй байдлын асуудлуудад хүргэж болох юм. Бид шинэ &man.mount.8; хийлгүйгээр туг идэвхжүүлдгийг зөвшөөрөхөөр ACL-уудын ажиллагааг өөрчилж болох юм, гэхдээ бид ACL-уудыг идэвхжүүлэлгүй санамсаргүйгээр холболт хийхийг болиулахыг хүсдэг бөгөөд учир нь хэрэв та ACL-уудыг идэвхжүүлээд дараа нь болиулаад өргөтгөсөн шинж чанаруудыг устгалгүйгээр дахин идэвхжүүлбэл та өөртөө нэлээн хэцүү асуудал учруулах зүйлийг хийх болно. Ерөнхийдөө та файлын систем дээр ACL-уудыг идэвхжүүлсний дараа файлын хамгаалалтууд нь системийн хэрэглэгчдэд зориулагдсан файлуудтай нийцгүй болж болох учир тэдгээрийг болиулж болохгүй бөгөөд ACL-уудыг дахин идэвхжүүлэх нь зөвшөөрлүүд нь өөрчлөгдсөн байж болох файлуудад өмнөх ACL-уудыг магадгүй дахин холбож өөр тааварлаж болшгүй ажиллагаанд хүргэж болох юм. ACL-ууд идэвхжүүлсэн файлын системүүд өөрсдийн зөвшөөрлийн тохируулгууд дээрээ + (нэмэх) тэмдэг үзэх үед харуулдаг. Жишээ нь: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html Энд бид directory1, directory2, болон directory3 сангууд бүгд ACL-ууд-ийн давуу талыг авч байгааг харж байна. public_html сан тэгэхгүй байна. <acronym>ACL</acronym>-уудыг ашиглах нь Файлын системийн ACL-уудыг &man.getfacl.1; хэрэгслээр харж болно. Жишээ нь test файл дээрх ACL тохируулгуудыг харахын тулд дараах тушаалыг ажиллуулах хэрэгтэй: &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- Энэ файлын ACL тохируулгуудыг өөрчлөхийн тулд &man.setfacl.1; хэрэгслийг ажиллуул. Ажиглаарай: &prompt.user; setfacl -k test туг нь тухайн үед тодорхойлогдсон бүх ACL-уудыг файл эсвэл файлын системээс арилгана. Илүү дээр арга бол ACL-уудыг ажиллуулахад шаардлагатай үндсэн талбаруудыг орхидог тугийг ашиглах явдал юм. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test Дээр дурдсан тушаал дээр тохируулга анхдагч ACL оруулгуудыг өөрчлөхөд хэрэглэгдсэн. Өмнөх тушаалаар устгагдсан болохоор урьдчилан тодорхойлсон оруулгууд байхгүй учир энэ нь анхдагч тохируулгуудыг сэргээж жагсаасан тохируулгуудаас зааж өгдөг. Хэрэв та систем дээр байхгүй хэрэглэгч эсвэл бүлэг нэмэх бол Invalid argument буюу Буруу нэмэлт өгөгдөл гэсэн алдаа stdout уруу хэвлэгдэнэ гэдгийг санаж байх хэрэгтэй. Том Рөүдс Хувь нэмэр болгон оруулсан Portaudit Гуравдагч талын аюулгүй байдлын асуудлуудыг монитор хийх нь Сүүлийн жилүүдэд эмзэг асуудлын үнэлгээ хэрхэн зохицуулагдаж байгаа тал дээр аюулгүй байдлын ертөнц олон сайжруулалт хийсэн. Одоогийн байгаа бүх л үйлдлийн системүүд дээр гуравдагч талын хэрэгслүүд суулгаж тохируулдгаас болж системийн халдлагын заналхийлэл ихэсдэг. Эмзэг асуудлын үнэлгээ нь аюулгүй байдлын түлхүүр хүчин зүйл бөгөөд &os; нь үндсэн системд зориулан зөвлөгөөнүүдийг гаргадаг боловч гуравдагч талын хэрэгслүүд бүрийн хувьд хийх нь &os; төслийн боломжоос гадуур юм. Мэдэгдэж байгаа асуудлуудыг администраторуудад анхааруулж гуравдагч талын эмзэг асуудлуудыг зөөлрүүлэх арга байдаг. &os;-д нэмэлтээр Portaudit гэгддэг хэрэгсэл зөвхөн энэ зорилгоор байдаг. ports-mgmt/portaudit порт нь &os;-ийн аюулгүй байдлын баг болон портуудын хөгжүүлэгчдийн шинэчилж ажиллагааг нь хангаж байдаг мэдээллийн баазаас мэдэгдэж байгаа аюулгүй байдлын асуудлуудыг шалгадаг. Portaudit-г ашиглаж эхлэхийн тулд Портуудын цуглуулгаас түүнийг суулгах хэрэгтэй: &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean Суулгах процессийн явцад өдөр бүрийн аюулгүй байдлыг шалгах ажиллагаанд Portaudit-н гаралтыг зөвшөөрч &man.periodic.8;-д зориулсан тохиргооны файлуудыг шинэчилдэг. Өдөр тутмын аюулгүй байдлыг шалгах ажиллагаа root-ийн захидлын бүртгэл уруу цахим захидал явуулж түүнийг уг хэрэглэгч уншсан эсэхийг баталгаажуулах хэрэгтэй. Өөр ямар ч илүү тохиргоо энд хэрэггүй. Суулгасны дараа администратор мэдээллийн баазыг шинэчлэх болон суулгасан багцуудад мэдэгдэж байгаа эмзэг асуудлуудыг үзэхдээ дараах тушаалыг ажиллуулна: &prompt.root; portaudit -Fda Мэдээллийн бааз &man.periodic.8; ажиллах үед автоматаар шинэчлэгддэг; иймээс дээрх тушаал заавал шаардлагагүй юм. Энэ нь зөвхөн дараах жишээнүүдэд шаардлагатай. Портуудын цуглуулгын хэсэг болгон суулгагдсан гуравдагч талын хэрэгслүүдийг ямар ч үед аудит хийхдээ администратор зөвхөн дараах тушаалыг ажиллуулах хэрэгтэй: &prompt.root; portaudit -a Portaudit эмзэг асуудалтай багцын хувьд доор дурдсантай адилыг гаргана: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. Үзүүлсэн URL уруу вэб хөтчийг чиглүүлж администратор асуудалтай байгаа эмзэг асуудлын талаар дэлгэрэнгүй мэдээллийг олж авч болно. Ийм мэдээлэл нь нөлөөлөх хувилбарууд болон &os;-ийн портын хувилбар, аюулгүй байдлын зөвлөгөөнүүд байж болох өөр бусад вэб сайтуудыг агуулж болох юм. Товчхондоо Portaudit нь хүчирхэг хэрэгсэл бөгөөд Portupgrade порттой цуг хэрэглэхэд маш ашигтай байдаг. Том Рөүдс Хувь нэмэр болгон оруулсан FreeBSD-ийн аюулгүй байдлын зөвлөгөөнүүд &os;-ийн аюулгүй байдлын зөвлөгөөнүүд Үйлдвэрлэлийн чанарыг хангасан үйлдлийн системүүдийн нэгэн адил &os; Аюулгүй байдлын зөвлөгөөнүүд гаргадаг. Эдгээр зөвлөгөөнүүд нь ихэвчлэн аюулгүй байдлын жагсаалтууд уруу илгээгддэг бөгөөд зөвхөн тохирох хувилбаруудад засвар хийгдсэний дараа Errata буюу алдааны хуудсанд тэмдэглэгддэг. Энэ хэсэгт зөвлөгөө гэж юу болох, түүнийг хэрхэн ойлгох болон системд засвар хийхдээ ямар арга хэмжээнүүдийг авах талаар тайлбарлах болно. Зөвлөгөө ямархуу харагдах вэ? &os;-ийн аюулгүй байдлын зөвлөгөөнүүд &a.security-notifications.name; захидлын жагсаалтаас авсан доорх зөвлөгөөтэй адил харагдах болно. ============================================================================= &os;-SA-XX:XX.UTIL Security Advisory The &os; Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person@EMAIL-ADDRESS Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) CVE Name: CVE-XXXX-XXXX For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References Topic буюу сэдэв талбар асуудал юу болохыг яг заасан байдаг. Энэ нь үндсэндээ тухайн үеийн аюулгүй байдлын зөвлөгөөний танилцуулга бөгөөд эмзэг асуудалтай цуг хэрэгслийг тэмдэглэдэг. The Category буюу зэрэглэл талбар нь хамаарч байгаа системийн хэсгийг хэлдэг бөгөөд core, contrib, эсвэл ports-ийн аль нэг байж болно. core зэрэглэл нь эмзэг асуудал &os; үйлдлийн системийн гол хэсэгт нөлөөлнө гэсэн үг юм. contrib зэрэглэл нь эмзэг асуудал sendmail зэрэг &os; төсөлд хувь нэмэр болгон оруулсан програм хангамжуудад нөлөөлнө гэсэн үг юм. Эцэст нь ports зэрэглэл нь эмзэг асуудал портуудын цуглуулганд ордог нэмэлт програм хангамжуудад нөлөөлөхийг харуулдаг. Module талбар нь бүрэлдэхүүн хэсгийн байрлалыг жишээ нь sys гэх зэргээр илэрхийлдэг. Энэ жишээн дээр sys модуль өртөхийг бид харж байгаа бөгөөд ийм учраас энэ эмзэг асуудал нь цөм дотор ашиглагдсан бүрэлдэхүүн хэсэгт нөлөөлөх юм. Announced буюу зарласан талбар нь аюулгүй байдлын зөвлөгөө хэвлэгдсэн эсвэл ертөнцөд зарлагдсан огноог заадаг. Энэ нь аюулгүй байдлын баг асуудал байгааг шалгаж үүний засвар &os;-ийн эх модны архивт итгэмжлэн оруулсныг тогтоосон гэсэн үг юм. Credits буюу талархал талбар нь эмзэг асуудлыг мэдэж тайлагнасан хувь хүн болон байгууллагыг зааж талархдаг. Affects буюу нөлөөлөх хувилбарын талбар нь энэ эмзэг асуудал нөлөөлөх &os;-ийн хувилбаруудыг тайлбарладаг. Цөмийн хувьд уг нөлөөлсөн файлууд дээр ажиллуулсан ident тушаалын үр дүнг зэрвэс харж хувилбарыг тодорхойлж болно. Портуудын хувьд /var/db/pkg санд портын нэрийн дараа хувилбарын дугаар байдаг. Хэрэв систем нь &os;-ийн CVS архивтай адил хамгийн сүүлийн хэлбэрт орж өдөр тутам дахин бүтээгдээгүй бол энэ нь нөлөөлөлд орсон хэвээр байх магадлалтай юм. Corrected буюу засварласан талбар нь огноо, цаг, цагийн бүс болон засварласан хувилбаруудыг заадаг. Common Vulnerabilities Database system буюу Нийтлэг Эмзэг асуудлуудын Мэдээллийн Баазын системээс эмзэг асуудлуудыг хайхад хэрэглэгдэх магадлалын мэдээлэлд нөөцлөгддөг. Background талбар нь нөлөөлөлд яг ямар хэрэгсэл орсон талаар мэдээлэл өгдөг. Ихэнхдээ энэ нь &os;-д яагаад тухайн хэрэгсэл байдаг, юунд хэрэглэгддэг болон хэрэгсэл хэрхэн бий болсон талаар байдаг. Problem Description буюу асуудлын тайлбар талбар нь аюулгүй байдлын цоорхойг гүнзгий тайлбарладаг. Энэ нь гажигтай кодын мэдээлэл эсвэл бүр хэрэгслийг хэрхэн хорлонтойгоор ашиглаж аюулгүй байдлын цоорхой нээдэг тухай мэдээллийг агуулдаг. Impact буюу үйлчлэл талбар нь асуудал системд ямар төрлийн үйлчлэл үзүүлдгийг тайлбарладаг. Жишээ нь энэ нь үйлчилгээг зогсоох халдлагаас авахуулаад хэрэглэгчдэд өгч болох нэмэлт зөвшөөрлүүд эсвэл халдагчид супер хэрэглэгчийн хандалт өгөх зэрэг юу ч байж болно. Workaround буюу тойрон гарах талбар нь боломжит тойрон гарах арга замыг системийг шинэчилж чадахгүй байж болох системийн администраторуудад олгодог. Энэ нь хугацааны шаардлагууд, сүлжээний боломж эсвэл өөр бусад олон шалтгаанаас болдог байж болох юм. Ямар ч байсан гэсэн аюулгүй байдлыг хөнгөнөөр авч үзэж болохгүй бөгөөд нөлөөлөлд орсон систем эсвэл засвар нөхөөс хийгдэх аль эсвэл аюулгүй байдлын цоорхойг тойрон гарах шийдэл хийгдэх шаардлагатай. Solution буюу шийдэл талбар нь нөлөөлөлд орсон системийг засварлах заавруудыг санал болгодог. Энэ нь системд засвар нөхөөс хийн аюулгүй ажиллуулах алхам алхмаар тест хийгдэж шалгагдсан арга юм. Correction Details буюу засварын нарийн учир талбар нь CVS салбар эсвэл хувилбарын нэрийн цэгүүдийг доогуур зураас тэмдэгтээр өөрчилж үзүүлдэг. Мөн энэ нь салбар болгон дахь нөлөөлөлд орсон файлуудын хувилбарын дугаарыг бас харуулдаг. References буюу лавлагаа талбар нь ихэвчлэн бусад мэдээллийн эхүүдийг өгдөг. Энэ нь вэбийн URL-ууд, номнууд, захидлын жагсаалтууд болон мэдээний бүлгүүдийг агуулж болно. Том Рөүдс Хувь нэмэр болгон оруулсан Процессийн бүртгэл хөтлөх Процессийн бүртгэл хөтлөх Процессийн бүртгэл хөтлөх аюулгүй байдлын аргыг ашиглаж администраторууд системийн эх үүсвэрүүдийг ашигласан байдал болон тэдгээрийг хэрэглэгчдэд хэрхэн хуваарилсныг мэдэж болох бөгөөд энэ нь системийг монитор хийх боломжийг олгодог. Мөн энэ арга нь хэрэглэгчдийн тушаалуудыг туйлын багаар мөшгих боломжийг администраторуудад олгодог. Энэ нь үнэн хэрэгтээ өөрийн эерэг болон сөрөг талуудтай. Эерэг талуудын нэг нь халдлагыг орсон цэг хүртэл нарийсган олох боломж юм. Сөрөг тал нь процессийн бүртгэл хөтлөлтөөр үүссэн бүртгэлүүд бөгөөд тэдгээр нь дискний зай шаардаж болох юм. Энэ хэсэг процессийн бүртгэл хөтлөлтийн үндсүүдийг администраторуудад таниулах болно. Процессийн бүртгэл хөтлөлтийг идэвхжүүлж хэрэглэх нь Процессийн бүртгэл хөтлөлтийг ашиглаж эхлэхээсээ өмнө үүнийг идэвхжүүлэх хэрэгтэй. Үүнийг хийхийн тулд дараах тушаалуудыг ажиллуул: &prompt.root; touch /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf Идэвхтэй болгосны дараа бүртгэл хөтлөлт CPU статистикууд, тушаалууд гэх мэтийг даган мөшгиж эхэлнэ. Бүртгэлийн бүх бичлэгүүд уншиж болохооргүй хэлбэрээр байдаг бөгөөд тэдгээрийг &man.sa.8; хэрэгсэл ашиглан үзэж болдог. Ямар нэг тохируулгагүйгээр ажиллуулбал sa тушаал нь хэрэглэгч болгоны дуудлагуудын тоо, нийт зарцуулсан хугацааг минутаар, нийт CPU болон хэрэглэгчийн хугацааг минутаар, дундаж I/O үйлдлүүдийн тоо гэх мэттэй холбоотой мэдээллийг дэлгэцэнд хэвлэн үзүүлдэг. Тушаалуудыг ашигласан тухай мэдээллийг харахын тулд &man.lastcomm.1; хэрэгслийг ашиглах хэрэгтэй. lastcomm тушаал нь тухайн &man.ttys.5; дээр хэрэглэгчдийн ажиллуулсан тушаалуудыг үзүүлэхэд хэрэглэгдэж болно, жишээ нь: &prompt.root; lastcomm ls trhodes ttyp1 Дээрх тушаал нь ttyp1 терминал дээр trhodes хэрэглэгчийн ls тушаал ашигласан мэдэгдэж байгаа бүгдийг дэлгэцэд харуулах болно. Өөр олон ашигтай тохируулгууд байдаг бөгөөд &man.lastcomm.1;, &man.acct.5; болон &man.sa.8; гарын авлагын хуудаснуудад тайлбарласан байдаг.