11.2. مخدم الوب (HTTP)

قرر مديرو النظم في شركة فلكوت استخدام أباتشي، مخدم HTTP، المتوفر في دبيان جيسي بنسخته 2.4.10.

بدائل مخدمات وب أخرى

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

11.2.1. تثبيت أباتشي

كل ما يلزم هو تثبيت الحزمة apache2. تحوي هذه الحزمة كافة الوحدات، بما فيها وحدات المعالجة المتعددة (Multi-Processing Modules أو اختصاراً MPMs) التي تؤثر على أسلوب المعالجة التفرعي الذي ينتهجه أباتشي لمعالجة الطلبات العديدة (كانت هذه تأتي في حزم منفصلة تبدأ أسماؤها بـ apache2-mpm-*). كما أنها ستجلب حزمة apache2-utils التي تحوي أدوات سطر الأوامر التي سنتعرف عليها لاحقاً.

تؤثر MPM المستخدمة بشكل كبير على طريقة تعامل Apache مع الطلبات المتوازية. عند استخدام worker MPM، يستخدم أباتشي ”الخيوط threads“ (عمليات خفيفة)، بينما يستخدم عند اختيار prefork MPM احتياطياً (pool) من عمليات منشأة مسبقاً. أما عند استخدام event MPM فهو يستخدم الخيوط أيضاً، لكن مع إعادة تسليم الاتصالات غير النشطة (خصوصاً تلك التي تبقى مفتوحة عبر ميزة keep-alive في HTTP) إلى خيط إدارة خاص.

كما ثبّت مديرو النظم في شركة فلكوت libapache2-mod-php5 أيضاً بحيث يُضافُ دعم PHP إلى أباتشي. هذا يؤدي لتعطيل event MPM الافتراضية، وتفعيل prefork بدلاً منها، لأن PHP لا تعمل إلا مع تلك MPM بعينها.

أمن التنفيذ بصلاحيات المستخدم www-data

افتراضياً، يعالح أباتشي الطلبات الواردة تحت هوية المستخدم www-data. هذا يعني أن أي ثغرة أمنية في سكربت CGI يُنفّذه أباتشي (في صفحة ديناميكية) لن يعرض النظام كله للخطر، بل الملفات التي يملكها هذا المستخدم فقط.

يسمح استخدام الوحدة suexec بتجاوز هذه القاعدة بحيث تُنفَّذ بعض سكربتات CGI تحت هويّة مستخدم آخر. يُضبَط هذا بتعليمة SuexecUserGroup usergroup في إعدادات أباتشي.

وهناك احتمال آخر وهو استخدام MPM مخصصة لذلك. مثل التي توفرها الحزمة libapache2-mpm-itk. تتمتع MPM هذه بالذات بسلوك مختلف قليلاً: فهي تسمح ”بعزل“ المضيفات الظاهرية (مجموعات الصفحات فعلياً) بحيث يعمل كل منها كمستخدم مختلف. بالتالي، لا تستطيع ثغرة في موقع واحد تعريض الملفات التي تنتمي لمالك موقع آخر للخطر.

أباتشي مخدم تجزيئي (modular)، وهناك مزايا كثيرة تقدمها وحدات (modules) خارجية يُحمّلها البرنامج الرئيسي أثناء مرحلة التهيئة. يُفعّل الإعداد الافتراضي أهم الوحدات شيوعاً، لكن لتفعيل وحدات جديدة يكفي استدعاء a2enmod module؛ولتعطيل وحدة ما، يُستَخدَم الأمر a2dismod module. في الواقع هذه البرامج تُنشِئ فقط (أو تحذف) وصلات رمزية في /etc/apache2/mods-enabled/، تشير إلى الملفات الفعلية (المُخزَّنة في /etc/apache2/mods-available/).

في الإعداد الافتراضي، ينصت مخدم الوب للمنفذ 80 (حسب الإعدادات في /etc/apache2/ports.conf)، ويخدّم الصفحات من المجلد /var/www/html/ (حسب الإعدادات في /etc/apache2/sites-enabled/000-default.conf).

التعمق أكثر إضافة دعم SSL

يتضمن أباتشي 2.2 وحدة SSL اللازمة لاتصالات HTTP الآمنة (HTTPS) افتراضياً. يجب فقط تفعيلها بالأمر a2enmod ssl، الذي يضيف التعليمات التوجيهية المطلوبة لملفات الإعدادات. هناك مثال عن الإعداد متوفر في /etc/apache2/sites-available/default-ssl.conf.

→ http://httpd.apache.org/docs/2.4/mod/mod_ssl.html

يجب الاحتياط أكثر إذا كنت تريد تفضيل اتصالات SSL باستخدام Perfect Forward Secrecy (تستخدم هذه الاتصالات مفاتيح زائلة للجلسات تضمن عدم انكشاف البيانات المشفرة القديمة التي يحتمل أنها التقطت عبر التجسس على الشبكة إذا انكشف مفتاح المخدم السري). ألق نظرة على نصائح موزيلا بالذات:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

11.2.2. إعداد مضيف ظاهري

المضيف الظاهري (virtual host) هو هوية إضافية لمخدم الوب.

يميّز أباتشي بين نوعين من الاستضافة الظاهرية: النوع الذي يعتمد على عنوان IP (أو المنفذ)، والنوع الذي يعتمد على اسم نطاق مخدم الوب. تحتاج الطريقة الأولى لتخصيص عنوان IP مختلف (أو منفذ) لكل موقع، بينما يمكن أن تعمل الثانية على عنوان IP (ومنفذ) وحيد، وتُفرَّق المواقع عن بعضها باسم المضيف (hostname) الذي يرسله عميل HTTP (وهذه لا تعمل إلا مع النسخة 1.1 من بروتوكول HTTP — لحسن الحظ هذه النسخة قديمة لدرجة أن جميع العملاء يستخدمونها فعلاً).

إن التناقص (المستمر) في عناوين IPv4 يدفعنا عادة لتفضيل الطريقة الثانية؛ لكنها تزيد تعقيد الأمور إذا كان المضيفات الظاهرية مضطرة لتوفير HTTPS أيضاً، لأن بروتوكول SSL لم يكن يدعم الاستضافة الظاهرية التي تعتمد على الأسماء قديماً؛ ولا تدعم جميع المتصفحات امتداد SNI (بيان اسم المخدم، Server Name Indication) التي تسمح بالجمع بينهما. عندما تحتاج عدة مواقع HTTPS العمل على المخدم نفسه، سيُفرّق بينها عادة بتشغيلها على منافذ مختلفة أو عناوين IP مختلفة (قد يساعد IPv6 هنا).

يُفعّل الإعداد الافتراضي لأباتشي 2 الاستضافة الظاهرية المعتمدة على الأسماء. بالإضافة لذلك، يُعرَّف مضيف ظاهري في الملف /etc/apache2/sites-enabled/000-default.conf؛ يستخدم هذا المضيف إذا لم يُعثَر على اسم مضيف يطابق طلب العميل.

نظرة سريعة أباتشي يدعم SNI

يدعم المخدم أباتشي امتداداً لبروتوكول SSL يدعى Server Name Indication‏ (SNI). يسمح هذا الامتداد للمتصفح أن يرسل اسم المضيف لمخدم الوب أثناء إنشاء اتصال SSL، قبل إرسال طلب HTTP بكثير، الذي كان يستعمل سابقاً للتعرف على المضيف الظاهري المطلوب من بين المضيفات على المخدم نفسه (الذين لهم عنوان IP والمنفذ نفسهما). يسمح هذا لأباتشي باختيار شهادة SSL الأنسب لمتابعة الطلب.

قبل SNI، كان أباتشي يستخدم دوماً الشهادة المعرفة في المضيف الظاهري الافتراضي. وعندئذ سيعرض العملاء الذين يحاولون الوصول لمضيف ظاهري آخر تحذيرات، لأن الشهادة التي استقبلوها لا توافق الموقع الذي يحاولون الوصول إليه. لحسن الحظ، تعمل معظم المتصفحات اليوم مع SNI؛ بما فيها Microsoft Internet Explorer منذ الإصدار 7.0 (منذ Vista)، وMozilla Firefox منذ الإصدار 2.0، وApple Safari منذ الإصدار 3.2.1، وجميع إصدارات Google Chrome.

حزمة أباتشي التي توفرها دبيان مبنية مع تضمين دعم SNI؛ ولذلك لا حاجة لأي إعداد أو ضبط.

يجب الانتباه أيضاً إلى ضمان تفعيل TLSv1 على المضيف الظاهري الأول (الذي يستخدم افتراضياً)، لأن أباتشي يستخدم بارمترات هذا المضيف الظاهري لبدء الاتصالات الآمنة، ومن الأفضل لهذه البارمترات أن تسمح بذلك!

بعد ذلك، يُعرّف كل مضيف ظاهري إضافي بملف يُخزَّن في /etc/apache2/sites-available/. بالتالي، لإعداد موقع وب للنطاق falcot.org يكفي إنشاء الملف التالي، ثم تفعيل المضيف الظاهري باستخدام a2ensite www.falcot.org.

مثال 11.16. الملف /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>
ServerName www.falcot.org
ServerAlias falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>

يستخدم المخدم أباتشي، كما هي إعداداته حتى الآن، ملف سجلات وحيد لجميع المضيفات الظاهرية (رغم أن تغيير هذا ممكن عبر إضافة تعليمات CustomLog في تعاريف المضيفات الظاهرية). من المنطقي إذن تعديل صيغة ملف السجلات هذا بحيث يتضمن اسم المضيف الظاهري. يمكن تحقيق هذا عبر إنشاء ملف /etc/apache2/conf-available/customlog.conf يُعرِّف صيغة جديدة لكافة ملفات السجلات (باستخدام التعليمة التوجيهية LogFormat) وتفعيله بالأمر a2enconf customlog. كما يجب أيضاً إزالة (أو تعليق) سطر CustomLog من الملف /etc/apache2/sites-available/000-default.conf.

مثال 11.17. الملف /etc/apache2/conf.d/customlog.conf

# New log format including (virtual) host name
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Now let's use this "vhost" format by default
CustomLog /var/log/apache2/access.log vhost

11.2.3. التعليمات التوجيهية الشائعة

يستعرض هذا القسم سريعاً بعض تعليمات إعداد أباتشي شائعة الاستخدام.

يحوي ملف الإعداد الرئيسي عدة كتل Directory عادة؛ تسمح بتحديد تصرفات المخدم المختلفة حسب موقع الملف الذي يقدمه. هذه الكتل تحوي عادة تعليمتي Options و AllowOverride.

مثال 11.18. كتلة Directory

<Directory /var/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>

تحوي تعليمة DirectoryIndex قائمة الملفات لتجربتها عند الرد على العميل عندما يطلب مجلداً. يستخدم أول ملف متوفر ويرسل كرد على الطلب.

تُتبَع التعليمة Options بقائمة من الخيارات المطلوب تفعيلها. تُعطّل القيمة None جميع الخيارات؛ وفي المقابل، تُفعِّلها All جميعاً عدا MultiViews. من الخيارات المتاحة:

تشير ExecCGI إلى إمكانية تنفيذ سكربتات CGI.
تسمح FollowSymlinks للمخدم بتتبع الروابط الرمزية، ويطلب منه إرسال محتويات أهداف هذه الروابط في الردود.
تطلب SymlinksIfOwnerMatch من المخدم تتبع الروابط الرمزية أيضاً، لكن فقط عندما ينتمي الرابط والهدف للمالك نفسه.
تُفعّل Includes ميزة Server Side Includes (أو SSI اختصاراً). وهي تعليمات مضمنة في صفحات HTML وتُنفّذ آنياً عند كل طلب.
تطلب Indexes من المخدم سرد محتويات المجلد إذا أشار طلب HTTP الذي أرسله العميل لمجلد لا يحوي ملف فهرس (أي عندما لا يحوي المجلد أي ملف من الملفات المذكورة في DirectoryIndex).
تُفعّل MultiViews التفاوض على المحتوى؛ يمكن أن يستخدم المخدم هذا لإعادة صفحة وب توافق اللغة المفضلة حسب إعدادات المتصفح.

تسرد التعليمة AllowOverride جميع الخيارات التي يمكن تفعيلها أو تعطيلها باستخدام ملفات .htaccess. أحد الاستخدامات الشائعة لها هو تقييد ExecCGI، بحيث يختار مدير النظام المستخدمين الذين يحق لهم تشغيل البرامج تحت هوية مخدم الوب (المستخدم www-data).

11.2.3.1. طلب المصادقة

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

مثال 11.19. ملف .htaccess يطلب المصادقة

Require valid-user
AuthName "Private directory"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

أمن لا أمن

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

يحوي الملف /etc/apache2/authfiles/htpasswd-private قائمة المستخدمين وكلمات السر؛ ومن الشائع تعديله باستخدام الأمر htpasswd. مثلاً، يُستَخدم الأمر التالي لإضافة مستخدم أو لتغيير كلمة سره:

# htpasswd /etc/apache2/authfiles/htpasswd-private user
New password:
Re-type new password:
Adding password for user user

11.2.3.2. تقييد الوصول

تتحكم تعليمة Require بتقييد الوصول للمجلد (ومجلداته الفرعية).

يمكن استخدامها لتقييد الوصول اعتماداً على معايير كثيرة؛ سنكتفي نحن بشرح تقييد الوصول اعتماداً على عنوان IP الخاص بالعميل، لكن يمكن جعل القيود أقوى من ذلك بكثير، خصوصاً عند جمع عدة تعليمات Require معاً ضمن كتلة RequireAll.

مثال 11.20. السماح بالوصول من الشبكة المحلية فقط

Require ip 192.168.0.0/16

بدائل الصيغة القديمة

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

تتحكم تعليمتا Allow from وDeny from بتقييد الوصول للمجلد (ومجلداته الفرعية).

تحدد تعليمة Order ترتيب تطبيق تعليمتي Allow from وDeny from؛ والأولوية للتعليمة التي تُطبّق أخيراً. بشكل أوضح، تسمح تعليمة Order deny,allow للعميل بالوصول إذا لم تنطبق تعليمة Deny from عليه، أو إذا انطبقت عليه تعليمة Allow from. وبالعكس، ترفض Order allow,deny وصوله إذا لم تنطبق عليه تعليمة Allow from (أو إذا انطبق عليه تعليمة Deny from).

يمكن أن تلحق تعليمتي Allow from وDeny from بعنوان IP، أو شبكة (مثل 192.168.0.0/255.255.255.0، أو 192.168.0.0/24 أو حتى 192.168.0)، أو اسم مضيف أو اسم نطاق، أو الكلمة المفتاحية all، التي تشير للجميع.

مثلاً، لرفض الاتصالات افتراضياً مع السماح بالاتصال من الشبكة المحلية، يمكنك استخدام ما يلي:

Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.4. محللات السجلات

كثيراً ما يُثبّت محلل سجلات على مخدم الوب؛ لأنه يعطي مديري النظم فكرة دقيقة عن أنماط استخدام المخدم.

اختار مديرو النظم في شركة فلكوت AWStats ‏(Advanced Web Statistics، إحصائيات الوب المتقدمة) لتحليل ملفات سجلات أباتشي.

أولى خطوات الإعداد هي تخصيص الملف /etc/awstats/awstats.conf. لقد ترك مديرو النظم في فلكوت الملف دون تعديل عدا البارمترات التالية:

LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
LoadPlugin="tooltips"

جميع هذه البارمترات مشروحة في التعليقات في ملف القالب. بالأخص، يحدد المتغيران LogFile وLogFormat موقع ملف السجلات وصيغة المعلومات التي يحويها؛ ويسرد SiteDomain وHostAliases الأسماء المتنوعة التي يعرف بها الموقع الرئيسي.

يجب ألا تعطى القيمة 1 للمتغير DNSLookup في المواقع عالية الطلب؛ أما بالنسبة للمواقع الأصغر، مثل موقع فلكوت المعروض أعلاه، فيسمح هذا الخيار بالحصول على تقارير أوضح تتضمن الأسماء الكاملة للأجهزة بدلاً من عناوين IP.

يمكن تفعيل AWstats أيضاً للمضيفات الظاهرية الأخرى؛ يحتاج كل مضيف لملف إعداد خاص، مثل /etc/awstats/awstats.www.falcot.org.conf.

مثال 11.21. ملف إعداد AWstats لمضيف ظاهري

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"

يستخدم AWstats أيقونات عديدة مُخزّنة في المجلد /usr/share/awstats/icon/. حتى تتوفر هذه الأيقونات على موقع الوب، يجب تعديل إعدادات أباتشي وإضافة التعليمة التوجيهية التالية:

Alias /awstats-icon/ /usr/share/awstats/icon/

بعد بضعة دقائق (وبعد أن يعمل السكربت بضع مرات)، تصبح النتائج متوفرة على الموقع:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

تحذير تدوير ملفات السجلات

حتى تأخذ الإحصائيات جميع السجلات بعين الاعتبار، يجب تشغيل AWStats مباشرة قبل تدوير ملفات سجلات أباتشي. بالاطلاع على التعليمة prerotate في الملف /etc/logrotate.d/apache2، يمكن حل هذه المشكلة بإضافة رابط رمزي للسكربت /usr/share/awstats/tools/update.sh في المجلد /etc/logrotate.d/httpd-prerotate:

$ cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
  daily
  missingok
  rotate 14
  compress
  delaycompress
  notifempty
  create 644 root adm
  sharedscripts
  postrotate
    if /etc/init.d/apache2 status > /dev/null ; then \
      /etc/init.d/apache2 reload > /dev/null; \
    fi;
  endscript
  prerotate
    if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
      run-parts /etc/logrotate.d/httpd-prerotate; \
    fi; \
  endscript
}
$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate
$ sudo ln -sf /usr/share/awstats/tools/update.sh \
  /etc/logrotate.d/httpd-prerotate/awstats

لاحظ أيضاً أنه يجب منح صلاحيات قراءة ملفات السجلات التي ينشئها logrotate للجميع، وخصوصاً AWstats. في المثال السابق، يضمن السطر create 644 root adm ذلك (بدلاً من الصلاحيات الافتراضية 640).