معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة
أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.
المحاضرة 1: "مقدمة: نماذج التهديد"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 2: "السيطرة على هجمات القراصنة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 3: "تجاوزات العازلة: المآثر والحماية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 4: "فصل الامتيازات"
الجزء 1 /
الجزء 2 /
الجزء 3 إذن ماذا لدينا في هذه القائمة؟ العمليات. الذاكرة هي شيء يحدث بالتزامن مع العملية. وبالتالي ، إذا لم تكن في هذه العملية ، فلا يمكنك الوصول إلى ذاكرتها. الذاكرة الافتراضية تعزز بشكل مثالي هذه العزلة بالنسبة لنا. بالإضافة إلى ذلك ، تسمح لك آلية التصحيح "بالظهور" في ذاكرة عملية أخرى ، إذا كان لديك نفس معرف المستخدم
بعد ذلك لدينا الشبكة. لا تتوافق الشبكات في
Unix تمامًا مع النموذج الموضح أعلاه ، ويرجع ذلك جزئيًا إلى حقيقة أن
نظام تشغيل
Unix تم تطويره لأول مرة ، ثم ظهرت شبكة ، سرعان ما أصبحت شائعة. لديها مجموعة مختلفة قليلا من القواعد. لذلك ، فإن العمليات التي نحتاج إليها حقًا هي توصيل شخص ما بالشبكة إذا كنت تدير الشبكة ، أو تستمع إلى بعض المنافذ إذا كنت تعمل كخادم. قد تحتاج إلى قراءة البيانات أو كتابتها على هذا الاتصال ، أو إرسال واستلام حزم
أولية .
وبالتالي ، فإن الشبكات في
Unix لا تتعلق في الغالب
بمعرف المستخدم . القواعد هي أن أي شخص يمكنه دائمًا الاتصال بأي جهاز أو أي عنوان IP أو فتح اتصال. إذا كنت ترغب في الاستماع على أحد المنافذ ، فهناك في هذه الحالة اختلاف واحد ، وهو أن معظم المستخدمين ممنوعون من الاستماع إلى المنافذ برقم أقل من "القيمة السحرية" 1024. من حيث المبدأ ، يمكنك الاستماع إلى هذه المنافذ ، ولكن في هذه الحالة يجب عليك كن مستخدمًا خاصًا باسم
"المستخدم الفائق" مع
uid = 0 .
بشكل عام ، في Unix ، يوجد مفهوم المسؤول أو المستخدم الفائق ، والذي يتم تمثيله بالمعرف uid = 0 ، والذي يمكنه تجاوز جميع عمليات التحقق هذه تقريبًا ، لذلك إذا كنت تعمل مع حقوق الجذر ، فيمكنك قراءة الملفات وكتابتها وتغيير حقوق الوصول إليها. سيسمح لك نظام التشغيل بالقيام بذلك لأنه يعتقد أنه يجب أن يكون لديك جميع الامتيازات. وأنت حقًا بحاجة إلى مثل هذه الامتيازات للاستماع على المنافذ برقم <1024. ما رأيك في مثل هذا التقييد الغريب؟
الجمهور: يحدد أرقام المنافذ المحددة لاتصالات معينة ، على سبيل المثال ، لـ
http على المنفذ 80.
البروفيسور: نعم ، بشكل افتراضي يستخدم
بروتوكول HTTP المنفذ 80. من ناحية أخرى ، يمكن للخدمات الأخرى استخدام منافذ برقم أعلى من 1024 ، لماذا هذا التقييد ضروري؟ ما الفائدة هنا؟
الجمهور: لأنك لا تريد أن يستمع أحد بطريق الخطأ إلى
HTTP الخاص بك.
الأستاذ: نعم. أعتقد أن السبب في ذلك هو أنك تستخدم العديد من المستخدمين على نفس الجهاز. لقد قاموا بتسجيل الدخول باستخدام تسجيلات الدخول الخاصة بهم ، وأطلقوا تطبيقاتهم ، لذلك أردت التأكد من أن بعض المستخدمين العشوائيين ، بعد تسجيل الدخول إلى الكمبيوتر ، لن يتمكنوا من الحصول على خادم الويب الذي يعمل عليه. نظرًا لأن المستخدمين المتصلين من الخارج لا يعرفون من يعمل على هذا المنفذ ، وهم يتصلون فقط بالمنفذ 80. إذا كنت أرغب في إدخال هذا الجهاز وبدء خادم الويب الخاص بي ، فأنا فقط أنقل كل حركة مرور خادم الويب إلى هذه السيارة. ربما لا تكون هذه خطة جيدة جدًا ، ولكنها الطريقة التي يمنع بها النظام الفرعي لشبكة Unix المستخدمين العشوائيين من التحكم في الخدمات المعروفة التي تعمل على أرقام المنافذ المنخفضة هذه. هذا هو الأساس المنطقي لهذا القيد.
بالإضافة إلى ذلك ، من وجهة نظر قراءة وكتابة بيانات الاتصال ، إذا كان لديك ملف واصف لمقبس معين ، فإن
Unix سيسمح لك بقراءة وكتابة أي بيانات في
اتصال TCP أو
uTP هذا . عند إرسال الحزم
الأولية ، يتصرف
Unix مثل بجنون العظمة ، لذلك لن يسمح لك بإرسال حزم عشوائية عبر الشبكة. يجب أن يكون هذا في سياق الاتصال الخاص ، ما لم يكن لديك
الجذر - الحق ويمكنك القيام بكل ما تريد.
لذا ، أحد الأسئلة المثيرة للاهتمام التي يمكنك طرحها هو من أين يأتي كل هؤلاء
المستخدمين ؟
نحن نتحدث عن العمليات التي لها
معرف مستخدم أو
معرف جماعي . عند تشغيل
PS على جهاز الكمبيوتر الخاص بك ، سترى بالتأكيد سلسلة من العمليات بقيم
uid مختلفة. من أين أتوا؟
نحتاج إلى بعض الآليات لتحميل كل قيم
معرفات المستخدمين هذه. لدى
Unix العديد من مكالمات النظام المصممة لذلك. لذلك ، للتمهيد لقيم المعرف هذه ، هناك وظيفة تسمى
setuid (uid) ، بحيث يمكنك تعيين رقم
uid لبعض العملية الحالية لهذه القيمة. هذه في الواقع عملية خطيرة ، مثل كل شيء آخر في تقليد
يونكس ، لأنه لا يمكنك القيام بذلك إلا إذا كان
uid = 0 . على أي حال ، يجب أن يكون الأمر كذلك.
وبالتالي ، إذا كنت مستخدمًا لديه حقوق الجذر ولديك
uid = 0 ، فيمكنك استدعاء
setuid (uid) وتبديل المستخدم إلى أي عملية. هناك بضع مكالمات نظام مماثلة أخرى لتهيئة
gid المتعلقة بالعملية: هذه هي
setgid و
setgroups . لذلك ، تسمح لك مكالمات النظام هذه بتكوين امتيازات العملية.
حقيقة أن العمليات الخاصة بك تحصل على حقوق الوصول الصحيحة عند تسجيل الدخول إلى جهاز
Unix لا يحدث لأن لديك نفس
المعرف مثل العمليات ، لأن النظام لا يعرف حتى الآن من أنت. بدلاً من ذلك ، في
Unix ، هناك نوع من إجراءات تسجيل الدخول عندما يبدأ
بروتوكول shell
SSH العملية لأي شخص يتصل بالكمبيوتر ويحاول مصادقة المستخدم.
وبالتالي ، تبدأ عملية تسجيل الدخول في البداية بـ
uid = 0 بالنسبة لمستخدم لديه حقوق الجذر ، وبعد ذلك ، عندما يتلقى اسم مستخدم وكلمة مرور محددين ، يقوم بفحصها في قاعدة بيانات الحسابات الخاصة به. كقاعدة عامة ، في
Unix ، يتم تخزين هذه البيانات في ملفين:
/ etc / password (لأسباب تاريخية ، لم تعد كلمات المرور مخزنة في هذا الملف) ، وفي
/ etc / shadow ، حيث يتم تخزين كلمات المرور. ومع ذلك ، يوجد جدول في ملف
/ etc / password يعرض كل اسم مستخدم في النظام كقيمة عددية.
وبالتالي ، يتم تعيين اسم المستخدم الخاص بك إلى عدد صحيح محدد في ملف
etc / password هذا ، ثم تتحقق عملية تسجيل الدخول مما إذا كانت كلمة المرور الخاصة بك صحيحة وفقًا لهذا الملف. إذا عثر على
uid الصحيح الخاص بك ، فإنه يقوم بتعيين وظائف
setuid إلى قيمة
uid تلك ويبدأ shell مع الأمر
exec (/ bin / sh) . يمكنك الآن التفاعل مع الغلاف ، ولكنه يعمل تحت
uid الخاص بك ، لذلك لن تتمكن من التسبب في تلف عرضي لهذا الجهاز.
الجمهور: هل من الممكن بدء عملية جديدة باستخدام
uid = 0 إذا لم يكن
uid الخاص بك بالفعل 0؟
البروفيسور: إذا كان لديك امتيازات الجذر ، يمكنك تقييد نفسك
بمرجع آخر ، وخفض
سلطتك ، ولكن على أي حال ، يمكنك إنشاء عملية بنفس
المعرف الذي تملكه فقط. ولكن يحدث أنك ترغب في زيادة الامتيازات لأسباب مختلفة. افترض أنك بحاجة إلى تثبيت حزمة ، والتي تحتاج إلى امتيازات
الجذر لها .
هناك طريقتان لتعيين الامتيازات على
Unix . لقد ذكرنا بالفعل هو واصف الملف. لذلك إذا كنت تريد حقًا زيادة الامتيازات الخاصة بك ، فيمكنك التحدث مع شخص يعمل بموجب حقوق الجذر ويطلب منه فتح هذا الملف لك. أو تحتاج إلى تثبيت بعض الواجهة الجديدة ، ثم يفتح هذا المساعد ملفًا لك ويعيد لك واصف ملف باستخدام نقل
fd . هذه إحدى الطرق لزيادة الامتيازات الخاصة بك ، ولكنها غير ملائمة لأنه في بعض الحالات هناك عمليات تعمل بعدد كبير من الامتيازات. لهذا ، لدى
Unix آلية ذكية ولكنها إشكالية في نفس الوقت تسمى
"ثنائيات setuid" . هذه الآلية قابلة للتنفيذ بشكل منتظم على
نظام ملفات
Unix ، إلا عندما تقوم بتشغيل
exec على ثنائي
setuid ، على سبيل المثال ،
/ bin / su على معظم الأجهزة ، أو
sudo ، عند بدء التشغيل.
يحتوي نظام
Unix النموذجي على مجموعة من الثنائيات
setuid . الفرق هو أنه عندما تقوم بتنفيذ أحد هذه الثنائيات ، فإنه في الواقع يبدل
معرف العملية إلى مالك هذا الثنائي. تبدو هذه الآلية غريبة عندما تراها لأول مرة. كقاعدة عامة ، فإن طرق استخدامه هي أن هذا "ثنائي" على الأرجح لديه مالك
uid 0 ، لأنك تريد حقًا استعادة العديد من الامتيازات.
أنت تريد استعادة حقوق المستخدم الفائق حتى تتمكن من تشغيل هذا الأمر
su ، وستقوم kernel ، عند تنفيذ هذا الثنائي ، بتبديل العملية
uid إلى 0 ، بحيث يقوم هذا البرنامج الآن ببعض الأشياء المميزة.
الجمهور: إذا كان لديك
uid = 0 وقمت بتغيير
uid من كل هذه الثنائيات
setuid إلى شيء آخر غير 0 ، هل يمكنك استعادة الامتيازات الخاصة بك؟
البروفيسور: لا ، لن تتمكن العديد من العمليات من استعادة الامتيازات عند خفض مستوى الوصول ، لذلك قد تكون عالقًا في هذا المكان. هذه الآلية غير مرتبطة بـ
uid = 0 . مثل أي مستخدم لنظام
Unix ، يمكنك إنشاء أي ملف ثنائي ، وبناء برنامج ، وتجميعه ، وتعيين هذا البت
setuid على البرنامج نفسه. إنه ينتمي إليك ، المستخدم ، معرف المستخدم الخاص بك. وهذا يعني أن أي شخص يقوم بتشغيل البرنامج الخاص بك سيقوم بتشغيل هذا الرمز بمعرف المستخدم الخاص بك. هل هناك أي مشكلة في هذا؟ ما الذي يجب فعله؟
الجمهور: أي إذا كان هناك خطأ في تطبيقك ، فهل يمكن لأي شخص أن يفعل أي شيء معه ، ويتصرف مع امتيازاتك؟
البروفيسور: صحيح ، يحدث ذلك إذا كان طلبي "عربات التي تجرها الدواب" ، أو إذا كان يسمح لك بتشغيل كل ما تريده. لنفترض أنه يمكنني نسخ غلاف النظام وجعله
setuid بالنسبة لي ، ولكن بعد ذلك يمكن لأي شخص تشغيل هذا shell تحت حسابي. ربما هذه ليست أفضل خطة عمل. لكن هذه الآلية لا تخلق مشكلة ، لأن الشخص الوحيد الذي يمكنه تعيين بت
setuid على ملف ثنائي هو مالك هذا الملف. أنت ، بصفتك مالك الملف ، لديك امتياز
uid ، حتى تتمكن من نقل حسابك إلى شخص آخر ، ولكن هذا الشخص الآخر لن يكون قادرًا على إنشاء ثنائي
setuid مع
معرف المستخدم الخاص بك.
يتم تخزين بت setuid هذا بجانب وحدات بت الإذن هذه ، أي أنه يوجد في كل
inode بت
setuid يوضح ما إذا كان هذا الملف القابل للتنفيذ يجب أو إذا انتقل البرنامج إلى
uid المالك أثناء التنفيذ.
اتضح أن هذه آلية صعبة للغاية عند استخدامها بشكل صحيح ، وبفضلها ، تقوم النواة بتنفيذ البرنامج بشكل صحيح. في الواقع ، من السهل القيام بذلك ، لأنه يتم إجراء فحص واحد فقط: إذا كان هذا البت
setuid موجودًا ، فإن العملية تنتقل إلى
uid . إنه بسيط للغاية.
لكن استخدامه بأمان أمر صعب للغاية ، لأنه ، كما تم الإشارة إليه للتو ، إذا كان هذا البرنامج يحتوي على أخطاء أو يفعل شيئًا غير متوقع ، فإنك تحصل على القدرة على القيام بأشياء عشوائية تحت
uid = 0 أو تحت أي
uid أخرى. في
Unix ، عندما تقوم بتشغيل برنامج ، فإنك ترث الكثير من الأشياء من العملية الرئيسية الخاصة بك.
على سبيل المثال ، يمكنك تمرير متغيرات البيئة إلى الثنائيات المحددة. الحقيقة هي أنه في
Unix ، يمكنك تحديد المكتبة المشتركة التي ستستخدمها للعملية من خلال تعيين متغير البيئة ، ولا تهتم ثنائيات
setuid بتصفية متغيرات البيئة هذه.
على سبيل المثال ، يمكنك تشغيل
bin / su ، ولكن استخدم مكتبات مشتركة لوظيفة
printf ، لذلك ستبدأ
printf عندما تطبع
bin / su شيئًا ما ، ويمكنك تشغيل الصدفة بدلاً من printingf.
هناك العديد من التفاصيل الدقيقة التي يجب أن تفهمها بشكل صحيح فيما يتعلق بعدم الثقة في البرنامج بالبيانات التي يدخلها المستخدم. نظرًا لأنك عادةً تثق في إدخال المستخدم ، فإن
setuid لم يكن أبدًا الجزء الأكثر أمانًا من نظام
Unix بأكمله. هل لديك أسئلة حول هذا؟
الجمهور: هل ينطبق
setuid أيضًا على المجموعات أم على المستخدم فقط؟
البروفيسور: هناك بت
setgid متماثل إلى
bituid bit ، والذي يمكنك تعيينه أيضًا. إذا كان الملف يحتوي على
gid معين ويتم تعيين بت
setgid هذا عند بدء تشغيل البرنامج ، فستحصل عليه.
لا
يتم استخدام
Setgid بشكل خاص ، ولكن يمكن أن يكون مفيدًا في الحالات التي تريد فيها توفير امتيازات محددة للغاية. على سبيل المثال ، قد يحتاج
bin / su إلى الكثير من الامتيازات ، ولكن ربما هناك بعض البرامج التي تحتاج إلى بعض الامتيازات الإضافية ، على سبيل المثال ، لكتابة شيء إلى ملف سجل خاص. لذلك ، ربما تريد تزويدها بمجموعة معينة وإنشاء ملف سجل لها قابل للكتابة من قبل هذه المجموعة. لذلك حتى لو كان البرنامج "عربات التي تجرها الدواب" ، فلن تخسر أي شيء سوى هذه المجموعة. هذا مفيد كآلية لا يتم استخدامها لسبب ما في كثير من الأحيان ، لأنه بعد كل شيء ، يجب على الناس استخدام حقوق الجذر أكثر.
الجمهور: هل هناك قيود على من يمكنه تغيير الوصول؟
الأستاذ: نعم. عمليات تطبيق
Unix المختلفة لها فحوصات مختلفة لذلك. القاعدة العامة هي أن الجذر فقط هو الذي يمكنه تغيير مالك الملف ، لأنك لا تريد إنشاء ملفات تخص شخصًا آخر ، وبالطبع لا تريد أن تلائم ملفات الآخرين. لذلك إذا كان
uid الخاص بك ليس 0 ، فأنت عالق. لا يمكنك تغيير ملكية أي ملف. إذا كانت
uid = 0 ، فلديك امتيازات الجذر ويمكنك تغيير المالك لأي شخص. هناك بعض المضاعفات إذا كان لديك
setuid ثنائي وقمت بالتبديل من
uid إلى آخر ، وهذا أمر صعب للغاية ، ولكن في الأساس لا يمكنك تغيير مالك الملف بشكل أساسي إذا لم يكن لديك امتيازات الجذر.
بكل المقاييس ، هذا نظام قديم قليلاً. ربما يمكنك تخيل العديد من الطرق لتبسيط العمليات الموضحة أعلاه ، ولكن في الواقع ، تبدو معظم الأنظمة المتقدمة مثل هذا لأنها تتطور بمرور الوقت. ولكن يمكنك استخدام هذه الآليات بشكل مثالي كـ "وضع حماية".
هذه ليست سوى نوع من مبادئ
Unix الأساسية ، والتي تظهر في كل نظام تشغيل يشبه Unix تقريبًا:
Mac OS X ،
Linux ،
FreeBSD ،
Solaris ، إذا كان شخص آخر يستخدمه ، وما إلى ذلك. لكن لكل من هذه الأنظمة آليات أكثر تعقيدًا يمكنك استخدامها. على سبيل المثال ، في
Linux هناك مجموعة "sandbox"
COMP ، يستخدم
Mac OS X حزام الأمان "sandbox". في الأسبوع المقبل ، سأعطيك أمثلة على صناديق الرمل المتوفرة على كل نظام قائم على
Unix .
لذا ، فإن إحدى الآليات الأخيرة ، التي
سنأخذها بعين الاعتبار قبل الغوص في
OKWS ، تشرح كيف تحتاج إلى التعامل مع الثنائيات
setuid وتوضح كيف يمكنك حماية نفسك من الثغرات الأمنية الموجودة. تكمن المشكلة في أنه سيكون لديك حتمًا بعض الثنائيات المحددة على نظامك ، مثل
/ bin / su أو
sudo أو أي شيء آخر ، ومن المحتمل أن تحتوي برامجك على أخطاء. وبسبب هذا ، سيتمكن شخص ما من تنفيذ ثنائي
setuid وستكون العملية قادرة على الوصول إلى
الجذر ، الذي لا تريد السماح به.
آلية
Unix ، التي تستخدم غالبًا لمنع تنفيذ عملية ضارة محتملة باستخدام ثنائيات
setuid ، هي استخدام مساحة اسم نظام الملفات لتغييرها باستخدام استدعاء نظام
chroot ، وهي عملية تغيير الدليل الجذر.
OKWS ،
كخادم ويب متخصص في إنشاء خدمات ويب سريعة وآمنة ، يستخدم هذا على نطاق واسع.
لذا ، في
Unix ، يمكنك تنفيذ
chroot في دليل معين ، لذلك ربما يمكنك أيضًا تنفيذ
chroot ("/ foo") .
هناك تفسيران لما يفعله
الكسب . الأول هو بديهي ، وهذا يعني أنه بعد تشغيل
chroot ، فإن الدليل الجذر أو الدليل الموجود خلف الخط المائل يكافئ بشكل أساسي ما كان
/ foo المستخدم قبل استدعاء
chroot . يبدو أن تحديد مساحة الاسم أسفل
/ foo الخاص بك. لذلك ، إذا كان لديك ملف كان يسمى
/ foo / x ، فبعد استدعاء
chroot ، يمكنك الحصول على هذا الملف ببساطة عن طريق فتح
/ x . لذا قم فقط بتحديد مساحة الاسم الخاصة بك إلى دليل فرعي. إليك ما هو الإصدار الحدسي.
بالطبع ، في الأمان ، ليس الإصدار الحدسي هو المهم ، ولكن ما الذي تفعله النواة بالضبط مع استدعاء هذا النظام؟ وهي في الأساس شيئين. أولاً ، فإنه يغير قيمة هذه الشرطة المائلة ، لذا كلما دخلت أو عندما تبدأ اسم الدليل بشرطة مائلة ، فإن النواة تتضمن أي ملف قدمته مع عمليات
chroot . في مثالنا ، هذا هو الملف
/ foo قبل استدعاء
chroot ، أي أننا نحصل على هذا
/ = / foo .
الشيء التالي الذي ستحاول النواة فعله هو حمايتك من القدرة على "الهرب" من
/ إذا فعلت
/../ . لأنه في
Unix ، يمكنني أن أطلب منك أن تعطيني ، على سبيل المثال ،
/../etc/password . لذا إذا قمت للتو بتكملة هذا السطر على
النحو التالي :
/foo/../etc/password ، فلن يكون ذلك جيدًا ، لأنني فقط أستطيع الخروج
/ foo والاستمرار في الحصول على
/ etc / password .
الشيء الثاني الذي تقوم به kernel مع استدعاء نظام
Unix هو أنه عندما تستدعي
chroot لهذه العملية بالذات ، فإنه يغير الطريقة التي
يتم بها تقييم
/../ في هذا الدليل. لذلك ، يتم تعديل
/../ بحيث يشير
/ foo إلى نفسه. وبالتالي ، هذا لا يسمح لك بـ "الهروب" ، وينطبق هذا التغيير فقط على هذه العملية ولا يؤثر على الباقي. ما الأفكار التي لديك حول كيفية "الهروب" من بيئة
chroot باستخدام كيفية تنفيذها؟
من المثير للاهتمام أن النواة تراقب دليل
chroot واحدًا فقط ، لذلك ربما يمكنك تنفيذ عملية
chroot = (/ foo) ، ولكنك ستعلق في هذا المكان. لذلك تريد الحصول على
/ etc / password ، ولكن كيف تفعل ذلك؟ يمكنك فتح الدليل الجذر الآن بكتابة
open (* / *) . سيعطيك هذا واصف ملف يصف ما
هو / foo . ثم يمكنك استدعاء
chroot مرة أخرى وتنفيذ
chroot (`/ bar) .
, :
root /foo ,
/foo/bar /../ /foo / bar/..
,
/foo .
fchdir (fd) (*/*) ,
chdir (..) .
/foo ,
/../ .
/foo ,
root , .
, , . .
Unix root-
chroot ,
chroot . ,
Unix uid = 0 ,
chroot . . , ,
chroot ,
userid . ,
Unix , ,
root , .
, , , .
chroot — . .
: ,
inod , ?
: ! , , , : «
inode 23», -
hroot . ,
Unix inode inode , , , root-.
, , ,
OKWS . ,
OKWS .
, -, , - , . , ,
httpd , ,
Apache .
userid www /etc/password . , ,
SSL ,
PHP , . , , ,
MySQL , .
MySQL .
MySQL , , , .
, , ,
MySQL , , .
, , , , . , , ,
Apache ,
SSL , , ,
PHP . , , , .
52:30
:
دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". 4: « », 2.
, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟