# pw lock staffБүлэг 15. Аюулгүй байдал
This translation may be out of date. To help with the translations please access the FreeBSD translations instance.
Table of Contents
15.1. Ерөнхий агуулга
Энэ бүлэг нь системийн аюулгүй байдлын ухагдахуунуудын үндэс, зарим нэг нийтлэг практикийн сайн аргууд болон FreeBSD дэх зарим нэг дэвшилттэй сэдвүүдийг танилцуулах болно. Энд дурдагдсан олон сэдвүүдийг бас системийн болон Интернэтийн аюулгүй байдалд хэрэглэж болох юм. Интернэт нь хүн бүр таны найрсаг хөрш байхыг хүсдэг "найзархаг" газар байхаа аль хэдийн больсон. Өөрийн системийг аюулгүй болгох нь таны өгөгдөл, оюуны өмч, цаг хугацаа зэрэг олон зүйлсийг хакерууд зэргийн савраас хамгаалахад хойшлуулашгүй чухал юм.
FreeBSD нь таны систем болон сүлжээний аюулгүй байдал болон бүрэн бүтэн байдлыг хангаж байдаг хэрэгслүүд болон арга замуудын цуглуулгыг агуулдаг.
Энэ бүлгийг уншсаны дараа, та дараах зүйлсийг мэдэх болно:
FreeBSD-ийн хувьд системийн аюулгүй байдлын үндсэн ухагдахуунууд.
FreeBSD-д байдаг DES болон MD5 зэрэг төрөл бүрийн нууцлах арга замуудын талаар.
Нэг удаагийн нууц үгийн нэвтрэлтийг хэрхэн тохируулах талаар.
TCP Wrappers буюу TCP Гүйцэтгэлийг хялбаршуулагчдыг inetd-д ашиглан хэрхэн тохируулах талаар.
FreeBSD дээр Kerberos5-г хэрхэн тохируулах талаар.
IPsec-г хэрхэн тохируулж FreeBSD/Windows® машинуудын хооронд VPN үүсгэх талаар.
FreeBSD-ийн SSH шийдэл болох OpenSSH-г хэрхэн тохируулж ашиглах талаар.
Файлын системийн ACL-үүд гэж юу болох, тэдгээрийг хэрхэн ашиглах талаар.
Portaudit хэрэгслийг хэрхэн ашиглаж Портын цуглуулгаас суулгагдсан гуравдагч програм хангамжийн багцуудыг аудит хийх талаар.
FreeBSD-ийн аюулгүй байдлын зөвлөмжүүдийн сонордуулгуудыг хэрхэн хэрэглэх талаар.
Процессийн Бүртгэл хөтлөх гэж юу болох талаар ойлголттой болж түүнийг FreeBSD дээр хэрхэн идэвхжүүлэх талаар.
Энэ бүлгийг уншихаасаа өмнө, та дараах зүйлсийг мэдэх шаардлагатай:
FreeBSD болон Интернэтийн үндсэн ухагдахуунуудыг ойлгох.
Энэ номонд нийтдээ аюулгүй байдлын нэмэлт сэдвүүд хамрагдсан болно. Жишээ нь Mandatory Access Control буюу Шаардлагатай Хандалтын Хяналт Mandatory Access Control буюу Албадмал Хандалтын хяналт-д, Интернэт галт ханануудын талаар Галт хана-д хэлэлцэгдсэн байгаа.
15.2. Танилцуулга
Аюулгүй байдал нь системийн администратораас эхэлж түүнтэй дуусдаг үйл ажиллагаа юм. BSD UNIX® олон хэрэглэгчийн системүүд нь угаасаа зарим нэг аюулгүй байдлыг хангаж байдаг боловч тэдгээр хэрэглэгчдийг "үнэнч" байлгахыг эрмэлздэг аюулгүй байдлын нэмэлт арга замуудыг бүтээж түүний ажиллагааг хангах ажил нь сисадмины магадгүй ганц, хамгийн том үүргүүдийн нэг юм. Таныг аюулгүй болгосон зөвхөн тэр хэмжээгээр машинууд нь аюулгүй байдаг бөгөөд аюулгүй байдлын санаа зовнилууд нь хүний ая тухтай хялбар байлгах гэсэн хэрэгцээтэй үргэлж тэмцэлдэж байдаг. Ерөнхийдөө UNIX® системүүд нь асар олон тооны зэрэгцээ процессуудыг ажиллуулах чадвартай бөгөөд эдгээр процессуудын ихэнх нь серверүүд болон ажилладаг - энэ нь гаднын зүйлс тэдэнтэй холбогдож ярилцах боломжтой гэсэн үг юм. Өчигдрийн миникомпьютерууд, мэйнфрэймүүдээс өнөөгийн ширээний компьютерууд болж компьютерууд нь сүлжээнд холбогдож сүлжээнүүд нь хоорондоо холбогдох тусам аюулгүй байдал нь улам илүү том асуудал болсоор байна.
Системийн аюулгүй байдал нь сүйрүүлэхийг оролдсон эсвэл системийг ашиглагдахааргүй болгох гэсэн, гэхдээ root бүртгэлийг буулган авах ("root-г эвдэх") оролдлого хийдэггүй, халдлагууд зэрэг төрөл бүрийн халдлагуудыг зогсоохтой бас хамааралтай юм. Аюулгүй байдлын санаа зовнилуудыг хэд хэдэн зэрэглэлд хувааж болно:
Үйлчилгээг зогсоох халдлагууд.
Хэрэглэгчийн бүртгэл буулган авалтууд.
Хандаж болох серверүүдээр дамжин root-г буулган авах.
Хэрэглэгчийн бүртгэлүүдээс дамжин root-г буулган авах.
Арын хаалга үүсгэлт.
Үйлчилгээг зогсоох халдлага нь машиныг хэрэгцээтэй эх үүсвэрээс нь салгах үйлдэл юм. Ихэвчлэн 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 хоёртын файлуудыг аюулгүй болгох.Хэрэглэгчийн бүртгэлүүдийг аюулгүй болгох.
Нууц үгийн файлыг аюулгүй болгох.
Цөмийн гол хэсэг, түүхий төхөөрөмжүүд болон файлын системүүдийг аюулгүй болгох.
Системд хийгдсэн зохисгүй өөрчлөлтүүдийг түргэн илрүүлэх.
Параной буюу хэт зовнил.
Энэ бүлгийн дараагийн хэсэг нь дээр дурдсан зүйлсүүдийг илүү гүнзгийгээр авч үзэх болно.
15.3. FreeBSD-н аюулгүй байдлыг хангах нь
Тушаалыг Протоколтой харьцуулахад (Command vs. Protocol) Энэ баримтын туршид бид тод текстээр програмыг |
Үүнээс хойшх хэсгүүд нь түрүүчийн бүлгийн сүүлийн хэсэгт дурдсан таны FreeBSD системийг аюулгүй болгох аргуудыг авч үзнэ.
15.3.1. root бүртгэл болон staff бүртгэлүүдийг аюулгүй болгох
Эхлээд хэрэв та root бүртгэлийг аюулгүй болгоогүй бол staff бүртгэлүүдийг аюулгүй болгоход санаа зовсны хэрэггүй. Ихэнх системүүд root бүртгэлд нууц үг өгсөн байдаг. Таны эхний хийх зүйл бол нууц үг үргэлж эвдэгдэж болно гэдгийг бодох хэрэгтэй. Энэ нь та нууц үгээ устгах хэрэгтэй гэсэн үг биш юм. Нууц үг нь машин уруу консол хандалт хийхэд үргэлж хэрэгтэй байдаг. Энэ нь юу гэсэн үг вэ гэхээр та нууц үгийг консолоос гадна эсвэл болж өгвөл бүр su(1) тушаалтай ашиглаж болохоор хийх ёсгүй гэсэн үг юм. Жишээ нь telnet эсвэл rlogin-р хийгдэх шууд root нэвтрэлтүүдийг хаах pty-уудын тохиргоог insecure буюу аюултай гэж /etc/ttys файлд заасан эсэхийг шалгаарай. Хэрэв бусад нэвтрэх үйлчилгээнүүд болох sshd зэргийг ашиглаж байгаа бол шууд root нэвтрэлтүүдийг бас хаасан эсэхийг шалгаарай. Та үүнийг /etc/ssh/sshd_config файлыг засварлан PermitRootLogin тохируулгыг no болгон зааж өгөөрэй. Хандах арга бүр - FTP зэрэг үйлчилгээнүүдээр ихэвчлэн эвдлэн ордог болохыг бодолцох хэрэгтэй. Шууд root нэвтрэлтүүд зөвхөн системийн консолоор хийгдэхэд зөвшөөрөгдөх ёстой.
Мэдээж систем админы хувьд та 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 уруу ksu(1) хийхийг зөвшөөрөх бас боломжтой байдаг. Энэ нь магадгүй давуу шийдэл байж болох юм. Учир нь хэрэв халдагч таны нууц үгийн файлыг олж аван staff бүртгэлийг эвдлэн орж чадах бол wheel арга нь халдагчид root-г эвдэх боломжийг олгосон хэвээр байдаг юм. wheel аргатай байх нь огт аргагүй байхаас илүү боловч энэ нь заавал ч үгүй хамгийн аюулгүй сонголт бас биш юм.
Бүртгэлийг бүрэн түгжихийн тулд pw(8) тушаалыг ашиглах хэрэгтэй:
Энэ нь 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 ашиглаж байгаа сайтууд эсвэл хэрэглэгч ssh(1) ашиглан түлхүүрүүд тохируулсан тохиолдлууд зэрэгт ажилладаггүй.
Эдгээр аюулгүй байдлын арга замууд нь бас таныг илүү хязгаарласан серверээс арай бага хязгаарласан машин уруу нэвтрэн орж байна гэж тооцдог. Жишээ нь хэрэв таны гол хайрцаг чинь бүх л төрлийн серверүүд ажиллуулж байвал таны ажлын компьютер чинь ямрыг ч ажиллуулах ёсгүй. Өөрийн компьютерийг боломжийн аюулгүй болгохын тулд та ерөөсөө сервергүй болтол аль болох цөөн сервер ажиллуулах хэрэгтэй бөгөөд та нууц үгээр хамгаалагдсан дэлгэц хоослогч ажиллуулах хэрэгтэй. Мэдээж ажлын компьютер уруу физик хандалт өгвөл халдагч ямар ч төрлийн аюулгүй байдлыг та хангасан байлаа гэсэн эвдэж чадна. Энэ нь таны бодох ёстой асуудлын нэг юм. Гэхдээ эвдлэн оролтуудын олонхи нь алсаас сүлжээгээр дамжин таны ажлын компьютер эсвэл серверүүдэд физик хандалт байхгүй хүмүүсээс ирдэг гэдгийг та бас л бодолцох хэрэгтэй юм.
Kereberos мэтийг ашиглах нь танд staff бүртгэлийн нууц үгийг нэг газар өөрчлөх эсвэл хаах боломжийг олгох бөгөөд staff-ийн гишүүдийн бүртгэл байж болох бүх машинууд дээр нэн даруй бас үйлчилдэг. Хэрэв staff-ийн гишүүний бүртгэл эвдэгдсэн бол түүний нууц үгийг бүх машинууд дээр нэн даруй өөрчлөх тэр боломжийг дутуу үнэлэх ёсгүй юм. Тусдаа байгаа нууц үгүүдийг N машинууд дээр өөрчлөх нь зовлонтой байдаг. Мөн та Kerberos-д нууц үг дахин өгөлтийг ноогдуулж болох бөгөөд Kerberos тасалбарыг хэсэг хугацааны дараа дуусдагаар хийж болохоос гадна Kerberos систем нь тодорхой хугацааны (жишээ нь сар бүр) дараа хэрэглэгчийг шинэ нууц үг сонгохыг шаарддагаар бас тохируулж болдог.
15.3.2. root-ажилладаг серверүүд болон suid/sgid хоёртын файлуудыг аюулгүй болгох
Хянамгай сисадмин илүү ч үгүй дутуу ч үгүй зөвхөн өөрийн хэрэгтэй серверүүдийг ажиллуулдаг. Гуравдагч талын серверүүд ихэвчлэн хамгийн алдаатай байх хандлагатай гэдгийг санаж байх хэрэгтэй. Жишээ нь imapd эсвэл popper серверийн хуучин хувилбарыг ажиллуулна гэдэг нь универсал root тасалбарыг бүх дэлхийд өгч байна гэсэн үг юм. Та няхуур шалгаагүй сервер битгий ажиллуул. Олон серверүүд заавал root эрхээр ажиллах шаардлагагүй байдаг. Жишээ нь ntalk, comsat, болон finger дэмонуудыг тусгай хэрэглэгчийн sandboxes буюу хамгаалагдсан хязгаарлагдмал орчинд ажиллуулах боломжтой байдаг. Хамгаалагдсан хязгаарлагдмал орчин нь асар их төвгүүдийг давж хийгээгүй л бол төгс биш бөгөөд өмнө дурдсан сонгины хандлагаар аюулгүй байдалд хандах нь хэвээр байна: хэрэв хэн нэгэн нь хамгаалагдсан хязгаарлагдмал орчинд ажиллаж байгаа серверт эвдэн орж чадсан ч гэсэн тэд хамгаалагдсан хязгаарлагдмал орчныг бас эвдэн гарах хэрэг болно. Аль болох олон давхаргыг халдагч эвдлэх ёстой болох тусам тэдгээрийн амжилттай болох нь улам багасах болно. Урьд нь root цоорхойнууд нь системийн үндсэн серверүүдээс авахуулаад бараг л бүх root ажилладаг сервер дээр олдож байсан. Хэрэв таны ажиллуулдаг машин уруу хүмүүс зөвхөн sshd ашиглан нэвтэрдэг бөгөөд telnetd, rshd эсвэл rlogind хэзээ ч ашиглан нэвтэрдэггүй бол эдгээр үйлчилгээнүүдийг хаагаарай!
Одоо FreeBSD нь ntalkd, comsat, болон finger үйлчилгээнүүдийг хамгаалагдсан хязгаарлагдмал орчинд анхдагчаар ажиллуулдаг. Хамгаалагдсан хязгаарлагдмал орчинд ажиллуулж болох өөр нэг програм нь named(8) юм. /etc/defaults/rc.conf нь named-г хамгаалагдсан хязгаарлагдмал орчинд ажиллуулахад шаардлагатай нэмэлт өгөгдлүүдийг тайлбар хэлбэрээр агуулсан байдаг. Таны шинэ систем эсвэл байгаа системээ шинэчилж байгаагаас хамааран тэдгээр хамгаалагдсан хязгаарлагдмал орчинд ашиглагдах тусгай хэрэглэгчийн бүртгэлүүд суулгагдаагүй байж болох юм. Хянамгай сисадмин судалгаа хийж серверүүдийг хамгаалагдсан хязгаарлагдмал орчинд аль болох ажиллуулдаг.
Хамгаалагдсан хязгаарлагдмал орчинд ерөнхийдөө ажилладаггүй хэд хэдэн серверүүд байдаг: 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-д бичиж чадна. Хэрэв хэрэглэгч гар дуурайх боломж бүхий терминал програм эсвэл эмулятор ажиллуулж байгаа бол хэрэглэгчийн терминалыг тушаал буцаан харуулахаар болгодог өгөгдлийн урсгалыг халдагч үүсгэж дараа нь тэр тушаалыг тэр хэрэглэгчийн эрхээр ажиллуулдаг.
15.3.3. Хэрэглэгчийн бүртгэлүүдийг аюулгүй болгох
Хэрэглэгчийн бүртгэлүүдийг аюулгүй болгох нь ихэвчлэн хамгийн хэцүү байдаг. Та өөрийн staff-д ширүүн хандалтын хязгаарлалтууд оногдуулж тэдгээрийн нууц үгүүдийг "од болгож" болох боловч та ердийн хэрэглэгчийн бүртгэлүүдийг яг ингэж хязгаарлаж чадахгүй байж болох юм. Хэрэв та хангалттай хяналттай байх юм бол таны аз болж хэрэглэгчийн бүртгэлүүдийг зөвөөр аюулгүй болгож чадна. Хэрэв үгүй бол та тэдгээр бүртгэлүүдийг хянахдаа ердөө л илүү сонор сэрэмжтэй байх хэрэгтэй. ssh болон Kerberos-г хэрэглэгчийн бүртгэлүүдэд ашиглах нь нэмэлт удирдлага болон техникийн дэмжлэг шаардлагатайгаас болоод илүү асуудалтай байдаг боловч энэ нь шифрлэсэн нууц үгийн файлыг бодох юм бол маш сайн шийдэл хэвээр байдаг.
15.3.4. Нууц үгийн файлыг аюулгүй болгох
Цорын ганц итгэлтэй арга бол аль болох олон нууц үгүүдийг од болгон тэдгээр бүртгэлүүдэд хандахын тулд ssh эсвэл Kerberos ашигла. Шифрлэгдсэн нууц үгийн файлыг (/etc/spwd.db) зөвхөн root уншиж чаддаг боловч халдагч root-бичих хандалт олж авч чадаагүй ч гэсэн тэр файлд унших эрх олж авах боломжтой байж болох юм.
Таны аюулгүй байдлын скриптүүд нууц үгийн файлд хийгдсэн өөрчлөлтүүдийг үргэлж шалгаж тайлагнах шаардлагатай (доорх Файлын бүрэн бүтэн байдлыг шалгах хэсгийг үзнэ үү).
15.3.5. Цөмийн гол хэсэг, түүхий төхөөрөмжүүд болон файлын системүүдийг аюулгүй болгох
Хэрэв халдагч root-г эвдсэн бол тэр юуг ч хийж чадах боловч зарим ашиг сонирхлууд байдаг. Жишээ нь орчин үеийн ихэнх цөмүүдэд пакет шиншлэх төхөөрөмжийн драйвер бүтээгдсэн байдаг. FreeBSD-д энэ нь bpf төхөөрөмж гэж нэрлэгддэг. Халдагч ердөө буулган авсан машин дээрээ пакет шиншлэгчийг ажиллуулахыг оролддог. Та халдагчид энэ боломжийг өгөх хэрэггүй бөгөөд ихэнх системүүдэд bpf төхөөрөмжийг эмхэтгэн оруулах шаардлагагүй юм.
Гэхдээ bpf төхөөрөмжийг хаасан ч гэсэн та /dev/mem болон /dev/kmem файлуудад бас санаа тавих хэрэгтэй. Энэнээс болоод халдагч түүхий (raw) төхөөрөмжүүдэд бичиж чадсан хэвээр байна. Мөн цөмийн бас нэг боломж болох модуль ачаалагч гэж нэрлэгддэг kldload(8) байдаг. Самбаатай халдагч KLD модуль ашиглаад өөрийн bpf төхөөрөмж эсвэл бусад шиншлэх төхөөрөмжийг ажиллаж байгаа цөмд суулгадаг. Эдгээр асуудлуудаас зайлсхийхийн тулд та цөмийг илүү өндөр аюулгүй байдлын түвшинд ядаж аюулгүйн түвшин 1-д ажиллуулах хэрэгтэй.
Цөмийн аюулгүй байдлын түвшинг янз бүрийн аргаар тохируулж болно. Ажиллаж байгаа цөмийн аюулгүй байдлын түвшинг нэмэгдүүлэх хялбар алга бол цөмийн kern.securelevel хувьсагчийг sysctl ашиглан өөрчлөх явдал юм:
# sysctl kern.securelevel=1Анхдагчаар FreeBSD цөм аюулгүй байдлын -1 түвшинтэй ачаалдаг. Аюулгүй байдлын түвшинг администратор эсвэл эхлүүлэх скриптүүд дэх тохиргооноос болоод init(8)-ээр өөрчлөөгүй л бол -1 хэвээр байх болно. /etc/rc.conf файлд kern_securelevel_enable хувьсагчийг YES ба kern_securelevel хувьсагчийн утгыг аюулгүй байдлын хүссэн түвшин рүүгээ болгон тохируулж системийг эхлүүлэх үед аюулгүй байдлын түвшинг нэмэгдүүлж болно.
Эхлүүлэх скриптүүд дөнгөж дуусаад байх үед FreeBSD системийн аюулгүй байдлын анхдагч түвшин -1 байдаг. Үүнийг "insecure mode" буюу "аюулгүй байдлыг хангаагүй горим" гэдэг бөгөөд учир нь хувиршгүй байлын тугуудыг болиулах, бүх төхөөрөмжөөс уншиж эсвэл тэдгээр рүү бичих гэх зэргийг хориогүй байдаг.
Аюулгүй байдлын түвшинг 1 эсвэл илүү өндөр утгаар тохируулсны дараа зөвхөн нэмэх болон хувиршгүй файлууд идэвхжиж тэдгээрийг болиулах боломжгүй болон түүхийн төхөөрөмжүүдэд хандахыг хориглодог. Илүү өндөр түвшингүүд бүр илүү олон үйлдлүүдийг хязгаарладаг. Төрөл бүрийн аюулгүй байдлын түвшнүүдийн үйлчилгээний талаарх дэлгэрэнгүй тайлбарыг security(7) гарын авлагын хуудсыг уншина уу.
Аюулгүйн түвшинг 1 эсвэл илүү өндөр түвшнээр дээшлүүлэх нь X11 (/dev/io руу хандах хандалт хаалттай байна) эсвэл FreeBSD-ийн бүтээлтийг эхээс суулгах (процессын |
Хэрэв цөмийн аюулгүйн түвшин 1 эсвэл түүнээс илүү утгаар дээшлүүлэгдсэн бол schg тугийг чухал эхлүүлэх хоёртын файлууд, сангууд болон скрипт файлууд (өөрөөр хэлбэл аюулгүйн түвшин тохируулагдах хүртэлх ажиллах бүх файлууд) дээр тохируулах нь ашигтай байж болох юм. Энэ нь хэтэрхий хийгдэж байж болох бөгөөд аюулгүйн өндөр түвшинд ажиллаж байхад системийг шинэчлэх үйл явцыг илүү хэцүү болгодог. Арай бага хязгаарлалттай өөр нэг боломж нь системийг илүү өндөр аюулгүйн түвшинд ажиллуулж гэхдээ schg тугийг системийн файл болон сан бүр дээр тохируулахгүй байх явдал юм. Өөр нэг боломж нь / болон /usr санг зөвхөн уншигдахаар холбох явдал юм. Юу зөвшөөрөгдсөн байх дээр хэтэрхий чанга байх нь халдлага илрүүлэлтийн бүх чухал зүйлсийг хязгаарлаж болох юм.
15.3.6. Файлын бүрэн бүтэн байдлыг шалгах нь: Хоёртын файлууд, Тохиргооны файлууд, гэх мэт.
Тэр мөч ирэхэд, та зөвхөн системийн гол тохиргоо болон хяналтын файлуудаа ая тухын хүчин зүйл урьтахаас хамаагүй өмнө хамгаалж чадна. Жишээ нь chflags тушаал ашиглан / болон /usr сангууд дахь ихэнх файлуудад schg битийг тохируулах нь магадгүй үр ашиггүй байж болох бөгөөд учир нь ингэснээр файлуудыг хамгаалахын хажуугаар бас илрүүлэх цонхыг хаадаг юм. Таны аюулгүй байдлын сонгины сүүлийн давхарга нь илрүүлэлт бөгөөд энэ нь хамгийн чухал юм. Хэрэв та боломжит халдагчдыг илрүүлж чадахгүй л бол аюулгүй байдлын бусад үлдсэн асуудлуудын талаар бодоод ч бараг хэрэггүй юм (эсвэл бүр дэмий юм, аюулгүй байдлыг танд буруу ойлгуулахад хүргэдэг). Сонгины ажлын хагас нь халдагчийг үйлдэл дээр нь барихын тулд түүнийг зогсоохын оронд харин удаашруулах явдал юм.
Халдлагыг илрүүлэх хамгийн сайн арга бол өөрчлөгдсөн, алга болсон, эсвэл гэнэтийн файлуудыг хайх явдал юм. Өөрчлөгдсөн файлуудыг хайх хамгийн сайн арга бол тэдгээрийг өөр (ихэвчлэн төвлөрсөн) хязгаарлагдмал хандалттай системээс хайх явдал юм. Өөрийн аюулгүй байдлын скриптийг нэмэлт аюулгүй байдал хангасан хязгаарлагдмал хандалттай систем дээр бичих нь тэдгээрийг боломжит халдагчдад бараг харагдуулдаггүй бөгөөд энэ нь чухал юм. Давуу талыг хамгийн ихээр авахын тулд ерөнхийдөө хязгаарлагдмал хандалттай хайрцагт бусад машинуудад хандах тэр ач холбогдолтой хандалтыг өгөх хэрэгтэй. Үүнийг ихэвчлэн бусад машинуудын зөвхөн унших NFS экспортыг хязгаарлагдмал хандалттай хайрцагт өгөх эсвэл ssh түлхүүр хослолыг тохируулж хязгаарлагдмал хандалттай хайрцгийг бусад машинууд уруу ssh хийхийг зөвшөөрөх замаар хийдэг. Өөрийн сүлжээний урсгалыг тооцохгүй юм бол NFS нь хамгийн харагддаггүй арга юм - энэ нь клиент хайрцаг бүр дэх файлын системүүдийг монитор хийхийг танд зөвшөөрч бараг л илэрдэггүй. Хэрэв таны хязгаарлагдмал хандалттай сервер нь клиент хайрцагнууд уруу hub буюу салаалагч эсвэл чиглүүлэлтийн хэд хэдэн давхаргаар дамжин холбогдсон бол NFS арга нь хэтэрхий аюултай (сүлжээний хувьд) байж болох бөгөөд ssh-ийг ашиглах нь түүний гаргадаг аудит мөрийн замуудтай байсан ч гэсэн магадгүй илүү сонголт байж болох юм.
Монитор хийгдэх клиент систем уруу хандахад хамгийн багаар бодоход унших эрхийг та хязгаарлагдмал хандалттай хайрцагт өгсний дараа яг мониторыг хийхдээ скрипт бичих хэрэгтэй. Өгөгдсөн NFS холболтод find(1) болон 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 нь таны хайж байгаа тэр тохируулга юм. Энэ давхаргын зорилго нь эвдлэн оролтын оролдлогуудыг амжилттай эсвэл амжилтгүй болсноос үл хамааран илрүүлэх явдал учраас ямар ч гэсэн ядаж долоо хоногт нэг удаа та тэдгээр файлуудыг магадгүй шалгаж байх хэрэгтэй юм.
Процессийн бүртгэл хийх нь (accton(8)-г үзнэ үү) эвдлэн оролтын дараах үнэлэх арга замууд болон тусалж болох харьцангуй бага ачаалал бүхий үйлдлийн системийн боломж юм. Энэ нь эвдлэн орсны дараа файлыг хөндөөгүй хэвээр гэж үзэн халдагч систем уруу хэрхэн эвдлэн орсныг мөрдөхөд ялангуяа ашигтай байдаг.
Эцэст нь аюулгүй байдлын скриптүүд нь бүртгэлийн файлуудыг процесс хийх ёстой бөгөөд бүртгэлүүд өөрсдөө аль болох аюулгүй байдлаар үүсгэгдэх ёстой бөгөөд алсын syslog нь их ашигтай байж болох юм. Халдагч өөрийн мөрийг арилгахыг оролдох бөгөөд эхний эвдлэн оролтын арга болон хугацааг мөрдөхөд сисадмины хувьд бүртгэлийн файлууд нь маш чухал байдаг юм. Бүртгэлийн файлуудын байнгын бичлэгийг хадгалах нэг арга нь системийн консолыг сериал порт уруу ажиллуулж консолуудыг хянаж аюулгүй машин дээр мэдээллийг цуглуулах явдал юм.
15.3.7. Параной буюу хэт зовнил
Бага зэргийн хэт зовнил буруудахгүй. Дүрэм болгож тав тухтай байдлыг алдагдуулдаггүй дурын тооны аюулгүй байдлын боломжуудыг сисадмин нэмж болох бөгөөд зарим анхаарлыг бодолцон тав тухтай байдалд нөлөөлөх аюулгүй байдлын боломжуудыг бас нэмж болох юм. Бүр илүү чухал нь аюулгүй байдлын администратор үүнийг бага зэрэг хольж хэрэглэж болно - хэрэв та энэ баримтад дурдсан заавруудыг үгчлэн ашиглавал энэ баримтыг уншсан ирээдүйн халдагчид та өөрийн арга замуудыг заан өгч байна гэсэн үг юм.
15.3.8. Үйлчилгээг Зогсоох Халдлагууд
Энэ хэсэг нь Үйлчилгээг Зогсоох халдлагуудыг хамарна. DoS халдлага нь ихэвчлэн пакетийн халдлага байдаг. Таны сүлжээг дүүргэж байгаа орчин үеийн хууран мэхэлсэн пакетийн халдлагуудын эсрэг нэг их юм хийж чадахгүй ч гэсэн халдлагууд таны серверүүдийг унагахгүйн тулд та ерөнхийдөө хохирлыг хязгаарлаж болно:
Серверийн fork хийлтийг хязгаарлах.
Springboard буюу бусад халдлагуудыг хязгаарлах (ICMP хариу халдлагууд, ping цацалт, гэх мэт.).
Цөмийн чиглүүлэлтийн кэшийг хэт ачаалах.
Нийтлэг DoS халдлагын дүр зураг бол fork хийгдэж байгаа серверт халдаж түүнээр асар их хүүхэд процесс үүсгүүлж эцсийн эцэст хост системийн хувьд санах ой, файлын тодорхойлогчууд гэх мэтүүд дуусч зогсоход хүргэдэг. inetd (inetd(8)-г үзнэ үү) нь энэ төрлийн халдлагыг хязгаарлах хэд хэдэн тохируулгатай. Машиныг зогсоохоос хамгаалах боломжтой боловч ерөнхийдөө үйлчилгээг халдлагад өртүүлэхгүй байх боломжгүйг энд тэмдэглэх нь зүйтэй юм. inetd гарын авлагын хуудсыг анхааралтай уншиж -c, -C, болон -R тохируулгуудад ялангуяа анхаарлаа хандуулаарай. Хууран мэхэлсэн IP халдлагууд нь inetd дахь -C тохируулгыг хуурах учраас ихэвчлэн тохируулгуудын хослолыг ашиглах шаардлагатай. Зарим дан серверүүд өөрийн fork хийгдэхийг хязгаарлах параметрүүдтэй байдаг.
Sendmail нь -OMaxDaemonChildren тохируулгатай байдаг бөгөөд энэ нь Sendmail-ийг ачаалал хязгаарлах тохируулгатай ажиллуулж ачааллын хоцрогдол үүсгэснээс хавьгүй илүүтэйгээр ажилладаг. Та Sendmail-г ажиллуулахдаа хүссэн ачааллыг даахаар гэхдээ компьютерийг унагахаар их хэмжээний тоогоор Sendmail-үүдийг ажиллуулах биш түүнээс багаар MaxDaemonChildren параметрийг хангалттай өндрөөр тавьж өгөх хэрэгтэй. Мөн sendmail-ийг дарааллын горимоор (-ODeliveryMode=queued) ажиллуулах болон дэмонг (sendmail -bd) дараалалтай (sendmail -q15m) ажиллуулдгаас тусад нь ажиллуулах нь чухал юм. Хэрэв та шууд илгээх горимыг хүсэж байгаа бол та дарааллыг -q1m зэргээр бүр бага интервалаар ажиллуулах боломжтой боловч MaxDaemonChildren тохируулгыг боломжийн утгаар хоорондоо холбоотой амжилтгүйтлүүдээс sendmail-ийг хамгаалахын тулд зааж өгсөн эсэхээ шалгаарай.
Syslogd-д шууд халдаж болох учраас аль болох -s тохируулгыг эсвэл -a тохируулгыг ашиглахыг танд зөвлөдөг.
Шууд халдлага хийгдэж болох TCP Wrapper-ийн буцах identd зэрэг буцан холбогддог үйлчилгээнүүдийн хувьд та маш хянамгай байх хэрэгтэй. Ийм учраас та TCP Wrapper-ийн буцах identd боломжийг ерөнхийдөө ашиглах хэрэггүй юм.
Та өөрийн захын чиглүүлэгчүүд дээрээ дотоод үйлчилгээнүүд уруугаа гаднаас хандуулахгүй болгож галт ханаар хамгаалах нь зүйтэй юм. Үүний цаадах санаа нь гаднаас ирж болзошгүй сүлжээ дүүргэх халдлагаас өөрийн LAN-г хамгаалах явдал бөгөөд сүлжээн дээр тулгуурласан root эрхийг буулгахаас дотоод үйлчилгээнүүдийг хамгаалах зүйлс тийм их биш юм. exclusive буюу хамааруулаагүй галт ханыг үргэлж тохируулах хэрэгтэй, өөрөөр хэлбэл "A, B, C, D болон M-Z портуудаас бусад бүгдийг галт ханаар хамгаалах хэрэгтэй". Ингэснээр та named (хэрэв та бүсийн хувьд анхдагч бол), ntalkd, sendmail болон бусад Интернэтээс хандах үйлчилгээнүүд зэрэг зарим нэг тусгай үйлчилгээнүүдийн портуудаас бусад бүх бага дугаарын портуудыг галт ханаар хамгаалж чадах юм. Хэрэв та галт ханыг өөр аргаар - inclusive буюу хамааруулсан эсвэл зөвшөөрсөн галт хана маягаар тохируулахыг оролдвол хэд хэдэн үйлчилгээнүүдийг "хаахаа" мартаж магадгүй юм, эсвэл та шинэ дотоод үйлчилгээ нэмээд галт ханаа шинэчлэхээ мартаж болох юм. Та галт хана дээр зөвшөөрсөнтэй адил үйлдлийг нэвтрүүлэхийн тулд бага дугаарын портуудыг нээлгүйгээр өндөр дугаарын портуудыг онгойлгож болох юм. Мөн FreeBSD нь динамик холболтод хэрэглэгддэг портуудыг 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 эсвэл илүү хурдаар холбогдсон бол sysctl(8)-оор rtexpire болон rtminexpire хувьсагчуудыг хоёуланг гараар дарж бичихдээ хянамгай байх хэрэгтэй. Аль ч параметрийг (машиныг сүйрүүлэхийг та хүсээгүй л бол) хэзээ ч битгий 0 болгоорой. Эдгээр параметрүүдийг хоёуланг нь 2 секунд болгох нь чиглүүлэлтийн хүснэгтийг халдлагаас хамгаалахад хангалттай байх ёстой.
15.3.9. Kerberos болон SSH-тэй холбоотой хандалтын асуудлууд
Хэрэв та Kerberos болон ssh-г хоёуланг ашиглахаар бол цөөн хэдэн асуудлуудыг дурдах хэрэгтэй. Kerberos 5 нь жинхэнийг шалгах маш сайн нэвтрэлтийн протокол боловч түүнийг ашигласан telnet болон rlogin-д байдаг алдаанууд нь энэ хоёр програмыг хоёртын урсгалтай ажиллахад тохиромжгүй болгодог. Мөн -x тохируулгыг ашиглахгүй л бол анхдагчаар Kerberos нь сессийг шифрлэдэггүй. ssh нь бүгдийг шифрлэдэг.
Ssh нь анхдагчаар шифрлэсэн түлхүүрүүдээ дамжуулдгаас бусад бүх л талаараа зэгсэн сайн ажилладаг. Энэ нь юу гэсэн үг вэ гэхээр та хэрэв системийн бусад хэсэгт хандах боломж олгодог түлхүүрүүд бүхий аюулгүй ажлын компьютертай бөгөөд та аюултай машин уруу ssh хийвэл таны түлхүүрүүд ашиглагдах боломжтой гэсэн үг юм. Яг түлхүүрүүд нь өөрсдөө ил гардаггүй боловч ssh нь таны нэвтэрсэн хугацааны туршид зориулж дамжуулах порт суулгадаг бөгөөд хэрэв халдагч аюулгүй машин дээрх root-г эвдсэн бол тэрхүү портыг таны түлхүүрүүдийг ашиглахын тулд хэрэглэн таны түлхүүрээр тайлагдах өөр бусад машинуудад хандах боломжийг олж авах боломжтой юм.
Бид staff нэвтрэлтүүдийн хувьд аль болох ssh-г Kerberos-той цуг ашиглахыг зөвлөдөг. Ssh нь Kerberos-ийн дэмжлэгтэй эмхэтгэгдэж болдог. Энэ нь ил гарсан байж болзошгүй ssh түлхүүрүүдэд найдах таны найдварыг багасгахын хамт нууц үгүүдийг Kerberos-оор хамгаалдаг. Ssh түлхүүрүүд нь аюулгүй машинуудын автоматчилагдсан ажлуудад (Kerberos-оор хийхэд таарахгүй) зөвхөн хэрэглэгдэх ёстой. Мөн бид таныг ssh-ийн тохиргоондоо key-forwarding буюу түлхүүр дамжуулалтыг болиулах эсвэл ssh-ийн authorized_keys файлдаа зөвхөн тусгайлсан машинуудаас нэвтрэхэд түлхүүрийг ашиглаж болохоор болгож зөвшөөрдөг from=IP/DOMAIN тохируулгыг ашиглахыг зөвлөдөг.
15.4. DES, Blowfish, MD5, SHA256, SHA512 болон Crypt
UNIX® систем дээрх хэрэглэгч бүрийн хувьд нууц үг бүртгэлтэй нь холбоотой байдаг. Мэдээж эдгээр нууц үгүүд нь зөвхөн хэрэглэгч ба үйлдлийн системд мэдэгдэж байх ёстой. Эдгээр нууц үгүүдийг нууцлаг байлгахын тулд тэдгээрийг "one-way hash буюу үл буцах хэш" гэгддэг шифрлэхэд амархан боловч буцааж болдоггүй аргаар шифрлэдэг. Өөрөөр хэлбэл хормын өмнө мэдээж гэж хэлсэн бидний хэлсэн үг яг жинхэнэдээ үнэн биш юм: үйлдлийн систем өөрөө нууц үгийг жинхэнэдээ мэддэггүй. Энэ нь зөвхөн нууц үгийн шифрлэсэн хэлбэрийг мэддэг. "plain-text буюу ердийн уншигдах текст " хэлбэрийн нууц үгийг авах цорын ганц арга нь боломжит нууц үгүүдийн орон зайгаас балмадаар хүчлэн хайх явдал юм.
Харамсалтай нь UNIX® бий болсон тэр үед нууц үгийг аюулгүй аргаар шифрлэх цорын ганц арга нь DES, Data Encryption Standard буюу Өгөгдөл Шифрлэх Стандарт дээр үндэслэсэн байлаа. Энэ нь АНУ-д оршин сууж байсан хэрэглэгчдийн хувьд тийм ч асуудалтай биш байсан юм, гэхдээ DES-ийн эх код АНУ-аас гадагшаа экспорт хийгдэж болохгүй байсан учир FreeBSD нь АНУ-ын хуулийг дагахын хажуугаар DES-ийг ашигласан хэвээр байсан бусад бүх UNIX® төрлүүдтэй нийцтэй байх арга замыг хайж олоход хүрсэн юм.
Үүний шийдэл нь АНУ-ын хэрэглэгчид DES сангуудыг суулгаж ашиглах боломжтой мөртлөө олон улсын хэрэглэгчид гадагш экспорт хийгдэж болох шифрлэх аргатай бас байхаар шифрийн сангуудыг хуваасан явдал байлаа. Ингэж FreeBSD нь MD5-ийг өөрийн анхдагч шифрлэх аргаа болгон ашиглах болсон юм. MD5 нь DES-ээс илүү аюулгүй нууцлаг гэгддэг бөгөөд DES-ийг суулгах нь үндсэндээ нийцтэй байх шалтгаануудын улмаас зориулагдсан юм.
15.4.1. Өөрийн Crypt арга замыг таних нь
Одоогоор шифрийн сан DES, MD5, Blowfish, SHA256 болон SHA512 хэш функцуудыг дэмждэг. Анхдагчаар FreeBSD нь MD5 ашиглан нууц үгүүдийг шифрлэдэг.
FreeBSD аль шифрлэх аргыг тохируулж ашиглаж байгааг мэдэх хялбар байдаг. /etc/master.passwd файл дахь шифрлэсэн нууц үгийг шалгах нь нэг арга юм. MD5 хэшээр шифрлэгдсэн нууц үгүүд нь DES-р шифрлэгдсэнийгээ бодох юм бол урт бөгөөд $1$ тэмдэгтээр бас эхэлдэг. $2a$ тэмдэгтээр эхэлсэн нууц үгүүд Blowfish хэш функцаар шифрлэгдсэн байдаг. DES мөр нь ямар нэг тусгайлан таньж болох шинж тэмдэггүй байдаг боловч тэд MD5 нууц үгүүдээс богино бөгөөд $ тэмдэгт ордоггүй 64 тэмдэгттэй цагаан толгойгоор кодчилогддог, тиймээс долларын тэмдэгтээр эхлээгүй харьцангуй богино мөр ихэвчлэн DES нууц үг байдаг. SHA256 болон SHA512 нь $6$ тэмдэгтээр эхэлдэг.
Шинэ нууц үгүүдэд ашиглагдах нууц үгийн хэлбэр нь нэвтрэлтийн passwd_format боломжийн тусламжтай /etc/login.conf файлд хянагддаг бөгөөд энэ хувьсагч нь des, md5 blf, sha256 эсвэл sha512 утгуудыг авдаг. Нэвтрэлтийн боломжуудын талаар дэлгэрэнгүй мэдээллийг login.conf(5) гарын авлагын хуудаснаас үзнэ үү.
15.5. Нэг удаагийн нууц үгүүд
Анхдагчаар FreeBSD OPIE (One-time Passwords In Everything буюу Бүхэнд зориулсан нэг удаагийн нууц үгүүд) дэмжлэгтэй байдаг бөгөөд энэ нь MD5 хэшийг анхдагчаар ашигладаг.
Бид гурван өөр төрлийн нууц үгийг доор хэлэлцэх болно. Эхнийх нь таны ердийн UNIX® загварын эсвэл Kerberos нууц үг юм; бид үүнийг "UNIX® нууц үг" гэж нэрлэх болно. Хоёр дахь төрөл нь OPIE opiekey(1) програмаар үүсгэгдэж opiepasswd(1) програм болон нэвтрэлт хүлээх мөр хүлээн авах нэг удаагийн нууц үг юм; бид үүнийг "нэг удаагийн нууц үг" гэх болно. Сүүлийн төрөл нууц үг бол opiekey програмд (заримдаа opiepasswd програмууд) өгдөг нууцлаг нууц үг бөгөөд үүнийг ашиглан дээрх програмууд нэг удаагийн нууц үг үүсгэдэг; бид үүнийг "нууцлаг нууц үг" гэх буюу эсвэл зүгээр л шалгагдаагүй "нууц үг" гэх болно.
Нууцлаг нууц үг нь таны UNIX® нууц үгтэй ямар ч холбоогүй юм; тэдгээр нь адил байж болох боловч ингэхийг зөвлөдөггүй. OPIE нууцлаг нууц үгүүд нь хуучин UNIX® нууц үгүүд шиг 8 тэмдэгтэд хязгаарлагддаггүй бөгөөд таны хүссэн хэмжээний урттай байж болдог. Зургаа эсвэл долоон үг бүхий өгүүлбэрээс тогтох нууц үгүүд нэлээн элбэг байдаг. Ихэнх хэсгийн хувьд OPIE систем UNIX®-ийн нууц үгийн системээс бүр мөсөн ангид ажилладаг.
Нууц үгээс гадна OPIE-д чухал өгөгдлийн өөр хоёр хэсэг байдаг. Нэг нь "seed буюу үр" эсвэл "key буюу түлхүүр" гэгддэг бөгөөд 2 үсэг болон таван тооноос тогтдог. Нөгөөдөх нь "давталтын тоо" буюу 1-ээс 100 хүртэлх тоо юм. OPIE нэг удаагийн нууц үгийг үр болон нууцлаг нууц үгийг нийлүүлэн MD5 хэшийг давталтын тоогоор ашиглан үүсгэж үр дүнг нь зургаан богино Англи үг болгодог. Эдгээр зургаан Англи үг нь таны нэг удаагийн нууц үг юм. Нэвтрэлт шалгах систем (үндсэндээ PAM) ашигласан хамгийн сүүлийн нэг удаагийн нууц үгийг хадгалж байдаг бөгөөд хэрэглэгчийн өгсөн нууц үгийн хэш өмнөх нууц үгтэй таарч байвал хэрэглэгчийг нэвтрүүлдэг. Үл буцах хэш ашиглагддаг болохоор хэрэв амжилттайгаар ашиглагдсан нууц үгийг олж авсан бол дараа дараагийн нэг удаагийн нууц үгүүдийг үүсгэх боломжгүй байдаг; хэрэглэгч болон нэвтрэлтийн програмыг хамгийн сүүлийн хэлбэрт адилхан байлгаж байхын тулд давталтын тоо амжилттай нэвтрэлт хийгдэх бүрийн дараа багасаж байдаг. Давталтын тоо 1 хүрэх үед OPIE дахин хийгдэх хэрэгтэй болно.
Систем болгоны хувьд хэдэн програмууд байдаг бөгөөд тэдгээрийг бид энд хэлэлцэх болно. opiekey програм давталтын тоо, үр болон нууцлаг нууц үгийг хүлээн авч нэг удаагийн нууц үг эсвэл нэг удаагийн нууц үгүүдийн үргэлжилсэн жагсаалтыг үүсгэдэг. opiepasswd програмыг OPIE-г эхлүүлэх болон нууц үг, давталтын тоо эсвэл үр өөрчлөхөд ашигладаг; энэ нь нууцлаг нэвтрэх үгс аль эсвэл давталтын тоо, үр болон нэг удаагийн нууц үгийг авдаг. opieinfo програм тохирох итгэмжлэлүүдийн файлуудыг (/etc/opiekeys) шалгаж ажиллуулсан хэрэглэгчийн одоогийн давталтын тоо болон үрийг дэлгэцэд гаргадаг.
Бид дөрвөн өөр төрлийн үйлдлийн талаар хэлэлцэх болно. Эхнийх нь аюулгүй холболтоор opiepasswd ашиглаж нэг удаагийн нууц үгүүдийг эхний удаа тохируулах эсвэл өөрийн нууц үг эсвэл үрийг өөрчлөх үйлдэл юм. Хоёр дахь үйлдэл нь opiepasswd-г аюултай холболтоор, opiekey тушаалыг аюулгүй холболтоор ашиглаж адил үйлдлийг хийх явдал юм. Гурав дахь нь opiekey-г аюултай холболтоор ашиглан нэвтрэн орох үйлдэл юм. Дөрөв дэх нь opiekey-г ашиглан хэд хэдэн түлхүүрүүд үүсгэх үйлдэл бөгөөд гадагшаа аюулгүй холболтуудгүй газрууд уруу явахдаа тэдгээр түлхүүрүүдийг бичин авч эсвэл хэвлэн аваад өөртөө авч явж болох юм.
15.5.1. Аюулгүй холболт эхлүүлэх
OPIE-г эхний удаа эхлүүлэхдээ opiepasswd тушаалыг ажиллуул:
% 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 COEDEnter new secret pass phrase: эсвэл Enter secret password: мөрүүд дээр та нууц үг эсвэл өгүүлбэр оруулах ёстой. Энэ нь таны нэвтрэхдээ ашиглах нууц үг биш гэдгийг санах хэрэгтэй, үүнийг ашиглаж таны нэг удаагийн нэвтрэх түлхүүрийг үүсгэдэг. "ID" мөр таны тухайн үеийн параметрүүд болох таны нэвтрэх нэр, давталтын тоо болон үрийг өгдөг. Нэвтрэн орох үед систем эдгээр параметрүүдийг санаж танд тэдгээрийг санах шаардлагагүйгээр буцаан үзүүлдэг. Сүүлийн мөр нь тэдгээр параметрүүд болон таны нууцлаг нууц үгт харгалзах нэг удаагийн нууц үгийг өгдөг; хэрэв та нэн даруй дахин нэвтэрвэл энэ нэг удаагийн нууц үг нь таны ашиглах тэр нууц үг юм.
15.5.2. Аюултай холболт эхлүүлэх
Өөрийн нууцлаг нууц үгийг аюултай холболтоор эхэлж өгөхдөө эсвэл өөрчлөхдөө opiekey ажиллуулж болох тийм газар уруу аюулгүй холболттой байж байх шаардлагатай; энэ нь таны итгэж байгаа машин дээр бүрхүүлийн тушаал хүлээх мөр хэлбэрээр байж болно. Та бас давталтын тоог (100 боломжийн утга байж болох юм) бодож өгөх хэрэгтэй бөгөөд та өөрөө үр бодож олох эсвэл дурын үүсгэснийг ашиглах хэрэгтэй. Аюултай холболтоор (таны эхлүүлж байгаа машин уруу) opiepasswd тушаалыг ашигла:
% 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 дар. Дараа нь хандах нууц үгийг оруулахын өмнө аюулгүй холболт уруугаа орж адил параметрүүдийг өгөөрэй:
% 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Одоо аюултай холболт уруугаа шилжиж үүсгэсэн нэг удаагийн нууц үгээ тохирох програм уруу хуулаарай.
15.5.3. Нэг удаагийн нууц үг ганцыг үүсгэх нь
OPIE-г эхлүүлэн тохируулж нэвтэрсний дараа танд иймэрхүү тушаал хүлээх мөр харуулагдана:
% 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 дарвал хүлээх мөр цуурайг идэвхжүүлж таны юу бичиж байгааг танд харуулдаг. Та хэвлэсэн зүйлээсээ харж магадгүй нууц үгийг гараараа бичиж оруулахыг оролдож байгаа бол энэ маш ашигтай байж болох юм.
Энэ үед нэвтрэлт хүлээх мөрөнд хариулахын тулд та өөрийн нэг удаагийн нууц үгийг үүсгэх хэрэгтэй болно. Үүнийг opiekey тушаал итгэн ажиллуулж чадах тийм систем дээрээ хийх хэрэгтэй. (DOS, Windows® болон Mac OS®-д зориулсан эдгээрийн хувилбарууд байдаг) Эдгээрт давталтын тоо болон үр тушаалын мөрийн тохируулга хэлбэрээр хэрэгтэй байдаг. Та нэвтрэн орж байгаа машиныхаа нэвтрэлт хүлээх мөрөөс эдгээрийг шууд хуулан тавьж болох юм.
Итгэсэн систем дээрээ:
% 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Одоо та өөрийн нэг удаагийн нууц үгтэй болсон болохоор нэвтрэлтээ үргэлжлүүлж болно.
15.5.4. Нэг удаагийн нууц үг олныг үүсгэх нь
Заримдаа та итгэсэн машин эсвэл аюулгүй холболт уруу хандах боломжгүй тийм газар очих хэрэгтэй болдог. Энэ тохиолдолд opiekey тушаал ашиглаж хэд хэдэн нэг удаагийн нууц үгүүдийг урьдчилан үүсгэж хэвлэн биедээ авч явах боломжтой юм. Жишээ нь:
% 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-n 5 нь дараалсан таван түлхүүрийг үүсгэхийг, 30 нь сүүлийн давталтын тоог хэд байх ёстойг зааж өгч байгаа юм. Эдгээр нь ашиглах бололцоотойг урвуу дарааллаар дэлгэцэнд харуулдгийг тэмдэглэх нь зүйтэй. Хэрэв та хэт санаа зовниж байгаа бол та үр дүнг гараар бичиж авахыг хүсэж болох юм; эсвэл lpr уруу хуулан авч тавьж болох юм. Мөр бүр давталтын тоо болон нэг удаагийн нууц үгийг харуулж байгааг анхаараарай; та нууц үгүүдийг хэрэглэх бүртээ тэдгээрийг арилгаж энэ хэвлэсэн арга тань ашигтай хэвээр болохыг мэдэж болох юм.
15.5.5. UNIX® нууц үгүүдийг ашиглахыг хязгаарлах нь
OPIE нь UNIX® нууц үгүүдийн ашиглалтыг нэвтрэлтийн сессийн IP хаяг дээр тулгуурлан хязгаарлаж чаддаг. Тохирох файл нь /etc/opieaccess бөгөөд энэ файл нь анхдагчаар байдаг. Энэ файлын талаар болон үүнийг ашигласнаар та аюулгүй байдлын ямар зүйлсүүдийг бодолцож анхаарах ёстой талаар дэлгэрэнгүй мэдээллийг opieaccess(5)-с шалгана уу.
Энд жишээ opieaccess файл байна:
permit 192.168.0.0 255.255.0.0
Энэ мөр нь UNIX® нууц үгүүдийг ямар ч үед ашиглахын тулд эхлэл IP хаягийг (хууран мэхлэхэд хүрч болох тийм эмзэг) заагдсан утга болон багтай тааруулах боломжийг хэрэглэгчдэд олгодог.
opieaccess дахь аль ч дүрэм таарахгүй байгаа бол анхдагчаар OPIE биш нэвтрэлтүүдийг хааж үгүйсгэдэг.
15.6. TCP Гүйцэтгэлийг хялбаршуулагчид
inetd(8)-г мэддэг хэн бүхэн TCP Гүйцэтгэлийг хялбаршуулагчдын талаар заримдаа сонссон байх. Гэхдээ цөөн хүмүүс энэ боломжийн сүлжээний орчин дахь ашигтай талыг бүрэн ойлгодог юм шиг санагддаг. Хүн бүхэн сүлжээний холболтууд зохицуулах галт хана суулгахыг хүсдэг юм шиг санагддаг. Галт хана олон төрлийн хэрэглээтэй боловч холболт үүсгэгч уруу текст илгээх зэрэг зарим зүйлсийг галт хана хийж чаддаггүй. Энд дурдсан TCP Гүйцэтгэлийг хялбаршуулагчид энэ мэтийг болон үүнээс илүүг хийдэг. Дараагийн хэдэн хэсэгт TCP Гүйцэтгэлийг хялбаршуулагчдын олон боломжуудыг хэлэлцэх бөгөөд боломжтой үед нь жишээ тохиргооны мөрийг үзүүлэх болно.
TCP Гүйцэтгэлийг хялбаршуулагчид програм хангамж нь inetd-ийн чадваруудыг сервер бүрийн хувьд түүний доор хянагдаж болохоор дэмжин өргөтгөдөг. Энэ аргыг ашиглан бүртгэл хөтлөх дэмжлэг нэмэх, холболтууд уруу мэдэгдэл буцаах, дэмонд зөвхөн дотоод холболтуудыг хүлээн авахыг зөвшөөрөх гэх мэт үйлдлүүдийг хийх боломжтой. Эдгээр боломжуудын заримыг галт хана суулган тохируулж хийж болох боловч энэ нь зөвхөн хамгаалалтын нэмэлт давхарга болохоос гадна галт ханын үзүүлж чаддагаас илүү хяналтыг олгодог юм.
TCP Гүйцэтгэлийг хялбаршуулагчдын ийнхүү нэмэгдсэн ажиллагаа нь сайн галт ханыг солихоор зүйл гэж ойлгогдох ёсгүй юм. TCP Гүйцэтгэлийг хялбаршуулагчид нь галт хана эсвэл өөр бусад аюулгүй байдлыг нэмэгдүүлэгч програмуудын хамтаар ашиглагдаж системийн хувьд хамгаалалтын нэмэлт давхарга болон аятайхан үйлчлэх боломжтой юм.
Энэ нь inetd-ийн тохиргооны өргөтгөл болохоор энэхүү баримтыг уншигч таныг inetd тохиргоо хэсгийг уншсан гэдэгт найдаж байна.
inetd(8)-ээр ажиллуулагдсан програмууд яг жинхэнээрээ "дэмонууд" биш боловч тэдгээрийг уламжлалаар дэмонууд гэдэг. Энэ ухагдахууныг бид энэ хэсэгт бас ашиглах болно. |
15.6.1. Эхний тохиргоо
TCP Гүйцэтгэлийг хялбаршуулагчдыг FreeBSD-д ашиглахад байх цорын ганц шаардлага нь inetd серверийг rc.conf файлаас -Ww тохируулгатай ажиллуулсан эсэхийг шалгах явдал юм; энэ нь анхдагч тохиргоо юм. Мэдээж /etc/hosts.allow файлын зөв тохиргоо бас байгааг хүлээж байдаг боловч эдгээр тохиолдлуудад syslogd(8) системийн бүртгэлүүдэд мэдэгдлүүд шиддэг.
Бусад TCP Гүйцэтгэлийг хялбаршуулагчдын шийдлүүдтэй харьцуулах юм бол hosts.deny файлыг хэрэглэхээ больсон. Тохиргооны бүх сонголтууд /etc/hosts.allow файлд байх шаардлагатай. |
Хамгийн амархан тохиргоогоороо бол дэмоны холболтын бодлогууд зөвшөөрөгдсөн эсвэл хаагдсаны аль нэгээр /etc/hosts.allow файл дахь тохируулгуудаас хамааран тохируулагддаг. FreeBSD дээрх анхдагч тохиргоо нь inetd-ээр эхэлсэн дэмон бүр уруу хийгдэх холболтыг зөвшөөрдөг. Үүнийг өөрчлөх талаар зөвхөн үндсэн тохиргооны тухай дурдсаны дараа хэлэлцэх болно.
Үндсэн тохиргоо ихэвчлэн дэмон : хаяг : үйлдэл хэлбэрийг авдаг. Энд байгаа дэмон нь inetd-ийн эхлүүлсэн дэмоны нэр юм. Хаяг нь зөв хостын нэр, address хаяг эсвэл дөрвөлжин хаалтан ([ ]) доторх IPv6 хаяг байж болно. action буюу үйлдлийн талбар нь allow буюу зөвшөөрөх эсвэл deny буюу эрхийг хориглох эсвэл хандалтыг хаахын аль нэг байна. Тохиргоо эхний тохирсон дүрэм журмын дагуу ажилладаг гэдгийг санах хэрэгтэй, энэ нь тохирох дүрмийг тохиргооны файлаас өсөх дарааллаар хайна гэсэн үг юм. Тохирох дүрэм олдвол тэр дүрэм ашиглагдаж хайх процесс зогсоно.
Бусад хэд хэдэн тохируулгууд байдаг боловч тэдгээрийг энэ хэсгийн сүүлд тайлбарлах болно. Хялбар тохиргооны мөр ганцхан тэр мэдээллийн дагуу амархнаар хийгдэж болно. Жишээ нь mail/qpopper дэмоноор дамжин хийгдэж болох POP3 холболтуудыг зөвшөөрөхийн тулд дараах мөрүүд hosts.allow файлд нэмж хийгдэх хэрэгтэй:
# This line is required for POP3 connections: qpopper : ALL : allow
Энэ мөрийг нэмснийхээ дараа inetd-г service(8) ашиглан дахин эхлүүлэх хэрэгтэй:
# service inetd restart15.6.2. Дэвшилтэт тохиргоо
TCP Гүйцэтгэлийг хялбаршуулагчид нь бас дэвшилтэт тохируулгуудтай байдаг; тэдгээр нь холболтуудтай хэрхэн ажиллахыг илүүтэйгээр хянах боломжийг олгодог. Зарим тохиолдолд тодорхой хостууд эсвэл дэмон холболтууд уруу тайлбар буцаах нь зүйтэй санаа байж болох юм. Бусад тохиолдолд магадгүй бүртгэлийн файл бичигдэх ёстой эсвэл цахим захидал администратор уруу илгээгдэж болох юм. Бусад тохиолдлууд үйлчилгээг зөвхөн дотоод холболтууддаа ашиглахыг шаардаж болох юм. Эдгээр нь бүгдээрээ орлуулагддаг тэмдэгтүүд, өргөтгөх тэмдэгтүүд болон гадаад тушаалыг ажиллуулах зэрэг тохиргооны сонголтуудын тусламжтай хийгдэх боломжтой юм. Дараагийн хоёр хэсэгт эдгээр тохиолдлуудын талаар бичсэн байгаа.
15.6.2.1. Гадаад тушаалууд
Холболтыг хааж түүнийг тогтоохыг оролдсон хүн уруу шалтгааныг нь илгээх тохиолдол гарчээ гэж бодъё. Үүнийг яаж хийх вэ? Энэ үйлдлийг twist тохируулга ашиглан хийх боломжтой. Холболт тогтоохоор оролдоход twist тохируулга бүрхүүлийн тушаал эсвэл скрипт ажилуулахаар дуудагддаг. 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-с ашиглах зөвшөөрөлгүй." гэсэн мэдэгдлийг хандалтын файлд урьдаар тохируулагдаагүй дэмон бүрийн хувьд буцаадаг. Энэ нь тогтоогдсон холболт дөнгөж салсны дараа холболтыг эхлүүлэгч уруу хариултыг буцааж илгээхэд маш их ашигтай байдаг. Буцсан мэдэгдэл бүр " тэмдэгтүүд дотор заавал байх шаардлагатай; энэ дүрмэнд ямар нэг жич зөвшөөрөл байхгүй.
Хэрэв халдагч эсвэл бүлэг халдагчид эдгээр дэмонуудыг холболт хийх хүсэлтээр цутгаж чадах юм бол серверийн эсрэг үйлчилгээг зогсоох халдлага явуулах боломжтой байж болох юм. |
Өөр нэг боломж нь эдгээр тохиолдлуудад spawn тохируулгыг ашиглах явдал юм. twist тохируулгын нэгэн адил spawn тохируулга нь холболтуудыг сохроор хааж гадаад бүрхүүлийн тушаалууд эсвэл скриптүүдийг ажиллуулахад ашиглагдаж болно. twist тохируулгаас ялгаатай тал нь spawn нь холболт тогтоосон хүн уруу хариулт буцааж илгээдэггүй. Жишээ нь дараах тохиргооны мөр байжээ гэж бодъё:
# 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 тэмдэгтээс гадна бусад цөөн хэдэн тэмдэгтүүд бас байдаг. Бүрэн жагсаалтыг hosts_access(5) гарын авлагын хуудаснаас үзнэ үү.
15.6.2.2. Орлуулагддаг тэмдэгтүүдийн тохиргоонууд
Энэ хүртэл ALL тохируулга бүх л жишээнүүдэд ашиглагдлаа. Ажиллагааг арай цаашлуулж өргөтгөх бусад тохируулгууд байдаг. Жишээ нь ALL нь дэмон, домэйн эсвэл IP хаягийн аль нэгтэй тааруулах зорилгоор ашиглагдаж болох юм. Өөр нэг орлуулагддаг тэмдэгт нь IP хаягаа өөрчлөн хуурсан байж болох дурын хостыг тааруулах PARANOID тохируулга юм. Өөрөөр хэлбэл PARANOID буюу хэт зовнил нь өөрийн хостын нэрээс өөр IP хаягтай машинаас холболт хийгдэх бүр түүнд тохирох үйлдлийг тодорхойлоход ашиглагдаж болох юм. Дараах жишээ энэ хэлэлцүүлэгт арай илүү ойлголт өгч магадгүй юм:
# Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny
Энэ жишээн дээр sendmail уруу хийгдэж байгаа өөрийнхөө хостын нэрээс өөр IP хаягтай холболтын бүх хүсэлтүүдээс татгалзан хааж байна.
Хэрэв клиент эсвэл сервер эвдэрхий DNS суулгацтай бол |
Орлуулагддаг тэмдэгтүүдийн талаар болон тэдэнтэй холбоотой ажиллагааны талаар дэлгэрэнгүйг hosts_access(5) гарын авлагын хуудаснаас үзээрэй.
Тусгай тохиргооны аль ч мөрүүдийн өмнө дээрх нь ажиллана, эхний тохиргооны мөр hosts.allow файлд тайлбар болгон хаагдах шаардлагатай. Үүнийг энэ хэсгийн эхэнд тэмдэглэж хэлсэн байгаа.
15.7. Kerberos5
Kerberos нь хэрэглэгчид өөрсдийгөө нууцлаг серверийн үйлчилгээнүүдийн тусламжтайгаар таниулан нэвтрэх боломжийг олгодог сүлжээний нэмэлт систем/протокол юм. Алсын нэвтрэлт, алсын хуулбар, нууцлаг систем хоорондох файл хуулбарлалт болон бусад аюул ихтэй үйлдлүүд зэрэг үйлчилгээнүүд харьцангуй аюулгүй хийгдэж илүү хяналт хийж болохоор болсон.
Kerberos нь хэн бэ гэдгийг шалгах прокси систем юм. Энэ нь бас итгэгдсэн гуравдагч нэвтрэлт таних систем гэж тайлбарлагдаж болно. Kerberos нь зөвхөн нэг функцыг хангадаг - сүлжээн дээр хэрэглэгчдэд өөрсдийгөө аюулгүйгээр таниулах боломжийг хангаж өгдөг. Энэ нь шалгаж таних функцууд (хэрэглэгчдийн хийхийг зөвшөөрдөг) эсвэл аудит функцуудын (тэдгээр хэрэглэгчид юу хийснийг) үүргийг гүйцэтгэдэггүй. Клиент болон сервер өөрийгөө таниулж батлахаар Kerberos-г ашигласны дараа тэд бизнесээ бодож өөрсдийн бүх холболтуудаа шифрлэж нууцлал болон бүрэн бүтэн байдлаа хадгалан баталгаажуулж болно.
Иймээс Kerberos-ийг нэвтрэлт танилт болон аудит үйлчилгээнүүдийг хангадаг бусад аюулгүй байдлын аргуудтай цуг ашиглахыг маш ихээр зөвлөдөг.
Дараах заавруудыг FreeBSD-д зориулан түгээгдсэн Kerberos-ийг хэрхэн тохируулах гарын авлага болгон ашиглаж болно. Гэхдээ та тохирох гарын авлагын хуудаснуудаас бүрэн тайлбарын талаар лавлах хэрэгтэй.
Kerberos-ийн суулгацыг үзүүлэх зорилгоор төрөл бүрийн нэрийн талбарууд дараах байдлаар зохицуулагдана:
DNS домэйн ("бүс") нь example.org байна.
Kerberos хүрээ нь EXAMPLE.ORG байна.
Хэрэв та дотооддоо ажиллуулах бодолтой байсан ч гэсэн Kerberos-ийг суулгаж тохируулахдаа жинхэнэ домэйны нэрүүдийг ашиглана уу. Энэ нь DNS-ийн асуудлуудыг тойрон гарч бусад Kerberos хүрээнүүдтэй хийх хоорондын үйлдлийг баталгаажуулдаг. |
15.7.1. Түүх
Kerberos-ийг MIT анх сүлжээний аюулгүй байдлын асуудлуудын шийдэл болгож хийсэн. Kerberos протокол нь хүчирхэг криптографыг ашигладаг бөгөөд клиент нь аюултай сүлжээний холболтоор өөрийгөө хэн бэ гэдгийг серверт (болон эсрэгээр) баталж чадах боломжийг олгодог.
Kerberos нь сүлжээний танин шалгах протоколын нэрээс гадна програмыг (жишээ нь Kerberos телнет) шийдвэрлэж байгаа програмуудыг тайлбарласан тайлбар бас болдог. Протоколын одоогийн хувилбар нь 5 бөгөөд RFC 1510-д тайлбарласан байдаг.
Өргөн хүрээний үйлдлийн системүүдийг хамарсан энэ протоколын хэд хэдэн чөлөөтэй шийдлүүд байдаг. Kerberos анх хөгжүүлэгдсэн Массачусетсийн Технологийн Институт (MIT) нь өөрийн Kerberos багцыг хөгжүүлсээр байна. Энэ багц нь US-д криптограф бүтээгдэхүүн болж нийтлэг хэрэглэгддэг бөгөөд энэ нь түүхээс авч үзэхэд US-ын экспортын дүрэм журмуудаас болсон юм. MITKerberos нь порт (security/krb5) хэлбэрээр байдаг. Heimdal Kerberos нь өөр шийдлийн 5-р хувилбар бөгөөд экспортын дүрэм журмуудыг тойрон гарах зорилгоор US-ээс гадна хамааралгүйгээр хөгжүүлэгдсэн ( бөгөөд ихэвчлэн арилжааны бус UNIX® төрлүүдэд орсон байдаг) юм. Heimdal Kerberos түгээлт нь порт (security/heimdal) хэлбэрээр байдаг бөгөөд үүний хамгийн бага суулгац үндсэн FreeBSD суулгацад орсон байдаг.
Аль болох олон үзэгчдийг хамрахын тулд эдгээр зааврууд нь FreeBSD-д орсон Heimdal түгээлтийг ашиглаж байна гэж тооцдог.
15.7.2. Heimdal KDC суулгаж тохируулах
Түлхүүр Түгээх Төв (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)-ийг нэмэх хэрэгтэй.
Зөв тохируулсан BINDDNS сервер бүхий том сүлжээнүүдэд өмнөх жишээ нь: [libdefaults]
default_realm = 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 тушаал ашиглан өөрчилж чадна. Та аль ч тушаал хүлээх мөрөнд ? тушаал ашиглаж байгаа боломжит тохируулгуудыг харж болохыг санаарай.
Мэдээллийн сан үүсгэлтийн жишээ сесс доор байна:
# kstash
Master key: xxxxxxxx
Verifying password - Master key: xxxxxxxx
# 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 үйлчилгээнүүдийг эхлүүлэх цаг болжээ. Үйлчилгээнүүдийг эхлүүлэхдээ service kerberos start болон service kadmind start тушаалуудыг ажиллуулна. Энэ үед танд ямар ч kerberos хийгдсэн дэмон байхгүйг санаарай, гэхдээ та KDC-ийн өөрийнх нь тушаалын мөрөөс үүсгэсэн удирдагчид (хэрэглэгч) зориулсан тасалбарыг авч жагсаан KDC-г ажиллаж байгаа гэдгийг та баталж чадаж байх ёстой:
% kinit tillman
tillman@EXAMPLE.ORG's Password:
% 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Та дууссаныхаа дараа тасалбарыг буцааж болно:
% kdestroy15.7.3. Серверийг Kerberos хийн Heimdal үйлчилгээнүүдтэй идэвхжүүлэх
Эхлээд бидэнд Kerberos-ийн тохиргооны файл /etc/krb5.conf-ийн хуулбар хэрэг болно. Ингэхийн тулд KDC-ээс түүнийг аюулгүй аргаар (scp(1) зэрэг сүлжээний хэрэгслүүд эсвэл физикээр уян диск ашиглан) клиент компьютер уруу ердөө л хуулах хэрэгтэй.
Дараа нь танд /etc/krb5.keytab файл хэрэгтэй. Энэ нь Kerberos хийгдсэн дэмонууд бүхий сервер болон ажлын станц хоёрын гол ялгаа юм - сервер нь keytab файлтай байх шаардлагатай. Энэ файл нь өөрийг нь зөвшөөрдөг серверийн хост түлхүүр болон өөрсдийнхөө нэрийг (identity) шалгах KDC-г агуулдаг. Хэрэв түлхүүр нь нийтэд мэдэгдвэл серверийн аюулгүй байдал эвдэрч болох учир энэ нь сервер уруу аюулгүйн үүднээс дамжуулагдах ёстой. Энэ нь шууд утгаараа FTP зэрэг цэвэр текст сувгаар дамжуулах нь маш буруу гэсэн үг юм.
Ихэвчлэн сервер уруу keytab файлыг kadmin тушаал ашиглан дамжуулдаг. Энэ нь тохиромжтой байдаг бөгөөд учир нь та бас хостын удирдагчийг (krb5.keytab файлын KDC төгсгөл) kadmin тушаал ашиглан үүсгэх хэрэгтэй болдог.
Та тасалбарыг аль хэдийн авсан байх ёстой бөгөөд энэ тасалбар нь kadmind.acl файлын kadmin интерфэйсийг ашиглаж болохоор зөвшөөрөгдсөн байх ёстойг санаарай. Heimdal-ийн мэдээллийн хуудаснуудын (info heimdal) "Алсын удирдлага" гэсэн гарчигтай хэсгээс хандалт хянах жагсаалтуудыг дизайн хийх талаар дэлгэрэнгүйг үзнэ үү. Хэрэв та алсын kadmin хандалтыг идэвхжүүлэхийг хүсэхгүй байгаа бол та KDC уруу ердөө л аюулгүйгээр холбогдож (локал консолоор, ssh(1) эсвэл Kerberos telnet(1)) удирдлагыг локалаар өөр дээрээсээ kadmin -l тушаал ашиглан хийж болно.
/etc/krb5.conf файлыг суулгасны дараа та Kerberos серверээс kadmin тушаалыг ашиглаж болно. add --random-key тушаал нь серверийн хост удирдагчийг нэмэх боломжийг танд олгох бөгөөд ext тушаал нь серверийн хост удирдагчийг өөрийн keytab уруу задлах боломжийг танд олгоно. Жишээ нь:
# 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> exitext тушаал нь ("extract" гэдгийг богиноор илэрхийлнэ) задалсан түлхүүрийг анхдагчаар /etc/krb5.keytab файлд хадгалдаг.
Хэрэв таны хувьд KDC дээр kadmind ажиллахгүй байгаа бөгөөд (магадгүй аюулгүй байдлын шалтгаануудаас болоод) тэгээд kadmin уруу алсаас хандах боломжгүй бол та хост удирдагчийг (host/myserver.EXAMPLE.ORG) шууд KDC дээр нэмж дараа нь доор дурдсантай адилаар түүнийг түр зуурын файл уруу (KDC дээрх /etc/krb5.keytab файлыг дарж бичихээс сэргийлж) задалж болно:
# 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 файлд доор дурдсантай төстэй мөрийг оруулан идэвхжүүлж дараа нь inetd(8) үйлчилгээг service inetd restart тушаалын тусламжтай дахин ачаалах болно:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user
Хамгийн чухал нь -a төрөл (нэвтрэлт танихад) хэрэглэгчид тохируулагдсан. Илүү дэлгэрэнгүйг telnetd(8) гарын авлагын хуудаснаас лавлана уу.
15.7.4. Клиентийг Kerberos хийн Heimdal үйлчилгээтэйгээр идэвхжүүлэх
Клиент компьютерийг тохируулах нь маш амархан. Kerberos тохиргоо хийгдсэний дараа танд зөвхөн /etc/krb5.conf-д байрлах Kerberos тохиргооны файл хэрэгтэй. Үүнийг ердөө л аюулгүйгээр клиент компьютер уруу KDC-ээс хуулна.
Клиентээсээ kinit, klist, болон kdestroy тушаалуудыг үүсгэсэн удирдагчийнхаа хувьд тасалбар олж авах, үзүүлэх, болон дараа нь устгахад ашиглахыг оролдон клиент компьютераа тест хийгээрэй. Та Kerberos програмуудыг ашиглан Kerberos хийгдсэн серверүүд уруу холбогдож чадах ёстой бөгөөд хэрэв ингэж ажиллаж болохгүй байгаа бөгөөд тасалбар олж авах нь асуудалтай байгаа бол энэ нь клиент эсвэл KDC-тэй холбоотой биш сервертэй холбоотой асуудал юм.
telnet зэрэг програмыг тест хийж байх үед таны нууц үг цэвэр текстээр бишээр илгээгдэж байгааг шалгахын тулд пакет шиншлэгч (tcpdump(1) зэрэг) ашиглаад үзээрэй. telnet-ийг бүх өгөгдлийн урсгалыг шифрлэдэг (ssh-тэй адил) -x тохируулгатай ашиглахыг оролдоорой.
Төрөл бүрийн гол биш Kerberos клиент програмууд нь бас анхдагчаар суудаг. Энэ нь үндсэн Heimdal суулгацын "хамгийн бага" мөн чанар юм: telnet нь цорын ганц Kerberos хийгдсэн үйлчилгээ юм.
Heimdal порт нь зарим нэг дутуу програмуудыг нэмдэг: ftp, rsh, rcp, rlogin болон бусад цөөн хэдэн нийтлэг биш програмуудын Kerberos хийгдсэн хувилбаруудыг нэмдэг. MIT порт нь бас Kerberos клиент програмуудын бүрэн цуглуулгыг агуулдаг.
15.7.5. Хэрэглэгчийн тохиргооны файлууд: .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 файлын тухай тайлбарладгийг тэмдэглэх нь зүйтэй юм.
15.7.6. Kerberos-той холбоотой арга, зальнууд болон алдааг олж засварлах
Heimdal эсвэл MITKerberos портууд ашиглах үед таны
PATHорчны хувьсагч клиентийн програмуудын Kerberos хувилбаруудыг системийн хувилбаруудаас өмнө жагсаасан байхыг шаарддаг.Таны хүрээний бүх компьютерууд цагийн тохиргоонуудаа адилаар тохируулсан уу? Хэрэв үгүй бол нэвтрэлт танилт амжилтгүй болж болох юм. ntpd-р Цаг Тааруулах нь нь 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-ийн алдаа биш юм.MITKerberos-той байхад хэрэв та анхдагч 10 цагаас арай урт амьдрах хугацаа бүхий тасалбартай удирдагчийг зөвшөөрөхийг хүсвэл
kadminдээрmodify_principalтушаал ашиглан өөрчлөхийг хүссэн удирдагч болонkrbtgtудирдагчийн maxlife-ийг өөрчлөх шаардлагатай. Дараа нь удирдагч-lтохируулгыгkinit-тай ашиглаж илүү урт амьдрах хугацаатай тасалбарыг авах хүсэлт илгээж болох юм.
Хэрэв та өөрийн KDC дээр алдааг олж засварлахын тулд пакет шиншлэгч ажиллуулж дараа нь ажлын станцаасаа |
Хэрэв та урт амьдрах хугацаатай (жишээ нь долоо хоног) тасалбар ашиглахыг хүсэж байгаа бөгөөд та тасалбар хадгалагдаж байгаа машин уруу OpenSSH ашиглан холбогдож байгаа бол Kerberos
TicketCleanupтохируулгаnoгэж sshd_config тохиргооны файлд байгаа эсэхийг шалгаарай, тэгэхгүй бол таны тасалбарууд таныг гарах үед устгагдах болно.Хостын удирдагчид илүү урт амьдрах хугацаатай тасалбартай бас байж болно гэдгийг санаарай. Хэрэв таны хэрэглэгчийн удирдагч долоо хоног амьдрах хугацаатай бөгөөд гэхдээ таны холбогдож байгаа хост 9 цаг амьдрах хугацаатай бол та кэшдээ хугацаа нь дууссан хостын удирдагчтай болж тасалбарын кэш хүссэнээр ажиллахгүй болох болно.
Тусгайлсан муу нууц үгүүдийг ашиглуулахгүйн тулд (
kadmindтушаалын гарын авлагын хуудас үүнийг товчхон тайлбарладаг) krb5.dict файлыг тохируулахдаа нууц үгийн бодлого тавигдсан удирдагчдад энэ нь зөвхөн хамаатайг санах хэрэгтэй. krb5.dict файлуудын хэлбэр хялбар байдаг: нэг мөрт нэг үг (string) байна. /usr/shared/dict/words симболын холбоос үүсгэх нь ашигтай байж болох юм.
15.7.7. MIT портоос ялгаатай талууд
MIT болон Heimdal суулгацуудын гол ялгаа нь өөр (гэхдээ орлуулж болох) тушаалууд болон өөр протоколууд ашигладаг kadmin програмтай холбоотой юм. Хэрэв таны KDC нь MIT бол та Heimdal kadmin програмыг ашиглаж өөрийн KDC-г алсаас (эсвэл эсрэг чиглэлд энэ зорилгоор) удирдаж чадахгүй болдог учир энэ нь их хамаатай юм.
Клиент програмууд нь бас шал өөр өөр тушаалын мөрийн тохируулгууд авч адил үүргийг гүйцэтгэж болох юм. MITKerberos вэб сайт (http://web.mit.edu/Kerberos/www/) дээрх заавруудыг дагахыг зөвлөж байна. Замын асуудлуудаас болгоомжлоорой: MIT порт нь анхдагчаар /usr/local/ уруу суудаг бөгөөд хэрэв таны PATH орчны хувьсагч системийн сангуудыг эхлээд жагсаадаг бол "жирийн" системийн програмууд MIT-ийн оронд ажиллаж болохыг санаарай.
|
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 санд хоёртын файлуудыг суулгадаг болохоор ингэж хийгддэг.
15.7.8. Kerberos дахь хязгааруудыг багасгах
15.7.8.1. Kerberos нь бүгдийг эсвэл юуг ч биш гэсэн арга юм
Сүлжээнд идэвхжүүлэгдсэн үйлчилгээ бүр Kerberos-тэй ажиллахаар засварлагдсан (эсвэл сүлжээний халдлагуудын эсрэг аюулгүй байдлыг хангасан) байх шаардлагатай, тэгэхгүй бол хэрэглэгчдийн итгэмжлэлүүд хулгайлагдаж дахин ашиглагдаж болох юм. Үүний нэг жишээ нь бүх алсын бүрхүүлүүдийг (жишээ нь rsh болон telnet) Kerberos хийн идэвхжүүлсэн мөртлөө нууц үгүүдийг цэвэр текстээр илгээдэг POP3 захидлын серверийг тэгж хувиргахгүй байх явдал юм.
15.7.8.2. Kerberos нь ганц хэрэглэгчийн ажлын станцуудад зориулагдсан
Олон хэрэглэгчийн орчинд Kerberos нь тийм ч аюулгүй биш юм. Энэ нь тасалбаруудыг бүх хэрэглэгчийн хувьд уншигдаж болох /tmp санд хадгалдаг учраас тэр юм. Хэрэв хэрэглэгч компьютераа хэд хэдэн бусад хүмүүстэй зэрэг харилцан хуваалцаж байвал (өөрөө хэлбэл олон-хэрэглэгч) хэрэглэгчийн тасалбаруудыг өөр хэрэглэгч хулгайлах (хуулан авах) боломжтой юм.
Үүнийг -c файлын нэрийн тушаалын мөрийн тохируулгатай эсвэл (илүү зохимжтой) KRB5CCNAME орчны хувьсагчтайгаар даван гарч болох юм, гэхдээ ингэх нь их ховор байдаг. Зарчмын хувьд тасалбарыг хэрэглэгчдийн гэр санд хадгалж хялбар файлын зөвшөөрлүүдийг ашиглах нь энэ асуудлыг багасгадаг.
15.7.8.3. KDC нь бүтэлгүйтлийн ганц цэг
Дизайнаараа бол KDC нь мастер нууц үгийн мэдээллийн баазаас тогтох бөгөөд түүний нэгэн адил аюулгүй байх ёстой. KDC нь үүн дээр өөр ямар ч үйлчилгээнүүд ажиллуулсан байх ёсгүй бөгөөд физикээр аюулгүй байдлыг нь хангасан байх шаардлагатай. Kerberos нь ижил түлхүүрээр ("мастер" түлхүүр) шифрлэгдсэн бүх нууц үгүүдийг хадгалдаг бөгөөд тэр ижил түлхүүр нь эргээд KDC дээр файл маягаар хадгалагддаг учраас аюул өндөртэй байдаг.
Тэмдэглэн хэлэхэд булаан эзлэгдсэн мастер түлхүүр нь хэн нэг нь айхаар тийм ч муу биш юм. Түлхүүр үг нь зөвхөн Kerberos мэдээллийн баазыг шифрлэхэд болон санамсаргүй тоо үүсгэгчийн үр болон хэрэглэгддэг. Таны KDC уруу хандахад аюулгүй л байж байвал халдагч мастер түлхүүрээр их юм хийж чадахгүй.
Мөн нэмж хэлэхэд хэрэв KDC нь боломжгүй байвал (магадгүй үйлчилгээ зогсоох халдлага эсвэл сүлжээний асуудлуудаас болоод) сүлжээний үйлчилгээнүүд нь нэвтрэлт танилтыг хийж болохгүй болохоор хэрэглэгдэх боломжгүй болох бөгөөд нэг ёсны үйлчилгээ зогсоох халдлагын рецепт болох юм. Үүнийг олон KDC-тэй (нэг мастер болон нэг буюу хэд хэдэн боолууд) болон хоёрдогч эсвэл нэмэлт, эцсийн нэвтрэлт таних (PAM нь энэнд маш сайн) болгоомжтой шийдлийн тусламжтайгаар даван гарч болох юм.
15.7.8.4. Kerberos-ийн дутагдлууд
Kerberos нь хэрэглэгчид, хостууд болон үйлчилгээнүүдэд өөр хоорондоо бие биенээ таниулах боломжийг олгодог. Гэхдээ энэ нь KDC-г хэрэглэгчид, хостууд эсвэл үйлчилгээнүүдэд таниулах аргагүй юм. Энэ нь троян хийгдсэн kinit (жишээ нь) тушаал бүх хэрэглэгчийн нэрс болон нууц үгүүдийг бүртгэн бичиж авч болно гэсэн үг юм. security/tripwire ч юм уу эсвэл өөр бусад файлын системийн бүрэн бүтэн байдлыг шалгах хэрэгслүүд үүнийг арилгаж чадна.
15.8. OpenSSL
Олон хэрэглэгчдийн хайдаг нэг боломж нь FreeBSD-д байдаг OpenSSL багаж юм. OpenSSL нь ердийн холбооны давхарга дээр шифрлэлт дамжуулах давхаргыг хангаж өгдөг; ингэснээр түүнийг сүлжээний програмууд болон үйлчилгээнүүдтэй холбож өгөх боломжийг олгодог.
OpenSSL-ийн зарим нэг хэрэглээнд захидлын клиентүүдийн шифрлэсэн нэвтрэлт, кредит картаар хийх төлбөрүүд гэх мэт вэб дээр тулгуурласан шилжүүлгүүд зэрэг олныг дурдаж болно. www/apache22 болон mail/claws-mail зэрэг олон портууд нь OpenSSL-тэй бүтээх эмхэтгэлийн дэмжлэгийг санал болгодог.
Ихэнх тохиолдолд Портуудын Цуглуулга нь make хувьсагч |
FreeBSD-д орсон OpenSSL-ийн хувилбар нь Secure Sockets Layer v2/v3 (SSLv2/SSLv3) буюу Аюулгүй Сокетуудын Давхаргын v2/v3 хувилбарууд, Transport Layer Security v1 (TLSv1) буюу Тээврийн Давхаргын Аюулгүй байдлын v1 хувилбарын сүлжээний аюулгүй байдлын протоколуудыг дэмждэг бөгөөд ерөнхий криптограф сан болон ашиглагдаж болох юм.
OpenSSL нь IDEA алгоритмийг дэмждэг боловч Нэгдсэн Улсын патентуудаас болоод анхдагчаар хаалттай байдаг. Үүнийг ашиглахын тулд лицензийг шалгасан байх ёстой бөгөөд хэрэв хязгаарлалтуудыг хүлээн авах боломжтой бол |
OpenSSL-ийн хамгийн түгээмэл хэрэглээний нэг бол програм хангамжуудад зориулан ашиглах сертификатуудыг бэлдэх явдал юм. Эдгээр сертификатууд нь компани болон хувь хүмүүсийн итгэмжлэлүүдийг хүчинтэй бөгөөд луйврын биш гэдгийг баталгаажуулдаг. Хэрэв асуудалтай сертификат хэд хэдэн "Certificate Authorities" эсвэл CA-ууд буюу Сертификатын Эрх мэдэлтнүүдээр шалгагдаагүй бол ихэвчлэн анхааруулга үзүүлдэг. Сертификатын Эрх мэдэлтэн нь VeriSign зэрэг компани байдаг бөгөөд компаниуд эсвэл хувь хүмүүсийн итгэмжлэлүүдийг хүчин төгөлдөр болгохын тулд сертификатуудыг баталгаажуулж өгдөг. Энэ процесс нь өртөгтэй бөгөөд сертификатууд ашиглахад заавал ч үгүй шаардлага болдоггүй; гэхдээ энэ нь паранойд буюу хэт зовнисон хэрэглэгчдийн заримын санааг тайвшруулж болох юм.
15.8.1. Сертификатуудыг үүсгэх нь
Сертификат үүсгэхийн тулд дараах тушаал байдаг:
# 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" хүлээх мөрийн дараах хариу домэйны нэрийг харуулж байгааг анзаараарай. Энэ мөр нь шалгалт хийх зорилгоор серверийн нэрийг оруулахыг шаарддаг; домэйн нэрээс бусдыг байрлуулах нь ашиггүй сертификат үүсэхэд хүргэдэг. Бусал тохируулгууд, жишээ нь дуусах хугацаа, өөр шифрлэх алгоритмууд гэх мэт тохируулгууд байдаг. Бүрэн гүйцэд жагсаалтыг openssl(1) гарын авлагын хуудсыг үзэн авч болно.
Дээрх тушаалын ажилласан санд хоёр файл одоо байж байх ёстой. Сертификатын хүсэлт req.pem нь таны оруулсан итгэмжлэлүүдийг хүчин төгөлдөр болгож хүсэлтийг баталгаажуулан сертификатыг танд буцаах сертификатын эрх мэдэлтэн уруу илгээгдэж болно. Үүсгэгдсэн хоёр дахь файл нь cert.pem гэж нэрлэгдэн сертификатын хувийн түлхүүр болох бөгөөд ямар ч байсан гэсэн хамгаалагдсан байх ёстой; хэрэв энэ нь бусдын гарт орох юм бол таны (эсвэл таны серверийн) дүрд тоглон ашиглагдаж болох юм.
CA-с гарын үсэг шаарддаггүй тохиолдолд өөрөө зурсан сертификатыг үүсгэж болно. Эхлээд RSA түрхүүр үүсгэх хэрэгтэй:
# openssl dsaparam -rand -genkey -out myRSA.key 1024Дараа нь CA түлхүүр үүсгэ:
# openssl gendsa -des3 -out myca.key myRSA.keyСертификат үүсгэхийн тулд энэ түлхүүрийг ашигла :
# openssl req -new -x509 -days 365 -key myca.key -out new.crtСанд хоёр шинэ файл үүсэх ёстой: сертификатын эрх мэдэлтний гарын үсгийн файл myca.key болон сертификат өөрөө new.crt байна. Эдгээрийг зөвхөн root унших эрхтэй /etc санд байрлуулах шаардлагатай. Үүнд 0700 зөвшөөрөл байж болох бөгөөд түүнийг chmod хэрэгсэл ашиглан тохируулж болно.
15.8.2. Сертификатуудыг ашиглах нь, жишээ
Тэгэхээр эдгээр файлууд нь юу хийж чадах вэ? Сайн хэрэглээ болох нэг жишээ нь SendmailMTA уруу хийгдэх холболтуудыг шифрлэх байж болно. Энэ нь локал 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 процессийн жагсаалтад харуулагдана.
Хялбар тест хийхийн тулд telnet(1) хэрэгсэл ашиглан захидлын серверт холбогдох хэрэгтэй:
# 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" мөр гарч ирвэл бүгд зөв ажиллаж байна.
15.9. IPsec дээгүүр VPN хийх
FreeBSD гарц машинуудыг ашиглан Интернэтээр тусгаарлагдсан хоёр сүлжээний хооронд VPN үүсгэх.
15.9.1. IPsec-ийг ойлгох нь
Энэ хэсэг нь IPsec-ийг тохируулах процессийг тайлбарлах болно. IPsec-ийг тохируулахын тулд та өөрчлөн тохируулсан цөм бүтээх ухагдахууныг мэдсэн байх шаардлагатай (FreeBSD цөмийг тохируулах нь-г үзнэ үү).
IPsec нь Интернэт Протокол (IP) давхаргын дээр суудаг протокол юм. Энэ нь хоёр буюу хэд хэдэн хостуудыг аюулгүй байдлаар (нэрээс нь харах юм бол) холбох боломжийг олгодог. FreeBSD IPsec "сүлжээний стек" нь IPv4 болон IPv6 протоколуудыг хоёуланг дэмждэг KAME шийдэл дээр үндэслэсэн.
IPsec нь хоёр дэд протоколоос тогтоно:
Encapsulated Security Payload (ESP) буюу Хайрцаглагдсан Аюулгүй байдлын ачаа нь гуравдагчийн нөлөөллөөс тэгш хэмт криптограф алгоритмийг (Blowfish, 3DES-тэй адил) ашиглан агуулгыг нь шифрлэж IP пакетийн өгөгдлийг хамгаалдаг.
Authentication Header (AH) буюу Нэвтрэлт Танилтын Толгой нь аюулгүй хэш хийх функцаар IP пакетийн толгойн талбаруудыг хэш хийн криптограф хянах нийлбэрийг тооцоолон гуравдагч этгээдийн нөлөөлөл болон хууран мэхлэлтээс IP пакетийн толгойг хамгаалдаг. Үүний дараа пакет дахь мэдээллийг таниулахыг зөвшөөрөх хэшийг агуулсан нэмэлт толгой байдаг.
ESP болон AH нь орчноосоо хамаараад хоёулаа цуг эсвэл тусдаа ашиглагдаж болно.
IPsec нь хоёр хостын хоорондох урсгалыг шууд шифрлэх (Transport Mode буюу Тээвэрлэх Горим гэгддэг) буюу эсвэл хоёр корпорацийн сүлжээний хооронд аюулгүй холбоонд ашиглагдаж болох "виртуал туннелиуд" (Tunnel Mode буюу Туннелийн Горим гэгддэг) бүтээхэд хэрэглэгдэж болох юм. Сүүлийнх нь ерөнхийдөө Виртуал Хувийн Сүлжээ (VPN) гэгддэг. FreeBSD-ийн IPsec дэд системийн талаар дэлгэрэнгүй мэдээллийг ipsec(4) гарын авлагын хуудаснаас лавлах хэрэгтэй.
Өөрийн цөмдөө IPsec дэмжлэгийг нэмэхийн тулд та дараах тохируулгуудыг цөмийн тохиргоондоо нэмээрэй:
options IPSEC IP security
device cryptoХэрэв IPsec дибаг хийх дэмжлэг заавал хэрэгтэй бол дараах цөмийн тохируулга бас нэмэгдсэн байх шаардлагатай:
options IPSEC_DEBUG debug for IP security15.9.2. Асуудал
VPN-ийг байгуулахад ямар нэг стандарт байхгүй. VPN-үүд нь өөр өөрийн давуу болон сул талуудтай төрөл бүрийн технологиудыг ашиглан хийгдэж болно. Энэ хэсэг нь нэг тохиолдлын загвар үзүүлэх бөгөөд энэ тохиолдол дахь VPN-ийг хийхэд хэрэглэгдэх стратегиудыг харуулах болно.
15.9.3. Тохиолдол: Хоёр сүлжээ, нэг нь гэрийн нэг нь ажлын. Хоёулаа Интернэтэд холбогдсон бөгөөд энэ VPN-ээр нэг юм шиг ажиллах сүлжээ.
Угтвар нөхцөл дараах маягийн байна:
Та хамгийн багадаа хоёр сайттай байна
Хоёр сайт хоёулаа IP-г дотооддоо ашигладаг
FreeBSD дээр нь ажилладаг гарц компьютераар хоёр сайт хоёулаа Интернэтэд холбогдсон.
Хоёр сүлжээний гарц компьютер бүр хамгийн багаар бодоход нэг нийтийн IP хаягтай.
Хоёр сүлжээний дотоод хаягууд нь нийтийн эсвэл хувийн IP хаягууд байж болох юм, энэ нь хамаагүй. Тэдгээр нь давхцахгүй байх ёстой, өөрөөр хэлбэл хоёулаа
192.168.1.x-г ашиглаж болохгүй юм.
15.9.4. IPsec-ийг FreeBSD дээр тохируулах нь
Эхлээд security/ipsec-tools портын цуглуулгаас суусан байх шаардлагатай. Энэ гуравдагч талын програм хангамжийн багц нь тохиргоог дэмжихэд туслах хэд хэдэн програмуудыг агуулдаг.
Дараагийн шаардлага нь пакетуудыг тунель хийх болон хоёр сүлжээг зөв холбогдоход ашиглагдах хоёр gif(4) псевдо төхөөрөмжийг үүсгэх явдал юм. root хэрэглэгчээр internal болон external гэсэн утгуудыг жинхэнэ дотоод болон гадаад гарцуудаар өөрчлөн дараах тушаалыг ажиллуулна:
# ifconfig gif0 create# ifconfig gif0 internal1 internal2# ifconfig gif0 tunnel external1 external2Жишээ нь ажлын LAN-ий нийтийн IP нь 172.16.5.4 бөгөөд хувийн IP нь 10.246.38.1 байна. Гэрийн LAN-ий нийтийн IP нь 192.168.1.12 бөгөөд дотоод хувийн IP нь 10.0.0.5 байна.
Энэ нь толгой эргэмээр санагдаж болох бөгөөд ifconfig(8) тушаалын дараах жишээ үр дүнгээс харна уу:
Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4
Хийгдэж дууссаны дараа хоёр хувийн IP-д ping(8) тушаал ашиглан дараах үр дүнд харуулсан шиг хүрэх боломжтой байх ёстой:
priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms
Хүсэн хүлээж байсны дагуу хоёр тал хоёулаа хувийн тохируулсан хаягаасаа ICMP пакетуудыг илгээх болон хүлээн авах боломжтой байна. Дараа нь аль аль сүлжээнээс урсгалыг зөв илгээдэг байхын тулд хоёр гарцад хоёуланд нь пакетуудыг хэрхэн яаж чиглүүлэхийг зааж өгөх ёстой. Энэ зорилгод дараах тушаал хүрнэ:
# corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0# corp-net# route add net 10.0.0.0: gateway 10.0.0.5# priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0# priv-net# route add host 10.246.38.0: gateway 10.246.38.1Энэ үе хүрэхэд дотоод машинууд нь аль аль гарц болон гарцын цаана байгаа машинуудаас хүрэх боломжтой байх ёстой. Үүнийг хялбараар дараах жишээнээс тодорхойлж болно:
corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms
Тунелиуд үүсгэж тохируулах нь хялбар хэсэг юм. Аюулгүй холбоосыг тохируулах нь илүү гүнзгий процесс юм. Дараах тохиргоо нь урьдчилан хуваалцсан (PSK) RSA түлхүүрүүдийг ашиглаж байна. IP хаягаас гадна хоёр /usr/local/etc/racoon/racoon.conf файл хоёулаа адил бөгөөд доорхтой төстэй байна.
path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete
padding # options are not to be changed
{
maximum_length 20;
randomize off;
strict_check off;
exclusive_tail off;
}
timer # timing options. change as needed
{
counter 5;
interval 20 sec;
persend 1;
# natt_keepalive 15 sec;
phase1 30 sec;
phase2 15 sec;
}
listen # address [port] that racoon will listening on
{
isakmp 172.16.5.4 [500];
isakmp_natt 172.16.5.4 [4500];
}
remote 192.168.1.12 [500]
{
exchange_mode main,aggressive;
doi ipsec_doi;
situation identity_only;
my_identifier address 172.16.5.4;
peers_identifier address 192.168.1.12;
lifetime time 8 hour;
passive off;
proposal_check obey;
# nat_traversal off;
generate_policy off;
proposal {
encryption_algorithm blowfish;
hash_algorithm md5;
authentication_method pre_shared_key;
lifetime time 30 sec;
dh_group 1;
}
}
sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp)
{ # $network must be the two internal networks you are joining.
pfs_group 1;
lifetime time 36000 sec;
encryption_algorithm blowfish,3des,des;
authentication_algorithm hmac_md5,hmac_sha1;
compression_algorithm deflate;
}Тохируулга бүрийг энэ жишээн дээр жагсаагдсантай нь тайлбарлах нь энэ баримтын хүрээнээс гадуур юм. racoon-ий тохиргооны гарын авлагын хуудсанд холбогдох мэдээлэл олон бий.
FreeBSD болон racoon нь хостуудын хооронд сүлжээний урсгалыг нууцлах болон буцааж задалж чаддаг байхын тулд SPD бодлогуудыг тохируулсан байх ёстой.
Энэ үйлдлийг дараах ажлын гарц дээрх шиг энгийн бүрхүүлийн скриптээр шийдэж болно. Энэ файлыг системийг эхлүүлэх үед ашиглах бөгөөд /usr/local/etc/racoon/setkey.conf гэж хадгалах ёстой.
flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;
Ингэсний дараа racoon-г хоёр гарц дээр дараах тушаал ашиглан эхлүүлнэ:
# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.logГарах үр дүнд нь доорхтой төстэй байна:
corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)
Тунель зөв ажиллаж байгааг шалгахын тулд нөгөө консол руу шилжиж сүлжээний урсгалыг харахын тулд tcpdump(1) ашиглан дараах тушаалыг хэрэглэнэ. em0-ийг сүлжээний интерфэйс картаараа шаардлагатай бол солиорой.
# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12Доорхтой төстэй өгөгдөл консол дээр гарах ёстой. Хэрэв үгүй бол асуудалтай гэсэн үг бөгөөд буцаасан өгөгдлийг дибаг хийх шаардлагатай.
01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)
Энд хүрэхэд хоёр сүлжээ хүрэх боломжтой байх бөгөөд нэг сүлжээний хэсэг юм шиг харагдах болно. Хоёр сүлжээ нь аль аль нь галт ханаар хамгаалагдсан байж болох бөгөөд ингэх ч ёстой юм. Тэдгээрийн хооронд урсгалыг зөвшөөрөхийн тулд пакетуудыг нааш цааш дамжуулах дүрмүүдийг нэмэх шаардлагатай. ipfw(8) галт ханын хувьд галт ханын тохиргооны файлдаа дараах дүрмүүдийг нэмээрэй:
ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any
Дүрмийн дугааруудыг тухайн хостын тохиргооноос хамаарч өөрчлөх шаардлагатай байж болох юм. |
pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any
Төгсгөлд нь системийг эхлүүлэх явцад VPN-ийг машин дэмжин ажиллаж эхэлдэг байлгахын тулд дараах мөрүүдийг /etc/rc.conf файлд нэмэх хэрэгтэй:
ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes"
15.10. OpenSSH
OpenSSH нь алсын машинуудад аюулгүйгээр хандах сүлжээний холболтын хэрэгслүүдийн олонлог юм. rlogin, rsh, rcp, болон telnet-ийг энэ програмаар шууд орлуулан ашиглаж болно. Мөн TCP/IP холболтууд аюулгүйгээр SSH-ээр туннель хийгдэж/дамжуулагдаж болдог. OpenSSH нь сэм чагналт, холболт булаан авалт, болон бусад сүлжээний түвшний халдлагуудыг үр дүнтэйгээр устгаж бүх трафикийг шифрлэдэг.
OpenSSH-г OpenBSD төсөл дэмжиж байдаг бөгөөд бүх сүүлийн үеийн алдааны засварууд болон шинэчлэлтүүд бүхий SSH v1.2.12 дээр тулгуурласан байдаг. Энэ програм нь SSH протокол 1 болон 2-той хоёулантай нь нийцтэй.
15.10.1. OpenSSH-ийг ашиглах давуу тал
telnet(1) эсвэл rlogin(1) ашиглаж байх үед сүлжээгээр илгээгдэж байгаа өгөгдөл цэвэр, шифрлэгдээгүй хэлбэрээр байдаг. Сүлжээний шиншлэгчид клиент болон серверийн хооронд хаана ч байсан гэсэн таны хэрэглэгч/нууц үгийн мэдээлэл эсвэл таны сессээр дамжсан өгөгдлийг хулгайлж чадна. OpenSSH нь ийм асуудлаас хамгаалж төрөл бүрийн нэвтрэлт таних болон шифрлэх аргуудыг санал болгодог.
15.10.2. sshd-г идэвхжүүлэх
sshd нь стандарт FreeBSD суулгацын явцад харуулагдах тохируулга юм. sshd идэвхжсэн эсэхийг харахдаа rc.conf файлаас дараах мөрийг шалгаарай:
sshd_enable="YES"
Энэ нь дараагийн удаа таны систем эхлэхэд OpenSSH-д зориулсан sshd(8) дэмон програмыг дуудна. Мөн service(8) ашиглан OpenSSH-г эхлүүлэх боломжтой байдаг:
# service sshd start15.10.3. SSH клиент
# 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-р эсвэл 2-р хувилбаруудад зориулан дамжуулан клиентэд зөвхөн аль нэгийг ашиглахыг хүчилж болно. 1-р хувилбарын нийцтэй байдал нь клиентэд хуучин хувилбаруудтай нийцтэй байх зорилгоор дэмжигдсэн байдаг.
15.10.4. Аюулгүй хуулбарлалт
scp(1) тушаал rcp(1)-тэй адил ажилладаг; энэ нь файлыг алсын машинаас эсвэл машин уруу, ялгаатай нь аюулгүйгээр хуулдаг.
# scp user@example.com:/COPYRIGHT COPYRIGHT
user@example.com's password: *******
COPYRIGHT 100% |*****************************| 4735
00:00
#Өмнөх жишээн дээр энэ хостын хувьд хээ нь аль хэдийн хадгалагдсан болохоор scp(1)-ийг энд ашиглах үед шалгагддаг.
15.10.5. Тохиргоо
OpenSSH дэмон болон клиентийн системийн дагуух тохиргооны файлууд /etc/ssh санд байрладаг.
ssh_config клиентийн тохируулгуудыг тохируулдаг бөгөөд sshd_config нь дэмонг тохируулдаг.
Мөн sshd_program (анхдагчаар /usr/sbin/sshd) болон sshd_flagsrc.conf тохируулгууд тохиргооны түвшнүүдийг илүүтэйгээр хангадаг.
15.10.6. ssh-keygen
Нууц үгүүдийг ашиглахын оронд ssh-keygen(1) нь хэрэглэгчийг шалгаж танихад DSA эсвэл RSA түлхүүрүүдийг үүсгэхэд хэрэглэгдэж болно:
% 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.comssh-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 түлхүүрүүдийг ашиглан алсын машин уруу холбогдохыг зөвшөөрөх болно.
Хэрэв нэвтрэх үгнүүд ssh-keygen(1)-д ашиглагдаж байгаа бол хувийн түлхүүрийг хэрэглэхийн тулд хэрэглэгчээс нууц үгийг нэвтрэх болгонд асуудаг. ssh-agent(1) нь урт нэвтрэх үгнүүдийг дахин дахин оруулах тэр зовлонг зөөллөж чадах бөгөөд ssh-agent болон ssh-add хэсэгт тайлбарлагдсан байгаа болно.
Төрөл бүрийн тохируулгууд болон файлууд нь таны систем дээр байгаа OpenSSH-ийн хувилбаруудаас шалтгаалан өөр өөр байдаг; асуудалтай учрахгүйн тулд та ssh-keygen(1) гарын авлагын хуудаснаас лавлах хэрэгтэй. |
15.10.7. ssh-agent болон ssh-add
ssh-agent(1) болон ssh-add(1) хэрэгслүүд нь нэвтрэх үгнүүдийг дахин дахин бичүүлэлгүйгээр SSH түлхүүрүүдийг санах ойд дуудан ашиглаж болох аргуудаар хангадаг.
ssh-agent(1) хэрэгсэл нь түүн уруу дуудагдсан хувийн түлхүүр(үүд) ашиглан жинхэнэ эсэхийг шалгах танилтыг зохицуулна. ssh-agent(1) нь өөр програмыг ачаалахад хэрэглэгдэх ёстой. Хамгийн хялбартаа энэ нь бүрхүүл эсвэл илүү дэвшилттэйгээр ашиглавал цонхны удирдагч ажиллуулж болох юм.
ssh-agent(1)-ийг бүрхүүлд ашиглахын тулд үүнийг эхлээд бүрхүүлтэй цуг нэмэлт өгөгдөл маягаар ажиллуулах шаардлагатай. Хоёрдугаарт хэн бэ гэдэг мэдээллийг (identity) ssh-add(1)-г ажиллуулан нэмэх хэрэгтэй бөгөөд түүнд хувийн түлхүүрийн нэвтрэх үгнүүдийг өгөх хэрэгтэй. Эдгээр алхмууд хийгдсэний дараа хэрэглэгч харгалзах нийтийн түлхүүр суулгагдсан дурын хост уруу ssh(1) хийж чадах болно. Жишээ нь:
% ssh-agent csh
% ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
%X11 дээр ssh-agent(1) хэрэглэхийн тулд ssh-agent(1)-ийн дуудлага ~/.xinitrc-д байх шаардлагатай. Ингэснээр X11-д ачаалагдсан бүх програмуудад ssh-agent(1)-ийн үйлчилгээнүүдийг үзүүлэх болно. Жишээ ~/.xinitrc файл иймэрхүү харагдах болно:
exec ssh-agent startxfce4
Энэ нь ssh-agent(1)-ийг ажиллуулах бөгөөд тэр нь эргээд X11 эхлэх бүрт XFCE-ийг ажиллуулна. Ингэж хийгдсэний дараа өөрчлөлтүүд нь үйлчлэхийн тулд X11 дахин эхэлсний хойно өөрийн SSH түлхүүрүүдийг бүгдийг ачаалахын тулд ердөө л ssh-add(1)-ийг ажиллуулаарай.
15.10.8. SSH туннель хийх
OpenSSH нь шифрлэгдсэн сессийн үед өөр протоколыг хайрцаглах туннель үүсгэх чадвартай байдаг.
Дараах тушаал telnet-д зориулж туннель үүсгэхийг ssh(1)-д хэлж өгнө:
% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
%ssh тушаал дараах тохируулгуудтай хэрэглэгдэнэ:
-2ssh-ийг протоколын 2-р хувилбарыг ашиглахыг зааж өгнө. (хэрэв та хуучин SSH серверүүдтэй ажиллаж байгаа бол үүнийг битгий ашиглаарай)-NТушаал байхгүй эсвэл зөвхөн туннель гэдгийг заана. Хэрэв үүнийг орхивол
sshердийн сесс эхлүүлнэ.-fssh-ийг ард, далд ажиллуулахыг заана.-LЛокал туннелийг localport:remotehost:remoteport загвараар зааж өгнө.
user@foo.example.comАлсын SSH сервер.
SSH туннель нь сонсох сокетийг localhost-ийн заагдсан порт дээр үүсгэн ажилладаг. Дараа нь локал хост/порт дээр хүлээн авсан дурын холболтыг SSH-ээр дамжуулан заасан алсын хост болон порт уруу илгээдэг.
Жишээн дээр localhost дээрх 5023 порт нь алсын машины localhost дээрх 23 порт уруу дамжуулагдаж байна. 23 нь telnet учир энэ нь SSH туннелээр аюулгүй telnet сесс үүсгэнэ.
SMTP, POP3, FTP гэх зэрэг ямар ч аюултай TCP протоколуудын гүйцэтгэлийг хялбаршуулахад үүнийг ашиглаж болно.
Жишээ 1. SMTP-д зориулан SSH ашиглан аюулгүй туннель үүсгэх
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTPҮүнийг ssh-keygen(1) болон нэмэлт хэрэглэгчийн бүртгэлүүдтэй цуг илүү үл үзэгдэх/төвөггүй SSH туннель хийх орчин үүсгэхэд ашиглаж болно. Түлхүүрүүд нь нууц үг бичихийн оронд ашиглагдаж болох бөгөөд туннелиуд нь тусдаа хэрэглэгч маягаар ажиллаж чадна.
15.10.8.1. SSH туннелийн практик жишээнүүд
15.10.8.1.1. POP3 сервер уруу аюулгүй хандах
Ажил дээр чинь гаднаас холболтууд хүлээн авах SSH сервер байна. Бас тэр оффисийн сүлжээнд POP3 сервер ажиллуулж байгаа захидлын сервер байна. Таны гэр болон оффисийн хоорондын сүлжээ болон сүлжээний зам итгэж болохоор эсвэл итгэж болохооргүй байж магадгүй юм. Ийм учраас та өөрийн захидлыг аюулгүй аргаар шалгах хэрэгтэй юм. Үүний шийдэл нь өөрийн оффисийн SSH сервер уруу SSH холболт үүсгэж захидлын сервер уруу туннель хийх явдал юм.
% 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 уруу илгээгдэнэ.
15.10.8.1.2. Хэцүү галт ханыг тойрон гарах
Зарим сүлжээний администраторууд хэтэрхий чанга галт ханын дүрэм ашиглан зөвхөн ирж байгаа холболтууд төдийгүй гарч байгаа холболтуудыг ч бас шүүдэг. Танд алсын машинуудад зөвхөн SSH болон вэбээр аялах 22 болон 80-р портуудад хандах боломжийг өгсөн байж болох юм.
Та хөгжим цацдаг Ogg Vorbis сервер зэрэг өөр (магадгүй ажилдаа холбоогүй) үйлчилгээ уруу хандахыг магадгүй хүсэж болох юм. Хэрэв энэ Ogg Vorbis сервер нь 22 эсвэл 80-аас бусад өөр порт дээр цацаж байгаа бол та түүнд хандаж чадахгүй юм.
Үүний шийдэл нь таны сүлжээний галт ханаас гаднах машин уруу SSH холболт үүсгэж үүнийг Ogg Vorbis сервер уруу туннель хийхэд ашиглах явдал юм.
% 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 уруу дамжуулагдана.
15.10.9. AllowUsers тохируулга
Ямар хэрэглэгчид хаанаас орохыг хязгаарлаж өгөх нь зүйтэй юм. 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-д өөрчлөлтүүд хийснийхээ дараа sshd(8)-д өөрийн тохиргооны файлуудыг дахин дуудахыг дараах тушаалыг ажиллуулж та хэлж өгөх ёстой:
# service sshd reload15.11. Файлын системийн хандалт хянах жагсаалтууд(ACL-үүд)
Хормын хувилбарууд зэрэг файлын системийн өргөжүүлэлтүүдийн хамтаар FreeBSD нь Файлын системийн хандалт хянах жагсаалтуудын (ACL-ууд) аюулгүй байдлыг санал болгодог.
Хандалт Хянах Жагсаалтууд нь стандарт UNIX® зөвшөөрлийн загварыг маш нийцтэй (POSIX®.1e) аргаар өргөтгөдөг. Энэ боломж нь администраторт илүү төвөгтэй аюулгүй байдлын загвар болон түүний давуу талыг ашиглахыг зөвшөөрдөг.
UFS файлын системүүдэд ACL дэмжлэгийг идэвхжүүлэхийн тулд дараах:
options UFS_ACL
тохируулгыг цөмд эмхэтгэх шаардлагатай. Хэрэв энэ тохируулга эмхэтгэгдээгүй бол ACL-ууд дэмжих файлын системийг холбохыг оролдоход анхааруулах мэдэгдэл дэлгэцэд гардаг. Энэ тохируулга GENERIC цөмд орсон байдаг. ACL-ууд нь файлын систем дээр өргөтгөсөн шинж чанаруудыг идэвхжүүлсэн дээр тулгуурладаг. Өргөтгөсөн шинж чанарууд нь дараа үеийн UNIX® файлын систем UFS2-д төрөлхийн дэмжигдсэн байдаг.
UFS1 дээр өргөтгөсөн шинж чанаруудыг тохируулахад UFS2 дээр тохируулахтай харьцуулбал илүү удирдлагын зардал шаардлагатай байдаг. UFS2 дээрх өргөтгөсөн шинж чанаруудын ажиллагаа нь бас бодитойгоор илүү байдаг. Иймээс UFS2-г UFS1-ийн оронд хандалт хянах жагсаалтуудад ашиглахыг ерөнхийдөө зөвлөдөг. |
ACL-ууд нь /etc/fstab файлд нэмэгдэж өгч болох холбох үеийн удирдлагын acls тугаар идэвхтэй болдог. Файлын системийн толгой дахь супер блокийн ACL-ууд тугийг өөрчлөхийн тулд tunefs(8)-ийг ашиглан шургуу замаар холбох үеийн тугийг автоматаар зааж өгч болно. Ерөнхийдөө хэд хэдэн шалтгааны улмаас супер блокийн тугийг ашиглах нь дээр байдаг:
Холбх үеийн ACL-ууд туг дахин холболтоор өөрчлөгддөггүй (mount(8)
-u), зөвхөн бүрэн гүйцэд umount(8) хийгдэж шинэ mount(8) хийгдсэний дараа болно. Энэ нь бас файлын системийг ашиглаж байх үед дарааллыг нь өөрчилж болохгүй гэсэн үг юм.fstab-д мөр байхгүй байсан ч гэсэн эсвэл төхөөрөмжүүдийн дараалал өөрчлөгдсөн ч гэсэн супер блокийн тугийг тохируулах нь файлын системийг үргэлж ACL-уудыг идэвхтэйгээр холбоход хүргэдэг. Энэ нь файлын системийг ACL-уудыг идэвхжүүлэлгүйгээр санамсаргүйгээр холбохоос хамгаалдаг бөгөөд ингэж санамсаргүй холбох нь ACL-уудыг буруугаар албадаж тэгснээр аюулгүй байдлын асуудлуудад хүргэж болох юм.
Бид шинэ 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 сан тэгэхгүй байна.
15.11.1. ACL-уудыг ашиглах нь
Файлын системийн ACL-уудыг getfacl(1) хэрэгслээр харж болно. Жишээ нь test файл дээрх ACL тохируулгуудыг харахын тулд дараах тушаалыг ажиллуулах хэрэгтэй:
% getfacl test
#file:test
#owner:1001
#group:1001
user::rw-
group::r--
other::r--Энэ файлын ACL тохируулгуудыг өөрчлөхийн тулд setfacl(1) хэрэгслийг ажиллуул. Ажиглаарай:
% setfacl -k test-k туг нь тухайн үед тодорхойлогдсон бүх ACL-уудыг файл эсвэл файлын системээс арилгана. Илүү дээр арга бол ACL-уудыг ажиллуулахад шаардлагатай үндсэн талбаруудыг орхидог -b тугийг ашиглах явдал юм.
% setfacl -m u:trhodes:rwx,group:web:r--,o::--- testДээр дурдсан тушаал дээр -m тохируулга анхдагч ACL оруулгуудыг өөрчлөхөд хэрэглэгдсэн. Өмнөх тушаалаар устгагдсан болохоор урьдчилан тодорхойлсон оруулгууд байхгүй учир энэ нь анхдагч тохируулгуудыг сэргээж жагсаасан тохируулгуудаас зааж өгдөг. Хэрэв та систем дээр байхгүй хэрэглэгч эсвэл бүлэг нэмэх бол Invalid argument буюу Буруу нэмэлт өгөгдөл гэсэн алдаа stdout уруу хэвлэгдэнэ гэдгийг санаж байх хэрэгтэй.
15.12. Гуравдагч талын аюулгүй байдлын асуудлуудыг монитор хийх нь
Сүүлийн жилүүдэд эмзэг асуудлын үнэлгээ хэрхэн зохицуулагдаж байгаа тал дээр аюулгүй байдлын ертөнц олон сайжруулалт хийсэн. Одоогийн байгаа бүх л үйлдлийн системүүд дээр гуравдагч талын хэрэгслүүд суулгаж тохируулдгаас болж системийн халдлагын заналхийлэл ихэсдэг.
Эмзэг асуудлын үнэлгээ нь аюулгүй байдлын түлхүүр хүчин зүйл бөгөөд FreeBSD нь үндсэн системд зориулан зөвлөгөөнүүдийг гаргадаг боловч гуравдагч талын хэрэгслүүд бүрийн хувьд хийх нь FreeBSD төслийн боломжоос гадуур юм. Мэдэгдэж байгаа асуудлуудыг администраторуудад анхааруулж гуравдагч талын эмзэг асуудлуудыг зөөлрүүлэх арга байдаг. FreeBSD-д нэмэлтээр Portaudit гэгддэг хэрэгсэл зөвхөн энэ зорилгоор байдаг.
ports-mgmt/portaudit порт нь FreeBSD-ийн аюулгүй байдлын баг болон портуудын хөгжүүлэгчдийн шинэчилж ажиллагааг нь хангаж байдаг мэдээллийн баазаас мэдэгдэж байгаа аюулгүй байдлын асуудлуудыг шалгадаг.
Portaudit-г ашиглаж эхлэхийн тулд Портуудын цуглуулгаас түүнийг суулгах хэрэгтэй:
# cd /usr/ports/ports-mgmt/portaudit && make install cleanСуулгах процессийн явцад өдөр бүрийн аюулгүй байдлыг шалгах ажиллагаанд Portaudit-н гаралтыг зөвшөөрч periodic(8)-д зориулсан тохиргооны файлуудыг шинэчилдэг. Өдөр тутмын аюулгүй байдлыг шалгах ажиллагаа root-ийн захидлын бүртгэл уруу цахим захидал явуулж түүнийг уг хэрэглэгч уншсан эсэхийг баталгаажуулах хэрэгтэй. Өөр ямар ч илүү тохиргоо энд хэрэггүй.
Суулгасны дараа администратор мэдээллийн баазыг шинэчлэх болон суулгасан багцуудад мэдэгдэж байгаа эмзэг асуудлуудыг үзэхдээ дараах тушаалыг ажиллуулна:
# portaudit -FdaМэдээллийн бааз periodic(8) ажиллах үед автоматаар шинэчлэгддэг; иймээс дээрх тушаал заавал шаардлагагүй юм. Энэ нь зөвхөн дараах жишээнүүдэд шаардлагатай. |
Портуудын цуглуулгын хэсэг болгон суулгагдсан гуравдагч талын хэрэгслүүдийг ямар ч үед аудит хийхдээ администратор зөвхөн дараах тушаалыг ажиллуулах хэрэгтэй:
# portaudit -aPortaudit эмзэг асуудалтай багцын хувьд доор дурдсантай адилыг гаргана:
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 уруу вэб хөтчийг чиглүүлж администратор асуудалтай байгаа эмзэг асуудлын талаар дэлгэрэнгүй мэдээллийг олж авч болно. Ийм мэдээлэл нь нөлөөлөх хувилбарууд болон FreeBSD-ийн портын хувилбар, аюулгүй байдлын зөвлөгөөнүүд байж болох өөр бусад вэб сайтуудыг агуулж болох юм.
Товчхондоо Portaudit нь хүчирхэг хэрэгсэл бөгөөд Portupgrade порттой цуг хэрэглэхэд маш ашигтай байдаг.
15.13. FreeBSD-ийн аюулгүй байдлын зөвлөгөөнүүд
Үйлдвэрлэлийн чанарыг хангасан үйлдлийн системүүдийн нэгэн адил FreeBSD "Аюулгүй байдлын зөвлөгөөнүүд" гаргадаг. Эдгээр зөвлөгөөнүүд нь ихэвчлэн аюулгүй байдлын жагсаалтууд уруу илгээгддэг бөгөөд зөвхөн тохирох хувилбаруудад засвар хийгдсэний дараа Errata буюу алдааны хуудсанд тэмдэглэгддэг. Энэ хэсэгт зөвлөгөө гэж юу болох, түүнийг хэрхэн ойлгох болон системд засвар хийхдээ ямар арга хэмжээнүүдийг авах талаар тайлбарлах болно.
15.13.1. Зөвлөгөө ямархуу харагдах вэ?
FreeBSD-ийн аюулгүй байдлын зөвлөгөөнүүд FreeBSD аюулгүй байдлын мэдэгдлүүд захидлын жагсаалт захидлын жагсаалтаас авсан доорх зөвлөгөөтэй адил харагдах болно.
=============================================================================
FreeBSD-SA-XX:XX.UTIL Security Advisory
The FreeBSD Project
Topic: denial of service due to some problem(1)
Category: core(2)
Module: sys(3)
Announced: 2003-09-23(4)
Credits: Person(5)
Affects: All releases of FreeBSD(6)
FreeBSD 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) (7)
CVE Name: CVE-XXXX-XXXX (8)
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 (9)
II. Problem Description (10)
III. Impact (11)
IV. Workaround (12)
V. Solution (13)
VI. Correction details (14)
VII. References (15)| 1 | Topic буюу сэдэв талбар асуудал юу болохыг яг заасан байдаг. Энэ нь үндсэндээ тухайн үеийн аюулгүй байдлын зөвлөгөөний танилцуулга бөгөөд эмзэг асуудалтай цуг хэрэгслийг тэмдэглэдэг. |
| 2 | The Category буюу зэрэглэл талбар нь хамаарч байгаа системийн хэсгийг хэлдэг бөгөөд core, contrib, эсвэл ports-ийн аль нэг байж болно. core зэрэглэл нь эмзэг асуудал FreeBSD үйлдлийн системийн гол хэсэгт нөлөөлнө гэсэн үг юм. contrib зэрэглэл нь эмзэг асуудал sendmail зэрэг FreeBSD төсөлд хувь нэмэр болгон оруулсан програм хангамжуудад нөлөөлнө гэсэн үг юм. Эцэст нь ports зэрэглэл нь эмзэг асуудал портуудын цуглуулганд ордог нэмэлт програм хангамжуудад нөлөөлөхийг харуулдаг. |
| 3 | Module талбар нь бүрэлдэхүүн хэсгийн байрлалыг жишээ нь sys гэх зэргээр илэрхийлдэг. Энэ жишээн дээр sys модуль өртөхийг бид харж байгаа бөгөөд ийм учраас энэ эмзэг асуудал нь цөм дотор ашиглагдсан бүрэлдэхүүн хэсэгт нөлөөлөх юм. |
| 4 | Announced буюу зарласан талбар нь аюулгүй байдлын зөвлөгөө хэвлэгдсэн эсвэл ертөнцөд зарлагдсан огноог заадаг. Энэ нь аюулгүй байдлын баг асуудал байгааг шалгаж үүний засвар FreeBSD-ийн эх модны архивт итгэмжлэн оруулсныг тогтоосон гэсэн үг юм. |
| 5 | Credits буюу талархал талбар нь эмзэг асуудлыг мэдэж тайлагнасан хувь хүн болон байгууллагыг зааж талархдаг. |
| 6 | Affects буюу нөлөөлөх хувилбарын талбар нь энэ эмзэг асуудал нөлөөлөх FreeBSD-ийн хувилбаруудыг тайлбарладаг. Цөмийн хувьд уг нөлөөлсөн файлууд дээр ажиллуулсан ident тушаалын үр дүнг зэрвэс харж хувилбарыг тодорхойлж болно. Портуудын хувьд /var/db/pkg санд портын нэрийн дараа хувилбарын дугаар байдаг. Хэрэв систем нь FreeBSD-ийн Subversion архивтай адил хамгийн сүүлийн хэлбэрт орж өдөр тутам дахин бүтээгдээгүй бол энэ нь нөлөөлөлд орсон хэвээр байх магадлалтай юм. |
| 7 | Corrected буюу засварласан талбар нь огноо, цаг, цагийн бүс болон засварласан хувилбаруудыг заадаг.
Common Vulnerabilities Database system буюу Нийтлэг Эмзэг асуудлуудын Мэдээллийн Баазын системээс эмзэг асуудлуудыг хайхад хэрэглэгдэх магадлалын мэдээлэлд нөөцлөгддөг. |
| 8 | Background талбар нь нөлөөлөлд яг ямар хэрэгсэл орсон талаар мэдээлэл өгдөг. Ихэнхдээ энэ нь FreeBSD-д яагаад тухайн хэрэгсэл байдаг, юунд хэрэглэгддэг болон хэрэгсэл хэрхэн бий болсон талаар байдаг. |
| 9 | Problem Description буюу асуудлын тайлбар талбар нь аюулгүй байдлын цоорхойг гүнзгий тайлбарладаг. Энэ нь гажигтай кодын мэдээлэл эсвэл бүр хэрэгслийг хэрхэн хорлонтойгоор ашиглаж аюулгүй байдлын цоорхой нээдэг тухай мэдээллийг агуулдаг. |
| 10 | Impact буюу үйлчлэл талбар нь асуудал системд ямар төрлийн үйлчлэл үзүүлдгийг тайлбарладаг. Жишээ нь энэ нь үйлчилгээг зогсоох халдлагаас авахуулаад хэрэглэгчдэд өгч болох нэмэлт зөвшөөрлүүд эсвэл халдагчид супер хэрэглэгчийн хандалт өгөх зэрэг юу ч байж болно. |
| 11 | Workaround буюу тойрон гарах талбар нь боломжит тойрон гарах арга замыг системийг шинэчилж чадахгүй байж болох системийн администраторуудад олгодог. Энэ нь хугацааны шаардлагууд, сүлжээний боломж эсвэл өөр бусад олон шалтгаанаас болдог байж болох юм. Ямар ч байсан гэсэн аюулгүй байдлыг хөнгөнөөр авч үзэж болохгүй бөгөөд нөлөөлөлд орсон систем эсвэл засвар нөхөөс хийгдэх аль эсвэл аюулгүй байдлын цоорхойг тойрон гарах шийдэл хийгдэх шаардлагатай. |
| 12 | Solution буюу шийдэл талбар нь нөлөөлөлд орсон системийг засварлах заавруудыг санал болгодог. Энэ нь системд засвар нөхөөс хийн аюулгүй ажиллуулах алхам алхмаар тест хийгдэж шалгагдсан арга юм. |
| 13 | Correction Details буюу засварын нарийн учир талбар нь Subversion салбар эсвэл хувилбарын нэрийн цэгүүдийг доогуур зураас тэмдэгтээр өөрчилж үзүүлдэг. Мөн энэ нь салбар болгон дахь нөлөөлөлд орсон файлуудын хувилбарын дугаарыг бас харуулдаг. |
| 14 | References буюу лавлагаа талбар нь ихэвчлэн бусад мэдээллийн эхүүдийг өгдөг. Энэ нь вэбийн URL-ууд, номнууд, захидлын жагсаалтууд болон мэдээний бүлгүүдийг агуулж болно. |
15.14. Процессийн бүртгэл хөтлөх
Процессийн бүртгэл хөтлөх аюулгүй байдлын аргыг ашиглаж администраторууд системийн эх үүсвэрүүдийг ашигласан байдал болон тэдгээрийг хэрэглэгчдэд хэрхэн хуваарилсныг мэдэж болох бөгөөд энэ нь системийг монитор хийх боломжийг олгодог. Мөн энэ арга нь хэрэглэгчдийн тушаалуудыг туйлын багаар мөшгих боломжийг администраторуудад олгодог.
Энэ нь үнэн хэрэгтээ өөрийн эерэг болон сөрөг талуудтай. Эерэг талуудын нэг нь халдлагыг орсон цэг хүртэл нарийсган олох боломж юм. Сөрөг тал нь процессийн бүртгэл хөтлөлтөөр үүссэн бүртгэлүүд бөгөөд тэдгээр нь дискний зай шаардаж болох юм. Энэ хэсэг процессийн бүртгэл хөтлөлтийн үндсүүдийг администраторуудад таниулах болно.
15.14.1. Процессийн бүртгэл хөтлөлтийг идэвхжүүлж хэрэглэх нь
Процессийн бүртгэл хөтлөлтийг ашиглаж эхлэхээсээ өмнө үүнийг идэвхжүүлэх хэрэгтэй. Үүнийг хийхийн тулд дараах тушаалуудыг ажиллуул:
# touch /var/account/acct
# accton /var/account/acct
# echo 'accounting_enable="YES"' >> /etc/rc.confИдэвхтэй болгосны дараа бүртгэл хөтлөлт CPU статистикууд, тушаалууд гэх мэтийг даган мөшгиж эхэлнэ. Бүртгэлийн бүх бичлэгүүд уншиж болохооргүй хэлбэрээр байдаг бөгөөд тэдгээрийг sa(8) хэрэгсэл ашиглан үзэж болдог. Ямар нэг тохируулгагүйгээр ажиллуулбал sa тушаал нь хэрэглэгч болгоны дуудлагуудын тоо, нийт зарцуулсан хугацааг минутаар, нийт CPU болон хэрэглэгчийн хугацааг минутаар, дундаж I/O үйлдлүүдийн тоо гэх мэттэй холбоотой мэдээллийг дэлгэцэнд хэвлэн үзүүлдэг.
Тушаалуудыг ашигласан тухай мэдээллийг харахын тулд lastcomm(1) хэрэгслийг ашиглах хэрэгтэй. lastcomm тушаал нь тухайн ttys(5) дээр хэрэглэгчдийн ажиллуулсан тушаалуудыг үзүүлэхэд хэрэглэгдэж болно, жишээ нь:
# lastcomm ls
trhodes ttyp1Дээрх тушаал нь ttyp1 терминал дээр trhodes хэрэглэгчийн ls тушаал ашигласан мэдэгдэж байгаа бүгдийг дэлгэцэд харуулах болно.
Өөр олон ашигтай тохируулгууд байдаг бөгөөд lastcomm(1), acct(5) болон sa(8) гарын авлагын хуудаснуудад тайлбарласан байдаг.
Last modified on: 2024 оны гуравдугаар сарын 9 by Danilo G. Baio