تأمين خادم الويب على لينكس

مرحبا يا هبر!

لم ننشر أي كتب جديدة على Linux للمبتدئين لفترة طويلة - والآن نقوم بترجمة منتجات جديدة لمثل هذه الخطة. كتاب كلينتون لينكس في العمل ، الذي نشره مانينغ ، لا يخبر فقط عن البنية الداخلية لينكس ، ولكن أيضًا عن المشاكل الأكثر شيوعًا وكيفية إصلاحها.


نشر المؤلف مقتطفًا من الفصل التاسع على موقع Hackernoon على الويب ، ونقترح عليك تقييمه.

إن تجميع خادم LAMP ، وكيفية تكوينه ، وضمان معالجة بيانات موثوقة ، وتكوين مجال الموضوع والعناية بشهادة TLS ، ليس سوى نصف الطريق إلى النصر. تحتاج أيضًا إلى التأكد من حماية بنيتك الأساسية من العديد من التهديدات المروعة للإنترنت.

في هذه المقالة ، نقوم بفحص أمان موقع ويب من خلال التعرف على كيفية العمل بشكل صحيح مع مجموعات النظام ، وضمان عزل العملية ، ومراجعة موارد النظام بانتظام. بالطبع ، هذه القصة ليست كاملة (غطى كتاب Linux قيد التشغيل أيضًا موضوعات أخرى ، على سبيل المثال ، تثبيت شهادات TLS والعمل مع SELinux) ، لكن هذا سيكون كافيًا للبدء.

مجموعات النظام ومبدأ الحد الأدنى من الامتيازات

بدأ المطورون الذين تدعمهم (أخيرًا) في إدراك أنه من الضروري تقييد الوصول العام إلى البيانات وملفات التكوين الموجودة على خادم التطبيق ، ولكن في نفس الوقت ، لترك هذا الوصول مفتوحًا لمبرمجين مختلفين وفرق تكنولوجيا المعلومات الأخرى.

الجزء الأول من الحل هو المجموعات . المجموعة هي كائن في النظام (يشبه كثيرًا المستخدم) مع تحذير بأنه لن يقوم أي مستخدم بتسجيل الدخول إلى النظام كمجموعة. تكمن قوة المجموعات في حقيقة أنه ، مثل المستخدمين ، يمكن "تخصيصهم" للملفات أو الأدلة ، مما يسمح لكل عضو في المجموعة باستخدام الامتيازات المقدمة لها. هذا موضح أدناه.

يمكن للمطورين في مجموعة Developers الوصول إلى دليل محدد ، وبالنسبة للمستخدمين الذين ليسوا أعضاء في هذه المجموعة ، سيتم إغلاق الدليل
جربها بنفسك: قم بإنشاء ملف جديد في محرر نصوص. اكتب نصًا عاديًا فيه ، على سبيل المثال ، "Hello World" ، حتى تتمكن من معرفة متى تم الوصول إلى الملف بنجاح. ثم قم بتحرير الأذونات باستخدام chmod 770 بحيث يتمتع مالك الملف وأعضاء المجموعة التي ينتمي إليها بحقوق كاملة للعمل مع الملف ، بينما لا يستطيع الآخرون قراءته.

 $ nano datafile.txt $ chmod 770 datafile.txt 

إذا لم يكن لدى نظامك حسابات مستخدمين أخرى غير حساباتك حتى الآن ، adduser بإنشاء مثل هذا الحساب إما باستخدام adduser - يتم ذلك في Debian / Ubuntu - أو باستخدام useradd ، كما هو معتاد في CentOS. سيعمل الأمر useradd على Ubuntu أيضًا.

يتطلب الأمر useradd ، على عكس نظام التشغيل دبيان adduser إنشاء كلمة مرور المستخدم بشكل منفصل:

 # useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully 

باستخدام الأمر su ، ننتقل إلى المستخدم الجديد. بعد إدخال كلمة المرور الخاصة به ، سيتم تنفيذ كافة الأوامر التالية نيابة عن هذا المستخدم. ستعمل نيابة عن هذا المستخدم بالذات ؛ لا أكثر ولا أقل. إذا حاولت قراءة ملف البيانات datafile.txt (باستخدام cat ) ، فلن ينفعك شيء بعد الآن ؛ كما تتذكر ، فقط أعضاء المجموعة لديهم حقوق القراءة. عند الانتهاء ، اكتب exit للخروج من غلاف المستخدم الجديد والعودة إلى الغلاف الأصلي.

 $ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exit 

كل هذا متوقع ومفهوم تماما. كما ترى ، عندما لا يمكنك قراءة ملف ينتمي إلى مستخدم آخر ، فهذه مشكلة في بعض الأحيان. دعنا نرى ما يمكنك القيام به من خلال ربط الملف بالمجموعة ، ثم تكوين أذونات الملف بشكل صحيح.

سنقوم بإنشاء مجموعة جديدة يمكننا من خلالها إدارة بيانات تطبيقنا ، ثم تحرير خصائص ملف البيانات الخاص بنا باستخدام chown . حجة أوبونتو: app-data-group تترك ملكية الملف لمستخدم Ubuntu ، لكن مجموعته تتغير إلى واحدة جديدة: app-data-group.

 # groupadd app-data-group # chown ubuntu:app-data-group datafile.txt 

قم بتشغيل ls للحصول على الإخراج "الموسع" لهذا الملف وعرض أذوناته وحالته الجديدة. يرجى ملاحظة: كما هو متوقع ، الملف مملوك لمستخدم ubuntu المنتمي إلى app-data-group .

 $ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txt 

يمكنك استخدام usermod لإضافة المستخدم إلى app-data-group ، ثم استخدام الأمر su للتبديل إلى shell الذي يتم فيه نشر حساب مستخدم آخر. الآن ، على الرغم من أن حقوق الوصول إلى الملف تمنعه ​​من جميع "الآخرين" - وأنت بالتأكيد مستخدم "مختلف" في الوقت الحالي - يجب عليك قراءة هذا الملف بحرية ، لأنك تنتمي إلى المجموعة الضرورية.

 # usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello World 

باستخدام الأمر su ، نقوم بالتبديل بين حسابات المستخدمين. يتم تسجيلها في ملف datafile.txt بي. مثل هذه المنظمة هي الطريقة الصحيحة والفعالة للقضاء على مجموعة متنوعة من المشاكل المعقدة المتعلقة بحقوق الوصول التي قد تنشأ في نظام متعدد المستخدمين.

في الواقع ، يتم استخدامه ليس فقط لتوفير حقوق الوصول اللازمة للمستخدمين الفرديين - كما أن العديد من عمليات النظام لن تكون قادرة أيضًا على تنفيذ مهامهم إذا لم يتم وصفهم بالعضوية في المجموعات الضرورية. يمكنك عرض ملف / etc / group بشكل قطري - لاحظ عدد عمليات النظام التي تنتمي إلى مجموعاتك الخاصة ...

قائمة مختصرة لمحتويات / etc / group file:

 $ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9: uucp:x:10: man:x:12: proxy:x:13: […] 

عزل عملية الحاوية

ربما تشعر بالقلق من أن العديد من الخدمات التي تعمل على نفس الخادم الخاص بك ستكون معرضة للخطر إذا تم اختراق خدمة واحدة على الأقل من هذه الخدمات؟ أحد الخيارات لتلطيف هذا الضرر الذي يمكن أن يتسبب فيه المستخدمون المهملون أو الضارون هو عزل موارد وعمليات النظام. وبالتالي ، حتى إذا رغب شخص ما في توسيع سلطته إلى ما وراء الحدود الموضوعة ، فلن يتمكن من الوصول الفعلي إلى البيانات.

في السابق ، تقرر حل هذه المشكلة على النحو التالي: تم تخصيص كل جهاز آلي خاص به. ومع ذلك ، فإن المحاكاة الافتراضية تجعل إنشاء بنية "شبكة" أسهل وأرخص بكثير. اليوم ، غالبًا ما يُشار إلى هذه البنية باسم الخدمة المصغرة وتسمح لك بتشغيل العديد من الحاويات في وقت واحد ، في واحدة منها ، على سبيل المثال ، يمكن أن تعمل قاعدة البيانات ، في الأخرى - أباتشي ، وفي الثالث - ملفات الوسائط التي يمكن تضمينها في صفحات الويب الخاصة بك. لا تسمح بنية الخدمات المصغرة بزيادة الإنتاجية والكفاءة بشكل ملحوظ فحسب ، بل تقلل أيضًا بشكل كبير من خطر القرصنة لكل مكون فردي.

"الحاويات" التي أتحدث عنها لا يجب أن تكون مقنعة مع LXC. أصبحت تقنيات الحاويات الأخرى مثل Docker أكثر شعبية اليوم.

التحقق من قيم معرف المستخدم الخطيرة

بالطبع ، يمكن لأي مستخدم لديه حقوق المسؤول توفير وصول الجذر مؤقتًا باستخدام sudo ، ولكن المسؤول فقط هو المسؤول الحقيقي. كما تعلم بالفعل ، من غير الآمن القيام بوظائف منتظمة تحت الوصول إلى الجذر. ومع ذلك ، يمكن أن يحدث هذا - سواء عن طريق الصدفة أو بسبب الاحتيال الضار في البيانات - أن المستخدم العادي سيكون لديه حقوق إدارية دون انقطاع.

في هذه الحالة ، من الجيد أنه ليس من الصعب تحديد هؤلاء المحتالين: معرف المستخدم و / أو المجموعة ، مثل معرف المشرف ، سيكون "0". ألق نظرة على ملف passwd في الدليل / etc /. يحتوي هذا الملف على سجل لكل حساب مستخدم عادي وحساب نظام موجود بالفعل في النظام. يحتوي الحقل الأول على اسم الحساب (في هذه الحالة ، root و ubuntu) ، ويحتوي الحقل الثاني على x بدلاً من كلمة المرور (إذا كانت كلمة المرور موجودة ، فسيتم تشفيرها في ملف / etc / shadow). لكن الحقلين التاليين يحتويان على معرف المستخدم والمجموعة. في حالة ubuntu في هذا المثال ، كلا المعرفين 1000. والمدير ، كما ترون ، لديه أصفار هنا.

 $ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bash 

إذا قابلت مستخدمًا عاديًا في أي وقت بمعرف مستخدم أو مجموعة = 0 ، فيمكنك أن تطمئن إلى أن الأمر ليس نظيفًا وأن الموقف بحاجة إلى إصلاح. طريقة سريعة وسهلة لتحديد هذه المشكلة هي التحقق من passwd باستخدام الأمر awk ، والذي سيعرض جميع الأسطر في الحقل الثالث التي لا يوجد فيها سوى 0. في حالتي (يمكنك الزفير) كان هناك خط واحد فقط - الجذر. يمكنك تشغيله مرة أخرى عن طريق استبدال $ 4 بـ $ 3 - سيؤدي هذا إلى التحقق من حقل معرف المجموعة.

 $ awk -F: '($3 == “0”) {print}' /etc/passwd root:x:0:0:root:/root:/bin/bash 

تدقيق موارد النظام

كلما زاد عدد الأشياء الموجودة في نظامك ، زاد احتمال كسر شيء ما فيه. لذلك ، من الحكمة تتبع ما يعمل وكيف. في هذه الحالة ، نحن نتحدث عن منافذ الشبكة (إذا كان المنفذ "مفتوحًا" ، فعندئذٍ يجب أن يكون مدخلًا) والخدمات (إذا كانت الخدمة نشطة ، فيجب أن يكون من الممكن استخدامها) وحول البرامج المثبتة (إذا تم تثبيت البرنامج ، فيجب أن يكون القدرة على القيام بذلك).

لكي تكون المراجعة مفيدة ، يجب أن تكون منتظمة إلى حد ما. نظرًا لأننا جميعًا منسيين ، فمن الأفضل بكثير كتابة أدوات التدقيق في برنامج نصي خاص لن يتم تنفيذه بشكل منتظم فحسب ، بل من الأفضل تحليل النتائج بحيث تكون أكثر قابلية للقراءة.

ومع ذلك ، أقدم لك هنا ثلاث أدوات تدقيق رئيسية ستساعدك في عرض المنافذ المفتوحة والخدمات النشطة وحزم البرامج غير الضرورية. مهمتك هي أتمتة كل هذا.

فحص المنفذ

يعتبر المنفذ "مفتوحًا" إذا كان المضيف يقوم بتشغيل عملية تستمع للطلبات على هذا المنفذ. مع مراقبة منافذك المفتوحة ، ستفهم بشكل أفضل ما يحدث بالضبط على خادمك.

أنت تعلم بالفعل أنه يجب فتح منافذ HTTP (80) و SSH (22) على خادم ويب عادي ، لذلك لن يفاجئك. ولكن من المهم الانتباه إلى نتائج أخرى غير متوقعة. يعرض الأمر netstat جميع المنافذ المفتوحة ، بالإضافة إلى الكثير من المعلومات حول كيفية استخدامها.

في هذا المثال ، نقوم باختبار خادم متعدد الأغراض نموذجي للغاية ، ويخبر الأمر -n netstat لتمكين جميع المنافذ والعناوين الرقمية. -l يشمل فقط مآخذ الاستماع ، و -p يضيف معرف العملية لبرنامج الاستماع. بطبيعة الحال ، إذا رأيت شيئا - فعل.

 # netstat -npl Active Internet connections (only servers) Proto Local Address Foreign Address State PID/Program name tcp 127.0.0.1:3306 0.0.0.0:* LISTEN 403/mysqld tcp 0.0.0.0:139 0.0.0.0:* LISTEN 270/smbd tcp 0.0.0.0:22 0.0.0.0:* LISTEN 333/sshd tcp 0.0.0.0:445 0.0.0.0:* LISTEN 270/smbd tcp6 :::80 :::* LISTEN 417/apache2 […] 

في السنوات الأخيرة ، ss استخدام ss أكثر وأكثر بدلاً من netstat . فقط في حالة: إذا وجدت نفسك يومًا ما في شركة وسألك شخص ما عن ss ، فإن هذا المثال (الذي يسرد جميع اتصالات SSH القائمة) يجب أن يكون غنيًا بالمعلومات بحيث لا يمكنك مواجهة الأوساخ:

 $ ss -o state established '( dport = :ssh or sport = :ssh )' Netid Recv-Q Send-Q Local Address:Port Peer Address:Port tcp 0 0 10.0.3.1:39874 10.0.3.96:ssh timer:(keepalive,18min,0) 

فحص الخدمات النشطة

إذا أخذت لقطة سريعة للخدمات التي يديرها system ونشطة حاليًا على جهاز الكمبيوتر الخاص بك ، فسيساعد الجهاز في تحديد أي نشاط غير مرغوب فيه. يمكن لأمر systemctl سرد كافة الخدمات الموجودة ، ومن ثم يمكن تضييق قائمتها إلى الخدمات التي يحتوي وصفها على enabled . لذلك سيتم إرجاع الخدمات النشطة فقط.

 # systemctl list-unit-files — type=service — state=enabled autovt@.service enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled getty@.service enabled haveged.service enabled mysql.service enabled networking.service enabled resolvconf.service enabled rsyslog.service enabled ssh.service enabled sshd.service enabled syslog.service enabled systemd-timesyncd.service enabled thermald.service enabled unattended-upgrades.service enabled ureadahead.service enabled 

إذا وجدت شيئًا لا systemctl بوضوح ، يمكنك استخدام الأمر systemctl لإيقاف الخدمة والتأكد من عدم إعادة تشغيله في التمهيد التالي.

 # systemctl stop haveged # systemctl disable haveged 

في الواقع ، لا يوجد شيء مظلم haveged الخدمة haveged التي أتوقف عنها في هذا المثال: إنها أداة يتم تشغيلها غالبًا لإنشاء نشاط نظام خلفية عشوائي عندما أقوم بإنشاء مفاتيح التشفير.
ابحث عن البرامج المثبتة

هل يمكن لشخص ما تثبيت برامج في النظام دون علمك؟ حسنًا ، لتكتشف - عليك أن تنظر. yum list installed الأمر yum list installed أو dpkg — list في حالة Debian / Ubuntu dpkg — list ملخصًا مفصلاً ، وينبغي أن يزيل أمر الإزالة جميع الحزم التي لا نحتاجها.

 # yum list installed # yum remove packageName 

وإليك كيف يتم نفس الشيء في أوبونتو:

 # dpkg --list # apt-get remove packageName 

من المفيد أيضًا تتبع التغييرات التي يتم إجراؤها على ملفات تكوين النظام - سنتحدث عن هذا في الفصل 11.