كيفية تأمين خادم الويب Linux الخاص بك

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

في هذه المقالة - التي تم اقتباسها من الفصل 9 من كتابي Manning ، Linux in Action - سأستكشف أمان موقع الويب من خلال الاستخدام الصحيح لمجموعات النظام ، وعزل العمليات ، والتدقيق المنتظم لموارد النظام. إنها ليست القصة الكاملة (يغطي كتابي في Linux in Action أدوات إضافية مثل تثبيت شهادات TLS والعمل مع SELinux) ، لكنها بداية رائعة.

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

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

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

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

nano datafile.txt chmod 770 datafile.txt

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

يتطلب الأمر useradd (على عكس Debian 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. تترك الوسيطة ubuntu: app-data-group ملكية الملف في أيدي مستخدم ubuntu ، لكنها تغير مجموعتها إلى مجموعة بيانات التطبيق الجديدة.

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

قم بتشغيل الأمر ls بإخراج "طويل" مقابل الملف لعرض أذوناته وحالته الجديدة. لاحظ أنه ، كما هو متوقع ، ubuntu هي مالك الملف ومجموعة بيانات التطبيق هي مجموعتها.

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

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

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

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

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

قائمة جزئية لمحتويات ملف / etc / group:

$ 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: […]

عزل العمليات داخل الحاويات

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

كان النهج القديم للمشكلة هو توفير آلة مادية منفصلة لكل خدمة. لكن المحاكاة الافتراضية يمكن أن تجعل بناء بنية تحتية "منعزلة" أسهل كثيرًا وبأسعار معقولة.

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

بكلمة "حاويات" لا أعني بالضرورة تلك الخاصة بإقناع LXC.

في هذه الأيام ، لهذا النوع من النشر ، أصبحت حاويات Docker أكثر بكثير

جمع. إذا كنت مهتمًا بمعرفة المزيد عن Docker ، فراجع دورات Pluralsight الخاصة بي التي تتناول الموضوع.

البحث عن قيم هوية المستخدم الخطيرة

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

الخبر السار هو أنه من السهل تحديد المحتالين: ستكون أرقام معرفات المستخدم و / أو المجموعة ، مثل الجذر ، صفرًا (0). ألق نظرة على ملف passwd في / etc /. يحتوي هذا الملف على سجل لكل حساب مستخدم عادي ونظام موجود حاليًا. يحتوي الحقل الأول على اسم الحساب (الجذر و 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 ، فأنت تعلم أن هناك شيئًا سيئًا يحدث ويجب عليك العمل على إصلاحه. الطريقة السريعة والسهلة لاكتشاف المشكلة هي تشغيل هذا الأمر awk في مقابل ملف passwd ، الذي سيطبع أي سطر يحتوي حقله الثالث على 0 فقط. في هذه الحالة ، مما يريحني كثيرًا ، كانت النتيجة الوحيدة هي الجذر. يمكنك تشغيله مرة ثانية باستبدال 4 دولارات مقابل 3 دولارات لالتقاط حقل معرف المجموعة.

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

موارد نظام المراجعة

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

For audits to be useful you’ll have to remember to run them once in a while. Since you just know you’re going to forget, you’ll be much better off incorporating your auditing tools into a script that not only executes regularly but, ideally, also parses the results to make them more readable.

Here, however, I’ll focus on introducing you to three key audit tools to help you scan for open ports, active services, and unnecessary software packages. Getting it automated will be your job.

Scanning for open ports

A port is considered “open” if there’s some process running on the host that’s listening on that port for requests. Keeping an eye on your open ports can keep you plugged into what’s really going on with your server.

You already know that a regular web server is probably going to have HTTP (80) and SSH (22) open, so it shouldn’t come as a surprise to come across those. But you’ll really want to focus on other unexpected results. netstat will display open ports along with a wealth of information about how they’re being used.

In this example run against a fairly typical multi-purpose server, -n tells netstat to include the numeric ports and addresses. -l includes only listening sockets, and -p adds the process ID of the listening program. Naturally, if you see something, do something.

# 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 […]

In recent years, ss has begun to replace netstat for many uses. Just in case you find yourself at a party one day and someone asks you about ss , this example (which lists all established SSH connections) should give you enough information to save you from deep embarrassment:

$ 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)

Scanning for active services

Getting a quick snapshot of the systemd-managed services currently enabled on your machine can help you spot activity that doesn’t belong. systemctl can list all existing services, which can then be narrowed down to only those results whose descriptions include enabled. This will return only active services.

# systemctl list-unit-files — type=service — state=enabled [email protected] enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled [email protected] 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

If you do find something that shouldn’t be there, you can use systemctl to both stop the service and make sure it doesn’t start up again with the next boot.

systemctl stop haveged systemctl disable haveged

There’s actually nothing dark and sinister about the haveged service I’m

stopping in this example: it’s a very small tool I often install to generate

random background system activity when I’m creating encryption keys.

Searching for installed software

Could someone or something have installed software on your system without you knowing? Well, how would you know if you don’t look? yum list installed or, on Debian/Ubuntu, dpkg — list will give you the whole briefing, while remove should delete any packages that don’t belong.

yum list installed yum remove packageName

Here’s how it goes on Ubuntu:

dpkg --list apt-get remove packageName

It’s also a good idea to be aware of changes to your system configuration files - which is something I cover in chapter 11.

تم اقتباس هذه المقالة من كتابي Manning "Linux in Action" . هناك الكثير من المرح من حيث جاء هذا ، بما في ذلك دورة مختلطة تسمى Linux in Motion تتكون من أكثر من ساعتين من الفيديو وحوالي 40٪ من نص Linux قيد التشغيل. من يدري ... قد تستمتع أيضًا ببرنامج Learn Amazon Web Services الذي نشرته مؤخرًا في شهر من الغداء .