امنیت آپاچی سرور

2,212 تعداد نمایش

نکات امنیتی ذکر شده، در این سند پیرامون سرور آپاچی نسخه 2.2.x و 2.4.x بوده هر چند که در مواردی با یکدیگر مشابه ولی در برخی موارد نیز با یکدیگر متفاوت می باشد. این موارد در هر بخش زیر بیان شده است.

در سند زیر نحوه پیاده سازی هر نسخه ذکر شده است.

ضمناً در بخش 13، به طور اختصاصی به نکات امنیتی Apache Http Server نسخه 2.4.x پرداخته شده است.

قبل از ایجاد تغییرات در وب سرور آپاچی شما بایستی نکات پایه ای درباره ی آپاچی سرور را بدانید.

دایرکتوری ریشه اسناد در مسیر مقابل قرار دارد : /var/www/html یا /var/www
فایل پیکربندی (configuration) اصلی : /etc/hhtpd/conf/httpd.conf در لینوکس های RHEL/CentOs/Fedora و /etc/apache2/apache2.conf در لینوکس های Debian/Ubuntu.
پورت پیش فرض HTTP: 80 TCP
پورت پیش فرض HTTPS: 443 TCP
برای تست کردن کردن فایل تنظیمات پیکربندی و syntax آن از دستور مقابل استفاده می شود: httpd –t
دسترسی به فایل های log وب سرور در مسیر مقابل قرار دارد : /var/log/httpd/access_log
فایل های Error وب سرور در مسیر مقابل قرار دارد : /var/log/httpd/error_log

عناوين مطالب: '

تنظیمات
پیوست
جدول ممیزي

تنظیمات

1-SCWS: برنامه ریزي و راه اندازي

1-1-SCWS: تهیه چک لیست برنامه ریزي پیش از راه اندازي

شرح اجمالی:

می بایست پیش و یا هنگام نصب و راه اندازي موارد و توصیه هاي زیر بررسی گردند:

بررسی و اجراي سیاست هاي امنیتی داخلی سازمان و موارد مرتبط با امنیت نرم افزارهاي تحت وب
پیاده سازي و ایجاد زیرساخت امن شبکه با توجه به کنترل دسترسی به/ از وب سرور و با استفاده از تجهیزاتی چون فایروال، روتر و سوییچ
امن سازي سیستم عامل وب سرور بوسیله حداقل سازي سرویس هاي مربوط به شبکه، اعمال مناسب بسته هاي ارائه شده و پیکربندي امن آن با توجه به معیار امنیت اینترنتی توصیه شده براي هر پلتفرم
پیاده سازی فرآیندهاي نظارتی مرکزي مربوط به لاگ
اجراي مکانیزم و فرآیندهاي مربوط به پایش فضاي حافظه و بازبینی لاگ ها در سرور
آموزش و آگاهی رسانی برنامه نویسان به منظور توسعه برنامه هاي کاربردي امن و ادغام امنیت در چرخه عمر توسعه نرم افزار
اطمینان از محفوظ ماندن اطلاعات ثبت شده مربوط به دامنه وب و عدم وجود اطلاعات حساس و حیاتی به منظور جلوگیري از حملات و خطراتی همچون مهندسی اجتماعی (نام هاي فردي ، (POCDialing (شماره هاي تلفن) و Brute Force (آدرس هاي ایمیلی که مطابق با نام کاربري هاي سیستم واقعی هستند)
پیکربندي صحیح و امن سرور DNS به منظور جلوگیري از حملات مخرب با توجه به توصیه هاي CIS

BIND DNS Benchmark

پیاده سازی یک سیستم تشخیص نفوذ شبکه (IDS) به منظور نظارت بر حملات علیه وب سرور

نحوه پیاده سازی:

مطابق با شرح اجمالی پیاده سازي گردد.

1-SCWS: عدم نصب سرویس هاي مختلف بر روي یک سرور

شرح اجمالی:

سرور اغلب طیف وسیعی از سرویس هاي پیش فرض غیر ضروري را ارائه می دهد که برخی از این سرویس ها، سرور را از لحاظ امنیتی در معرض خطرات جدي قرار می دهند. یک سرور می تواند خدمات زیادي انجام دهد این بدان معنا نمی باشد که می بایست بطور حتم همه این خدمات باید فعال شوند. لذا می بایست تعداد خدمات، سرویس ها و فرآیندهاي پشت صحنه اي که بر روي سروري که میزبان Apache است ، اجرا ، به موارد ضروري محدود شده، و وب سرور تنها کارکرد اصلی سرور شود.

نحوه پیاده سازی:

به منظور اجراي این بند، می بایست سرویس هاي غیرضروري سیستم عامل خود را غیرفعال و یا حذف نمایید. در سیستم عامل لینوکس توزیع Red Hat می بایست فرمان زیر اجرا گردد.

chkconfig <servicename> off

: SCWS-1 نصب Apache

شرح اجمالی:

معیار CIS Apache (Center for Internet Security) حاضر، در اکثر موارد استفاده از آپاچی باینري ارائه شده توسط فروشنده به منظور کاهش دوباره کاري و افزایش اثربخشی تعمیر و نگهداري و امنیت پیشنهاد می کند. با این حال، براي حفظ معیار به صورت عمومی و قابل استفاده و انطباق با کلیه پلت فرم های یونیکس/ لینوکس، یک منبع پیش فرض براي این معیار ایجاد و استفاده شده است.

نحوه پیاده سازی:

نصب و راه اندازي بستگی زیادي به پلتفرم سیستم عامل دارد. در خصوص توزیع هاي سورس می توان از لینک

http://httpd. apache. org/docs/2. 2/install. Html بهره برده و در خصوص توزیع

Linux 5 Red Hat Enterprise می توان از دستور زیر استفاده نمود.

# yum install httpd

2-SCWS: به حداقل رساندن ماژول هاي Apache

2–SCWS: فعال نمودن ماژول هاي احراز هویت و اعطاي مجوز ضروري

شرح اجمالی:

ماژول هایی با عنوان authn_* به منظور احراز هویت و ماژول هاي authz_* جهت ارائه مجوز می باشند. همچنین Apache شامل دو نوع احراز هویت basic و digest می باشد. لذا تنها ماژول هایی را که مورد نیاز می باشند، فعال نمایید.

نحوه پیاده سازی:

به منظور تصمیم گیري درخصوص نصب ماژول هاي لازم و ضروري از مستندات و توضیحاتی که براي هر ماژول موجود است، می توان استفاده نمود. البته برخی ماژول ها به صورت پیش فرض مورد نیاز نیستند و البته غیرفعال هستند. در ضمن یکسري از ماژول ها به صورت dynamic در آپاچی وجود دارند و بوسیله کامنت کردن یا حذف دستور LoadModule از فایل پیکربندي (معمولا http. conf) می توان آن ها را غیرفعال نمود.

2–SCWS: فعال نمودن ماژول پیکربندي لاگ

شرح اجمالی:

ماژول log_config قابلیت انعطاف ثبت وقایع درخواست هاي کلاینت را فراهم کرده و پیکربندي به منظور اینکه چه نوع اطلاعاتی درفایل لاگ ذخیره می شود را فراهم می آورد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

در خصوص توزیع هاي سورس با ماژول هاي static، اسکریپت ./configure آپاچی را بدون اینکه Script

. فعال شده باشد، اجرا نمایید –disable-log-config ، Option

$ cd $DOWNLOAD/httpd-2. 2. 22

$. /configure

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند ، دستور LoadModule در صورتی که در حال حاضر در پیکربندي آپاچی به صورت زیر کامنت گذاري نشده است، اضافه و یا اصلاح نمایید.

LoadModule log_config_module modules/mod_log_config. so

2–SCWS: غیرفعال نمودن ماژول WebDAV

شرح اجمالی:

ماژول هاي mod_dav و mod_dav_fs آپاچی از قابلیت WebDAV (احراز هویت و نسخه بندي توزیع شده مبتنی بر وب) براي آپاچی پشتیبانی می کنند. WebDAV یک افزونه براي پروتکل HTTP است که به کلاینت اجازه ایجاد، جابجایی، تغییر و یا حذف فایل ها و منابع را بر روي وب سرور می دهد.

نحوه پیاده سازی:

به منظور پیاده سازی این تنظیم و غیرفعال کردن WebDAV می بایست هر یک از موارد زیر را انجام داد:

در خصوص توزیع هاي سورس با ماژول هاي static اسکریپت ./configure آپاچی را بدون اینکه آیتم هاي mod_dav و mod_dav_fs در Script Option مربوط به enable-modules=configure– فعال شده باشد، اجرا نمایید.

$ cd $DOWNLOAD/httpd-2. 2. 22

$. /configure

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند ، دستور LoadModule را براي ماژول هاي mod_dav و mod_dav_fs از فایل conf حذف و یا کامنت گذاري نمایید.

##LoadModule dav_module modules/mod_dav. so

##LoadModule dav_fs_module modules/mod_dav_fs. so

2–SCWS: غیرفعال نمودن ماژول Status

شرح اجمالی:

ماژول mod_status در Apache وضعیت و آمار فعلی سرور را فراهم می کند.

نحوه پیاده سازی:

به منظور پیاده سازی این تنظیم و غیرفعال کردن mod_status می بایست هر یک از موارد زیر را انجام داد:

در خصوص توزیع هاي سورس با ماژول هاي static، اسکریپت ./configure آپاچی را بدون اینکه Script

فعال شده باشد، اجرا نمایید. –disable-status configure مربوط به Option

$ cd $DOWNLOAD/httpd-2. 2. 22

$. /configure –disable-status

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند، دستور LoadModule را براي ماژول mod_status از فایل conf حذف و یا کامنت گذاري نمایید.

##LoadModule status_module modules/mod_status. so

2–SCWS: غیرفعال نمودن ماژول Autoindex

شرح اجمالی:

ماژول autoindex به طور خودکار صفحات وبی شامل محتویات دایرکتوري ها بر روي سرور را ایجاد می کند، که به طور معمول هنگامی استفاده می شوند که نیازي به ایجاد یک index.html نیست.

نحوه پیاده سازی:

به منظور پیاده سازی این تنظیم و غیرفعال کردن mod_autoindex می بایست هر یک از موارد زیر را انجام داد:

در خصوص توزیع هاي سورس با ماژول هاي static، اسکریپت ./configure آپاچی را بدون اینکه Script

. فعال شده باشد، اجرا نمایید –disable-autoindex configure مربوط به Option

$ cd $DOWNLOAD/httpd-2. 2. 22

$. /configure -disable-autoindex

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند، دستور LoadModule را براي ماژول mod_autoindex از فایل conf حذف و یا کامنت گذاري نمایید.

## LoadModule autoindex_module modules/mod_autoindex. so

2 –SCWS: غیرفعال نمودن ماژول Proxy

شرح اجمالی:

سرور با استفاده از ماژول هاي پروکسی Apache به عنوان یک پروکسی (Forward proxy یا reverse proxy) از HTTP و پروتکل هاي دیگر با ماژول هاي دیگر پروکسی بارگذاري می شود. اگر نصب Apache براي درخواست به / یا از شبکه دیگري در نظر گرفته نشده باشد، در آن صورت ماژول پروکسی نباید بارگذاري شود.

نحوه پیاده سازی:

به منظور پیاده سازی این تنظیم و غیرفعال کردن ماژول proxy می بایست هر یک از موارد زیر را انجام داد:

در خصوص توزیع هاي سورس با ماژول هاي static اسکریپت ./configure آپاچی را بدون اینکه آیتم

–enable-modules=configure مربوط به Script Option در mod_proxy فعال شده باشد، اجرا نمایید.

$ cd $DOWNLOAD/httpd-2. 2. 22

$. /configure

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند ، دستور LoadModule را براي ماژول mod_proxy و هر ماژول پروکسی دیگر از فایل conf حذف و یا کامنت گذاري نمایید.

##LoadModule proxy_module modules/mod_proxy. so

##LoadModule proxy_balancer_module modules/mod_proxy_balancer. so

##LoadModule proxy_ftp_module modules/mod_proxy_ftp. so

##LoadModule proxy_http_module modules/mod_proxy_http. so

##LoadModule proxy_connect_module modules/mod_proxy_connect. so

##LoadModule proxy_ajp_module modules/mod_proxy_ajp. so

2–SCWS: غیرفعال نمودن ماژول هاي دایرکتوری هاي کاربر

شرح اجمالی:

می بایست دستور UserDir غیرفعال شود تا بدین وسیله دایرکتوری هاي خانگی کاربر از طریق وب با یک علامت مد( ~) قبل از نام کاربري، قابل دسترسی نباشند. این دستور همچنین نام مسیر دایرکتوري قابل دسترس را نشان می دهد.. به عنوان مثال:

http://example. com/~ralph/ ممکن است به یک زیردایرکتوري public_html از دایرکتوري خانگی کاربر ralph دسترسی داشته باشد.
دستور /ممکن است /~rootرا به دایرکتوري ریشه (/) نگاشت کند.

نحوه پیاده سازی:

به منظور پیاده سازی این تنظیم و غیرفعال کردن ماژول user directories می بایست هر یک از موارد زیر انجام گیرد:

در خصوص توزیع هاي سورس با ماژول هاي static اسکریپت./configure آپاچی را با آیتم mod_proxy

. اجرا نمایید –disable-userdir configure مربوط به Script Option در

$ cd $DOWNLOAD/httpd2. 2. 22

$. /configure –disable-userdir

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند، دستور LoadModule را براي ماژول mod_userdir از فایل conf حذف و یا کامنت گذاري نمایید.

##LoadModule userdir_module modules/mod_userdir. so

2–SCWS: غیرفعال نمودن ماژول Info

شرح اجمالی:

ماژول mod_info اطلاعاتی در مورد پیکربندي سرور از طریق دسترسی به server-info/، ارائه می کند.

نحوه پیاده سازی:

به منظور پیاده سازی این تنظیم و غیرفعال کردن ماژول mod_info می بایست هر یک از موارد زیر را انجام داد:

در خصوص توزیع هاي سورس با ماژول هاي static اسکریپت . /configure آپاچی را بدون اینکه آیتم

–enable-modules=configure مربوط به Script Option در mod_info فعال شده باشد، اجرا نمایید

$ cd $DOWNLOAD/httpd2.2.22

$. /configure

در خصوص ماژول هایی که به صورت پویا بارگذاري شده اند، دستور LoadModule را براي ماژول mod_info از فایل conf حذف و یا کامنت گذاري نمایید.

##LoadModule info_module modules/mod_info. so

3-SCWS: اصول، مجوزها و مالکیت

3-1-SCWS: اجراي وب سرور Apache با کاربري غیر root

شرح اجمالی:

اگرچه آپاچی معمولاً با دسترسی هاي root به منظور شنود به پورت 80 و 443 آغاز می شود، اما به منظور انجام سرویس دهی می تواند و می بایست کاربري غیر از کاربر ریشه اجرا شود. از دستورهاي User و Group به منظور تعیین کاربر و گروهی که ایجاد کننده فرآیندهاي آپاچی فرض می شوند، استفاده می گردد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

در صورتی که Apache User و Apache Group ایجاد نگردیده است، یک حساب کاربري و گروه منحصر بفرد را ایجاد نمایید:

# groupadd -r apache

# useradd apache -r -g apache -d /var/www -s /sbin/nologin

پیکربندي User و Group در فایل پیکربندي conf آپاچی:

User apache

Group apache

تنظیمات مربوطه در آپاچی نسخه 2.4.x بدین صورت می باشد.

# groupadd apache

# useradd –G apache apache

مالکیت دایرکتوری نصب آپاچی را به کاربر غیر ممتاز بدهید.

# chown –R apache:apache /opt/apache

پیکربندي User و Group در فایل پیکربندي httpd.conf آپاچی:

User apache

Group apache

3-SCWS: درنظر گرفتن پوسته نامعتبر براي حساب کاربري آپاچی

شرح اجمالی:

نباید از حساب apache به عنوان یک حساب کاربري ورود عادي استفاده شود، و می بایست یک پوسته نامعتبر یا nologin به منظور اطمینان از عدم استفاده از این حساب براي ورود در نظر گرفته شود.

نحوه پیاده سازی:

تغییر حساب apache به استفاده از یک پوسته nologin یا یک پوسته نامعتبر همانند /dev/null :

# chsh -s /sbin/nologin apache

3–SCWS: قفل نمودن حساب کاربري Apache

شرح اجمالی:

حساب کاربري که آپاچی تحت آن اجرا می شود نباید یک رمز عبور معتبر داشته باشد، اما می بایست غیرفعال گردد.

نحوه پیاده سازی:

از دستور passwd به منظور غیرفعال نمودن حساب کاربري آپاچی استفاده نمایید:

# passwd -l apache

3–SCWS: تنظیم مالکیت بر روي دایرکتوری ها و فایل هاي Apache

شرح اجمالی:

دایرکتوري ها و فایل هاي آپاچی بایستی متعلق به root باشند. این امر در مورد تمام دایرکتوري هاي نرم افزار آپاچی و فایل هاي نصب شده نیز صدق می کند.

نحوه پیاده سازی:

پیاده سازی موارد زیر:

:/usr/local/apache2 مانند $APACHE_PREFIX تنظیم مالکیت در دایرکتوری هاي

$ chown -R root $APACHE_PREFIX

3–SCWS: تنظیم شناسه گروه بر روي دایرکتوری ها و فایل هاي Apache

شرح اجمالی:

می بایست دایرکتوری ها و فایل هاي آپاچی براي داشتن یک شناسه گروه از root، یا یک گروه معادل root تنظیم شوند. این امر در مورد تمام دایرکتوري هاي نرم افزار آپاچی و فایل هاي نصب شده نیز به کار برده می شود. تنها مورد استثنا این است که ریشه اصلی پوشه APACHE_PREFIX/htdocs) apache$) به یک گروه تعیین شده نیاز دارد تا به محتواي وب اجازه دهد از طریق یک فرآیند مدیریت تغییر (مانند webupdate)، بروزرسانی شود.

نحوه پیاده سازی:

:/usr/local/apache2 مانند $APACHE_PREFIX تنظیم مالکیت در دایرکتوری هاي

$ chown -R root $APACHE_PREFIX

3–SCWS: محدود کردن دسترسی هاي Write بر روي دایرکتوری ها و فایل هاي Apache

شرح اجمالی:

به طور کلی مجوزهاي دایرکتوری هاي آپاچی و مجوزهاي فایل می بایست rwxr-xr-x (755) باشد، مگر این که نیاز به دسترسی اجرایی داشته باشد. این امر در مورد دایرکتوری هاي نرم افزار آپاچی و فایل هاي نصب شده به استثنا ریشه اصلی پوشه APACHE_PREFIX/htdocs$ apache اعمال می شود. دایرکتوری ها و فایل ها در مسیر اصلی پوشه ممکن است به یک گروه با دسترسی نوشتن انتساب شوند تا به محتواي وب اجازه بروزرسانی دهند. علاوه بر این، می بایست دایرکتوري /bin و قابلیت اجرایی به طوري تنظیم گردد که توسط سایرین قابل خواندن نباشد.

نحوه پیاده سازی:

انجام مورد زیر به منظور حذف دیگر دسترسی روي دایرکتوری هاي $APACHE_PREFIX.

# chmod -R o-w $APACHE_PREFIX

تنظیمات مربوطه در آپاچی نسخه 2.4.x بدین صورت می باشد.

در آپاچی نسخه 2.4.x به دایرکتوری $web_server بروید:

مجوز فولدر های bin و conf را به صورت زیر تغییر دهید:

# chmod –R 750 bin conf

3–SCWS: امن نمودن دایرکتوري Core Dump

شرح اجمالی:

دستور CoreDumpDirectory براي مشخص کردن مسیري که تلاش هاي آپاچی را به منظور ایجاد core dump، نشان می دهد، بکار می رود. دایرکتوري پیش فرض، دایرکتوري ServerRoot می باشد، با این حال core dump ها در سیستم هاي لینوکسی به صورت پیش فرض غیرفعال است. در رویدادهایی که نیاز به core dump ها می باشد، می بایست دایرکتوري قابلیت نوشتن را توسط آپاچی داشته باشد و باید نیازمندي هاي امنیتی که در پایین و در قسمت پیاده سازی تعریف شده است را تأمین کند.

نحوه پیاده سازی:

دستور CoreDumpDirectory را از فایل هاي پیکربندي Apache حذف کنید یا از اینکه دایرکتوري پیکربندي شده از شرایط زیر برخوردار است اطمینان حاصل کنید.

($APACHE_PREFIX/htdocs). وجود ندارد apache در مسیر اصلی پوشه ، CoreDumpDirectory
بایستی در ریشه بوده و مالکیت یک گروه Apache را داشته باشد (همانطور که به وسیله ي دستور گروه ، تعریف شده)

# chown root:apache /var/log/httpd

نباید هیچ مجوز دسترسی read-write-search براي دیگر کاربران وجود داشته باشد.

# chmod o-rwx /var/log/httpd

SCWS-3-8: امن نمودن Lock File

شرح اجمالی:

دستور LockFile سبب ایجاد مسیري به فایل Lock در زمانی می شود که آپاچی از دستورهاي فراخوانی سیستمی مانند fcntl(2) یا flock(2) براي پیاده سازی یک mutex (قفل) استفاده می کند.

اکثر سیستم هاي لینوکس به طور پیش فرض از سمافورها به جاي آن استفاده می کنند، در صورتی که ممکن است دستوري اعمال و یا به کار برده نشود. با این حال مسئله مهم این است که، در صورتی که یک فایل Lock مورد استفاده قرار گرفت، این فایل در یک دایرکتوري محلی باشد که توسط دیگر کاربران writable نباشد.

نحوه پیاده سازی:

مسیر دایرکتوري اي را پیدا کنید که LockFile در آن ایجاد می شود که به صورت پیش فرض، دایرکتوري ServerRoot/logs است.
اگر مسیر یک دایرکتوري در DocumentRoot است، دایرکتوري را اصلاح نمایید.
مالکیت و گروه را به ریشه تغییر دهید: اگر در حال حاضر، ریشه به حساب نمی آید.
مجوزها را تغییر دهید، به طوري که دایرکتوري تنها توسط ریشه یا کاربري که Apache ابتدا با او آغاز به کار می کند، قابل نوشتن باشد (مقدار پیش فرض، ریشه است. )
بررسی نمایید که دایرکتوري فایل قفل، به جاي یک سیستم فایل نصب شده ي NFS، بر روي یک هارد دیسک نصب شده ي محلی باشد.

3-9–SCWS: امن نمودن Pid فایل

شرح اجمالی:

دستور PidFile مسیر فایل process ID را تنظیم می کند که سرور براي آن Process ID سرور را ثبت می کند، که البته براي ارسال یک سیگنال به Process سرور یا بررسی سلامت Process مفید است.

نحوه پیاده سازی:

دایرکتوري اي را پیدا کنید که PidFile در آن ایجاد می شود. مقدار پیش فرض، دایرکتوري

. است ServerRoot/logs

اگر PidFile در یک دایرکتوري در Apache DocumentRoot است، دایرکتوري را اصلاح کنید.
مالکیت و گروه را به ریشه تغییر دهید: در صورتی که در حال حاضر ریشه نباشد.
مجوزها را طوري را تغییر دهید که دایرکتوري، تنها توسط ریشه یا کاربري که Apache ابتدا با او آغاز به کار می کند، قابل نوشتن باشد (مقدار پیش فرض، ریشه می باشد).

SCWS-3-10: امن نمودن فایل ScoreBoard

شرح اجمالی:

دستور ScoreBoardFile مسیر فایلی را تنظیم می کند که سرور براي ارتباطات بین IPC) Process) در میان Processهاي آپاچی از آن استفاده می کند. در اکثر پلت فرم های لینوکس، حافظه به اشتراك گذاشته شده، به جاي یک فایل در سیستم فایل مورد استفاده قرار خواهد گرفت، بنابراین به طور کلی این دستور مورد نیاز نبوده و لازم نیست تا دایرکتوري مجزایی تعیین شود. با این حال، اگر دستور مشخص باشد در اینصورت آپاچی از فایل پیکربندي شده براي ارتباطات بین Process استفاده خواهد کرد. هرچند که در صورت محرز شدن این موضوع می بایست در یک دایرکتوري امن قرار داده شود.

نحوه پیاده سازی:

بررسی نمایید که آیا ScoreBoardFile در هیچ یک از فایل هاي پیکربندي Apache، مشخص شده است یا خیر. اگر جواب منفی بود، هیچ تغییري لازم نیست.
اگر دستور، موجود باشد، دایرکتوري اي را پیدا کنید که ScoreBoardFile در آن ایجاد می شود. مقدار پیش فرض، دایرکتوري ServerRoot/logs است.
اگر ScoreBoardFile در یک دایرکتوري در Apache DocumentRoot است، دایرکتوري را اصلاح نمایید.
اگر مالکیت و گروه root نیست آن را به root:root تغییر دهید.
مجوزها را به گونه اي تغییر دهید که دایرکتوري، تنها توسط root یا کاربري که Apache ابتدا با او آغاز به کار می کند، قابل نوشتن باشد (مقدار پیش فرض، ریشه است.)
بررسی نمایید که دایرکتوري فایل scoreboard، به جاي یک سیستم فایل نصب شده ي NFS، بر روي یک هارد دیسک نصب شده ي محلی باشد.

SCWS-3-11: محدود کردن دسترسی هاي نوشتن گروه بر روي دایرکتوری ها و فایل هاي Apache

شرح اجمالی:

به طور کلی می بایست مجوزهاي گروهی براي دایرکتوری هاي آپاچی، r-x بوده و مجوزهاي فایل نیز می بایست همین باشند، مگر اینکه قابل اجرا نباشند و قابل اجرا بودن آن ها نیز مناسب نباشد. این امر در مورد تمام دایرکتوری ها و فایل هاي نصب شده نرم افزار آپاچی به استثناء ریشه اصلی پوشه $DOCROOT تعریف شده توسط DocumentRoot آپاچی و به طور پیش فرض براي $APACHE_PREFIX/htdocs نیز به کار می رود. ممکن است یک گروه توسعه وب براي دسترسی write دایرکتوری ها و فایل ها در مسیر اصلی پوشه تعیین شوند که به محتواي وب اجازه بروزرسانی داده شود.

نحوه پیاده سازي:

به منظور حذف دسترسی نوشتن گروه بر روي فایل ها و دایرکتوری هاي $APACHE_PREFIX، دستور زیر را اجرا نمایید.

# chmod -R g-w $APACHE_PREFIX

12–3–SCWS: محدود نمودن دسترسی Write گروه بر روي ریشه اصلی دایرکتوری و فایل ها

شرح اجمالی:

ممکن است لازم باشد مجوزهاي گروهی براي دایرکتوری هاي $DOCROOT آپاچی توسط یک گروه مجاز مانند توسعه، پشتیبانی، یا یک ابزار مدیریت محتواي تولید، قابل نوشتن باشند. با این حال، نکته مهم این است که گروه آپاچی مورد استفاده براي اجراي سرور، دسترسی نوشتن بر روي هیچ یک از دایرکتوری ها یا فایل ها موجود در ریشه سند را نداشته باشد.

نحوه پیاده سازی:

به منظور حذف دسترسی نوشتن گروه بر روي فایل ها و دایرکتوری هاي DOCROOT$ با گروه Apache، دستور زیر را اجرا نمایید.

# find -L $DOCROOT -group $GRP -perm /g=w -print | xargs chmod g-w

4-SCWS: کنترل دسترسی آپاچی

4–SCWS: منع دسترسی به دایرکتوري ریشه ی OS

شرح اجمالی:

دستور Directory، به منظور پیکربندي خاص دایرکتوري؛ کنترل هاي دسترسی و بسیاري از ویژگی ها و گزینه هاي دیگر را میسر می سازد. یک استفاده مهم که باعث ایجاد یک سیاست انکار پیش فرض می گردد این است که اجازه دسترسی به دایرکتوری ها و فایل هاي سیستم عامل جز آن هایی که به طور خاص مجاز هستند را نمی دهد. این کار با مسدود کردن دسترسی به دایرکتوري ریشه سیستم عامل با استفاده از یکی از دو روش زیر می باشد که البته تنها یکی از این دو دستور باید انجام شود و مجاز به استفاده از هر دو نیستید:

استفاده از دستور Apache Deny به همراه یک دستور Order
Apache Require استفاده از دستور

هر دو روش موثر هستند و در حال حاضر ترکیبی از Order/Deny/Allow توصیه نمی گردد، زیرا آن ها سه راه را فراهم می سازند که تمامی دستورات طی یک دستور مشخص شده مورد پردازش قرار می گیرند. در مقابل، دستور Require بر روي اولین تطابق، مشابه با نحوه عمل Rule در فایروال، عمل می کند. دستور Require به صورت پیش فرض در آپاچی نسخه 2. 4 می باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

فایل هاي پیکربندي Apache را به منظور یافتن یک عنصر Directory> <ریشه، جستجو نمایید (شامل هر conf و هر فایل پیکربندي موجود در آن)
یک دستور Require منفرد را اضافه کرده و مقدار آن را all denied تنظیم نمایید.
هر دستور Deny و Allow را از عنصر> <Directory ریشه، حذف نمایید.

…

Require all denied

…

</Directory>

4–SCWS: اجازه دسترسی مناسب به محتواي وب

شرح اجمالی:

به منظور سرویس دهی محتواي وب، می بایست از دستور Allow استفاده نموده تا امکان دسترسی مناسب به دایرکتوری ها، مکان ها و میزبان هاي مجازي که حاوي محتواي وب هستند را میسر سازد.

نحوه پیاده سازی:

در راستاي پیاده سازی وضعیت توصیه شده موارد زیر را اجرا نمایید:

به منظور یافتن همه ي عناصر Directory> > و Location>>، فایل هاي پیکربندي Apache را جستجو نمایید (شامل conf و هر فایل پیکربندي موجود در آن). بایستی یک عنصر براي پوشه اصلی و هر دایرکتوري یا لوکیشن خاص، وجود داشته باشد. احتمالا دستورهاي کنترل دسترسی دیگري نیز در زمینه هاي مختلف، از جمله میزبان هاي مجازي یا عناصر خاص مانند <Proxy> وجود داشته باشند.
شامل دستورهاي مناسب Require، با مقادیر متناسب با نوع استفاده هر دایرکتوري می باشد.

پیکربندي هاي زیر، تنها چند نمونه ممکن هستند:

<Directory “/var/www/html/”> Require ip 192. 169.

</Directory>

Require all granted

</Directory>

Require local

</Location>

<Location /portal> Requirevalid-user

</Location>

3–4–SCWS: محدودسازي OverRide براي دایرکتوري ریشه OS

شرح اجمالی:

دستور OverRide، به فایل هاي.htaccess اجازه می دهند تا بدون در نظر گرفتن بسیاري از پیکربندي ها، از جمله احراز هویت، کنترل انواع سند، ایندکس هاي تولید شده به طور خودکار، کنترل دسترسی و Optionها مورد استفاده قرار گیرند. هنگامی که سرور یک فایل .htaccessدسترسی پیدا می کند (که توسط AccessFileName مشخص شده) ، می بایست از اینکه کدام دستورهاي اعلام شده در آن فایل می توانند اطلاعات دسترسی قبلی را نادیده بگیرد، مطلع باشد. هنگامی که این دستور بر روي None تنظیم شود، در آن صورت فایل هاي .htaccess به طور کامل نادیده گرفته می شوند. در اینصورت، سرور حتی براي خواندن فایل هاي .htaccessدر فایل سیستم هیچ تلاشی نمی کند. لذا چنانچه این دستور بر روي All تنظیم شود، در این صورت هر دستوري که یک زمینه .htaccess داشته باشد، در فایل هاي .htaccessمجاز می باشد.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache 2. 2 مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/core. html#allowoverride

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

فایل هاي پیکربندي Apache را به منظور یافتن یک عنصر <Directory> ریشه، جستجو نمایید (شامل conf و هر فایل پیکربندي موجود در آن)
یک دستور منفرد AllowOverride درصورت عدم وجود، اضافه نمایید.
مقدار AllowOverride را none تنظیم نمایید.

…

AllowOverride None

…

</Directory>

تنظیمات مربوطه در آپاچی نسخه 2.4.x بدین صورت می باشد.

به دایرکتوری $web_server/conf بروید و httpd.conf را باز کرده و در سطح ریشه Directory را جستجو کنید:

Options –Indexes

AllowOverride None

…

</Directory>

4–4–SCWS: محدودسازي OverRide براي کلیه دایرکتوری ها

شرح اجمالی:

دستور AllowOverRide، به فایل هاي .htaccess اجازه می دهند تا بدون در نظر گرفتن بسیاري از پیکربندي ها، از جمله احراز هویت، کنترل انواع سند، ایندکس هاي تولید شده به طور خودکار، کنترل دسترسی و Optionها مورد استفاده قرار گیرند. هنگامی که سرور یک فایل.htaccess پیدا می کند (که توسط AccessFileName مشخص شده)، می بایست از اینکه کدام دستورهاي اعلام شده در آن فایل می توانند اطلاعات دسترسی قبلی را نادیده بگیرد، مطلع باشد. هنگامی که این دستور بر روي None تنظیم شود، در آن صورت فایل هاي .htaccess به طور کامل نادیده گرفته می شوند. در اینصورت، سرور حتی براي خواندن فایل هاي .htaccess در فایل سیستم هیچ تلاشی نمی کند. لذا چنانچه این دستور بر روي All تنظیم شود، در اینصورت هر دستوري که یک زمینه .htaccess داشته باشد، در فایل هاي .htaccessمجاز می باشد.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache 2. 2 مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/core. html#allowoverride

:نحوه ی پیاده سازی

فایل هاي پیکربندي Apache را به منظور یافتن AllowOverride، جستجو نمایید (شامل conf وهر فایل پیکربندي موجود در آن)
مقدار همه دستورهاي AllowOverride را none تنظیم نمایید.

…

AllowOverride None

…

5-SCWS: به حداقل رساندن قابلیت ها، محتوا و گزینه ها

5–SCWS: محدود نمودن Optionها براي دایرکتوري ریشه OS

شرح اجمالی:

دستور Options آپاچی اجازه پیکربندي خاص Optionها، از جمله اجراي CGI، دنبال کردن Symbolic linkها، دستورات سمت سرور و content negotiation را می دهد.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache 2. 2 مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/core. html#options

: نحوه پیاده سازی

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

فایل هاي پیکربندي Apache را به منظور یافتن یک عنصر <<Directory ریشه، جستجو نمایید (شامل conf و هر فایل پیکربندي موجود در آن)
یک دستور منفرد Options درصورت عدم وجود، اضافه نمایید.
مقدار Options را none تنظیم نمایید.

…

Options None

…

</Directory>

5–SCWS: محدود نمودن Optionها براي دایرکتوري ریشه وب

شرح اجمالی:

دستور Options اجازه پیکربندي خاص Optionها را می دهد، از جمله می توان به موارد زیر اشاره نمود:

اجرای CGI دنبال کردن Symbloic link ها دستورات سمت سرور و
content negotiation

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache 2. 2 مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/core. html#option

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

فایل هاي پیکربندي Apache را به منظور یافتن یک عنصر <Directory> ریشه، جستجو نمایید (شامل conf و هر فایل پیکربندي موجود در آن)
اگر به multiviews نیاز می باشد، می بایست هر دستور Option ایجاد شده، داراي مقدار None یا

Multiviews باشد.

…

Options None

…

</Directory>

5–SCWS: به حداقل رساندن Optionها براي دیگر دایرکتوری ها

شرح اجمالی:

دستور Options اجازه پیکربندي خاص Optionها، از جمله اجراي CGI، دنبال کردن Symbolic linkها، دستورات سمت سرور و content negotiation را می دهد.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache 2. 2 مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/core. html#options

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

فایل هاي پیکربندي Apache را به منظور یافتن یک عنصر <Directory> ریشه، جستجو نمایید (شامل conf و هر فایل پیکربندي موجود در آن)
هر دستور Option موجود که داراي مقدار includes نمی باشد را اصلاح یا اضافه نمایید.

دیگر Optionها را در صورتی که ضرورت دارد همانند بالا به صورت مناسب پیاده سازی کنید.

5–SCWS: حذف نمودن محتواي پیش فرض HTML

شرح اجمالی:

محتواهاي پیش فرضی براي نصب و راه اندازي آپاچی موجود است که البته براي استفاده، مناسب و مورد نیاز نمی باشد. عملکرد اصلی براي این محتواي نمونه، ارائه یک وب سایت پیش فرض، ارائه دفترچه راهنماي کاربر یا نشان دادن ویژگی هاي خاص وب سرور است که می بایست تمام محتوایی که مورد نیاز نمی باشد حذف گردد.

نحوه پیاده سازی:

تمام محتواي از پیش نصب شده را مرور کرده و محتوایی که مورد نیاز نمی باشد را حذف نمایید. به خصوص، به دنبال محتواي غیرضروري باشید که ممکن است در یک مسیراصلی یافت شود، یک دایرکتوري پیکربندي می تواند دایرکتوري conf/extra یا یک بسته ي Unix/Linux باشد.

html یا صفحه welcome به طوري که به صورت پیش فرض نصب بوده را حذف و یا به کامنت تبدیل نمایید. در ضمن حذف یک فایل مانند welcome. conf که به صورت زیر نشان داده شده، توصیه نمی شود، زیرا با بروزرسانی بسته ، ممکن است مجدداً جایگزین شود.

# This configuration file enables the default “welcome”

# page if there is no default index page present for # the root URL. To disable the Welcome page, comment # out all the lines below.

##<LocationMatch”^/+$”>

##Options –Indexes

## ErrorDocument 403 /error/noindex. Html

##</LocationMatch>

محتواي user manual آپاچی را حذف کرده یا پیکربندي هایی که به بارگذاري دستی ارجاع می دهند را به کامنت تبدیل نمایید.

# yum erase httpd-manual

هر پیکربندي کنترل کننده وضعیت سیستم را حذف یا به کامنت تبدیل نمایید.

# Allow server status reports generated by mod_status,

# with the URL of http://servername/server-status

# Change the “. example. com” to match your domain to enable.

##<Location /server-status>

## SetHandler server-status

## Order deny,allow

## Deny from all

## Allow from. example. com ##</Location>

هر پیکربندي کنترل کننده اطلاعات سیستم را حذف یا به کامنت تبدیل نمایید.

# Allow remote server configuration reports, with the URL of

# http://servername/server-info (requires that mod_info. c be loaded). # Change the “. example. com” to match your domain to enable.

##<Location /server-info>

## SetHandler server-info

## Order deny,allow

## Deny from all

## Allow from. example. com

##</Location>

هر پیکربندي کنترل کننده دیگري مانند perl-status را حذف یا به کامنت تبدیل نمایید.

# This will allow remote server configuration reports, with the URL of

# http://servername/perl-status

# Change the “. example. com” to match your domain to enable.

##<Location /perl-status>

## SetHandler perl-script

## PerlResponseHandler Apache2:: Status

## Order deny,allow

## Deny from all

## Allow from. example. com

##</Location>

: SCWS-5-5 حذفCGI Content Printenv پیش فرض

شرح اجمالی:

اکثر وب سرور ها از جمله بسته نصبی آپاچی به صورت پیش فرض داراي محتواي CGI می باشند که براي کاربري وب سرور الزامی و مقتضی نمی باشد. کاربرد اصلی این برنامه نمونه شبیه سازي قابلیت هاي وب سرور می باشد. یکی از محتواهاي CGI پیش فرض براي بسته نصبی آپاچی، اسکریپت prinenv می باشد. این اسکریپت تمام مقادیر محیطی CGI را به درخواست کننده بر می گرداند که شامل تعداد زیادي توضیحات در مورد پیکربندي سیستم و مسیرهاي سیستمی می باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

محل فایل ها و دایرکتوری هاي cgi-bin فعال شده در پیکربندي Apache را از طریق دستورهاي Script،

ScriptInterpreterSource یا ScriptAliasMatch ، ScriptAlias را تعیین نمایید.

در صورتی که printenv در دایرکتوري cgi-bin نصب شده بود، آن را حذف نمایید.

# rm $APACHE_PREFIX/cgi-bin/printenv

SCWS-5-6: حذف CGI Content test-cgi پیش فرض

شرح اجمالی:

اکثر وب سرورها از جمله بسته نصبی آپاچی به صورت پیش فرض داراي محتواي CGI می باشند که براي کاربري وب سرور الزامی و مقتضی نمی باشد. کاربرد اصلی این برنامه نمونه شبیه سازي قابلیت هاي وب سرور می باشد. یکی از محتواهاي CGI پیش فرض براي بسته نصبی آپاچی اسکریپت test-cgi می باشد. این اسکریپت تمام مقادیر محیطی CGI را به درخواست کننده بر میگرداند که شامل تعداد زیادي توضیحات در مورد پیکربندي سیستم می باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

محل فایل ها و دایرکتوری هاي cgi-bin فعال شده در پیکربندي Apache از طریق دستورهاي Script،

ScriptInterpreterSource یا ScriptAliasMatch ، ScriptAlias را تعیین نمایید

در صورتی که test-cgi در دایرکتوري cgi-bin نصب شده بود ، آن را حذف نمایید.

# rm $APACHE_PREFIX/cgi-bin/test-cgi

SCWS-5-7 محدود نمودن روش های HTTP Request:

شرح اجمالی:

با استفاده از دستور <LimitExcept> روش هاي HTTP Request غیر ضروري وب سرور را محدود نموده تا تنها روشهاي درخواست POST ، HEAD ، GET و OPTIONS HTTP قبول و پردازش شوند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

محل فایل هاي پیکربندي Apache و فایل هاي پیکربندي گنجانده شده در آن را تعیین نمایید.
دستور را در مسیر اصلی پوشه جستجو نمایید، مانند:

…

</Directory>

1. دستوري مانند آنچه در زیر نشان داده شده را به گروه دستورهاي document root، اضافه نمایید.

# Limit HTTP methods to standard methods. Note: Does not limit TRACE

Require all denied

</LimitExcept>

1. در فایل هاي پیکربندي Apache، دستورهاي دیگري به جز دایرکتوري ریشه ي OS را جستجو کرده و دستورهاي مشابهی را به هر کدام اضافه نمایید. درك این مطلب بسیار مهم است که دستورها مبتنی بر سلسله مراتب سیستم فایل OS هستند ، نه سلسله مراتب مکان هایی در URLهاي وب سایت که توسط

Apache مورد دسترسی قرار می گیرند.

…

# Limit HTTP methods

Require all denied

</LimitExcept>

</Directory>

تنظیمات مربوطه در آپاچی نسخه 2.4.x بدین صورت می باشد.

به مسیر دایرکتوری $Web_Server/conf بروید و درفایل httpd.conf موارد زیر را اضافه کنید.

Deny from all

</LimitExcept>

SCWS-5-8: غیرفعال کردن روش HTTP TRACE:

شرح اجمالی:

از دستور TraceEnable به منظور غیرفعال کردن روش درخواست HTTP TRACE استفاده گردد.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/core. html#traceenable

: نحوه پیاده سازی

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

محل فایل پیکربندي اصلی Apache را همانند httpd.conf تعیین نمایید.
دستور TraceEnable را به پیکربندي سطح سرور با مقدار off اضافه نمایید.

پیکربندي سطح سرور بالاترین سطح پیکربندي به شمار می رود و مانند دایرکتوری هاي دیگري همچون

. مرتبط نمی باشد <Location> یا <Directory>

TraceEnable off

5-9–SCWS: محدود نمودن نسخه پروتکل HTTP

شرح اجمالی:

از ماژول هاي mod-rewrite یا mod_security می توان براي عدم دسترسی به نسخه هاي پروتکل هاي HTTP قدیمی و نامعتبر استفاده کرد. نسخه 1,1 RFC از HTTP مورخ ژوئن 1999 می باشد، و از نسخه 2,1 توسط آپاچی پشتیبانی شده است. استفاده از این ماژول براي دسترسی به نسخه هاي قدیمی HTTP مانند 0,1 و قبل از آن غیر مجاز می باشد.

به منظور کسب جزئیات بیشتر به مستندات Apache مربوط به mod_rewrite مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/mod_rewrite. html

: نحوه پیاده سازی

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

ماژول mod_rewrite را با انجام هرکدام از موارد زیر، براي Apache بارگذاري نمایید:
1. با اضافه کردن گزینه ي enable-rewrite– به اسکریپت ./configure، هنگام نصب Apache، ماژول mod_rewrite نیز نصب می گردد.

. /configure –enable-rewrite

و یا با استفاده از دستور LoadModule در فایل پیکربندي conf، ماژول را به صورت dynamic، بارگذاري نمایید.

LoadModule rewrite_module modules/mod_rewrite. so

به منظور فعال نمودن RewriteEngine، مقدار این دستور را به on در پیکربندي عمومی سرور تغییر دهید.

RewriteEngine on

محل فایل پیکربندي اصلی Apache مانند httpd.conf را تعیین کرده و شرط Rewrite زیر را براي انطباق با HTTP/1. 1 و قانون Rewriteرا براي رد کردن ورژن هاي دیگر پروتکل، به پیکربندي سطح سرور اضافه نمایید.

RewriteEngine On

RewriteCond %{THE_REQUEST} !HTTP/1\. 1$

RewriteRule. * – [F]

به طور پیش فرض، تنظیمات پیکربندي mod-rewrite از سرور اصلی توسط میزبان هاي مجازي به ارث برده نمی شوند. بنابراین، اضافه کردن دستورهاي زیر به هر بخش براي به ارث بردن تنظیمات سرور اصلی نیز ضروري است.

RewriteEngine On

RewriteOptions Inherit

10 5-SCWS: محدود نمودن دسترسی به فایل هاي . ht*

شرح اجمالی:

دسترسی به هر فایلی که با .ht شروع شده و از دستور FilesMatch استفاده می کند را محدود نمایید.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

1.خطوط زیر را در پیکربندي آپاچی در سطح پیکریندي سرور اضافه و یا اصلاح نمایید.

Require all denied

</FileMatch>

-11 5-SCWS: محدود نمودن پسوند فایل ها

شرح اجمالی:

دسترسی به پسوند فایل هاي نامتناسبی که انتظار نمی رود بخش مشروعی از وب سایت باشند، را محدود نمایید به نحوي که نتوان با دستور FilesMatch از آن ها استفاده نمود

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

لیستی از پسوند فایل هاي موجود بر روي وب سرور ایجاد نمایید. دستور find/awk زیر ممکن است مفید باشد، اما احتمالا با توجه به دایرکتوری هاي وب روت مناسب براي وب سرور شما، به سفارشی سازي نیاز دارد. توجه داشته باشید که دستور find، هر فایل بدون نقطه (.) در نام فایل را نادیده می گیرد، زیرا انتظار می رود که آن ها محتواي مناسبی نباشند.

find */htdocs -type f -name ‘*. *’ | awk -F. ‘{print $NF }’ | sort -u

لیست پسوند هاي فایل موجود براي محتواي مناسب بر روي سرور وب، مرور کرده و آن هایی که نامناسب هستند را حذف کرده و هر پسوند فایل اضافه اي که انتظار می رود در آیندهاي نزدیک به سرور وب افزوده شود را اضافه نمایید.
به منظور رد نمودن دسترسی به همه فایل ها به صورت پیش فرض ، دستور FilesMatch را اضافه نمایید.

# Block all files by default, unless specifically allowed.

Require all denied

</FilesMatch>

یک دستور FilesMatch دیگر اضافه کنید که اجازه ي دسترسی به پسوند فایل هایی که به طور خاص در فرآیند مرور مرحله ي 2، مجوز داشته اند را می دهد. مثالی از دستور FilesMatch در زیر آمده است. پسوند فایل در عبارت منظم بایستی با لیست تأیید شما مطابقت داشته باشد، نه لزوما با عبارت زیر.

# Allow files with specifically approved file extensions

# Such as (css, htm; html; js; pdf; txt; xml; xsl;… ),

# images (gif; ico; jpeg; jpg; png;… ), multimedia

<FilesMatch “^. *\. (css|html?|js|pdf|txt|xml|xsl|gif|ico|jpe?g|png)$”> Require all granted

</FilesMatch>

-125-SCWS: فیلترینگ درخواست ها بر اساس آدرس IP

شرح اجمالی:

از ماژول mod_rewrite می توان جهت رد کردن تقاضا براي url هاي خاص استفاده کرد این ماژول این امکان را می دهد که به جاي IP از Host Name استفاده گردد. عادي ترین دسترسی به وب سایت از طریق مرورگرها و نرم افزار خودکار با استفاده از یک نام میزبان می باشد، و در نتیجه شامل نام میزبان در هدر HTTP HOST خواهد بود.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache 2. 2 مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/mod_rewrite. html

: نحوه پیاده سازی

در راستاي پیاده سازی وضعیت توصیه شده موارد زیر را اجرا نمایید:

1.ماژول mod_rewrite را با انجام هرکدام از موارد زیر، براي Apache بارگذاري کنید:

با اضافه کردن گزینه ي enable-rewrite به اسکریپت. Apache, configure/. با mod_rewrite بارگذاري شده به صورت static را در طول فرآیند ساخت، بسازید.

. /configure –enable-rewrite

یا با استفاده از دستور LoadModule در فایل پیکربندي conf، ماژول را به صورت dynamic، بارگذاري کنید.

LoadModule rewrite_module modules/mod_rewrite. so

به منظور فعال نمودن RewriteEngine، مقدار این دستور را به on تغییر دهید.

RewriteEngine On

محل فایل پیکربندي Apache مانند httpd.conf را تعیین کرده و شرط rewrite زیر را براي مطابقت با نام میزبان مورد انتظار از پیکربندي سطح سرور بالا، اضافه کنید.

RewriteCond %{HTTP_HOST} !^www\. example\. com [NC]

RewriteCond %{REQUEST_URI} !^/error [NC]

RewriteRule ^. (. *) – [L,F]

-13 5-SCWS: محدود کردن دستور Listen

شرح اجمالی:

دستور Listen، شماره پورت هایی را که وب سرور آپاچی می خواهد بر روي آن گوش دهد را مشخص می کند. همچنین IP هایی که تنها درخواست آن ها پذیرفته خواهد شد، را نیز مشخص می کند. به جاي نامحدود شدن شنود بر روي تمام آدرس هاي IP در دسترس براي سیستم، آدرس یا آدرس هاي IP خاص در نظر گرفته شده باید به طور صریح مشخص شوند. به طور خاص ، یک دستور Listen که هیچ آدرس IP براي آن مشخص نشده، یا با یک آدرس IP از صفرها (0. 0. 0. 0) نباید مورد استفاده قرار گیرد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

1.هر دستور Listen در فایل پیکربندي Apache بدون هیچ آدرس IP مشخص، یا با همه ي آدرس هاي IP برابر صفر را مانند مثال زیر بیابید. به یاد داشته باشید که ممکن است آدرس هاي IPv4 و IPv6 هر دو در سیستم موجود باشند.

Listen 80

Listen 0.0.0.0:80

Listen [::ffff:0.0.0.0]:80

2.دستورهاي Listen در فایل پیکربندي Apache را براي داشتن آدرس هاي IP مشخص با توجه به استفاده در نظر گرفته شده، اصلاح کنید. ممکن است چندین دستور Listen براي هر آدرس IP و پورت، مشخص شود.

Listen 10. 1. 2. 3:80

Listen 192. 168. 4. 5:80

Listen [2001:db8::a00:20ff:fea7:ccea]:80

-14 5-SCWS: محدود نمودن Optionهاي فریم مرورگر

شرح اجمالی:

دستور Header به هدرهاي پاسخ HTTP سرور اجازه اضافه، جایگزین یا ادغام را می دهد. ما از این دستور براي اضافه کردن یک هدر پاسخ HTTP سرور به منظور توجیه مرورگرها در خصوص اینکه تمام صفحات وب را از قرار گرفتن در چارچوب وب سایت هاي دیگر محدود کنند، استفاده خواهیم نمود.

نحوه پیاده سازی:

1.دستور Header را براي هدر X-Frames-Options در تنظیمات آپاچی به وضعیت always اضافه و یا اصلاح نمایید و همانطور که به صورت زیر نمایش داده شده است یک عمل از append و یک مقدار از

. انتخاب گردد DENY یا SAMEORIGIN

Header always append X-Frame-Options SAMEORIGIN

6-SCWS: عملیات ورود، نظارت و نگهداري

6–SCWS: پیکربندي لاگ خطا

شرح اجمالی:

از دستور LogLevel به منظور پیکربندي سطح شدت براي Error Log مورد استفاده قرار می گیرد. در حالی که دستور ErrorLog، نام فایل ممیزي خطا را پیکربندي می کند. مقادیر Log براي SysLog استاندارد شامل debug و info ، notice ، warn ، error ، crit ، alert ، (syslog) emerge می باشد. سطح توصیه شده notice می باشد. به طوري که تمام خطاها از سطح emerge تا سطح notice ثبت می شوند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

مقدار LogLevel را در پیکربندي آپاچی اضافه نموده و یا تغییر دهید به گونه اي که مقدار notice و یا پایین تر داشته باشد. توجه نمایید که داشتن یک مقدار از info یا debug نیز می توان بکار برد در صورتی که نیاز به لاگ کامل تر وجود داشته باشد و فرآیندهاي ذخیره سازي و نظارت، قادر به کنترل بار اضافی باشند. لذا مقدار پیشنهادي در این خصوصnotice می باشد.

LogLevel notice

در صورتی که دستور ErrorLog پیکربندي نشده ، آن را اضافه نمایید. مسیر فایل ممکن است نسبی یا قطعی باشد، یا لاگ ها براي ارسال به یک سرور syslog، پیکربندي شده باشند.

ErrorLog “logs/error_log”

در صورتی که افراد مسئول متفاوتی براي میزبان مجازي وب سایت در نظر گرفته شده است براي هر میزبان مجازي پیکربندي شده یک دستور ErrorLog مشابه اضافه نمایید. هر فرد یا سازمان مسئول دسترسی به لاگ هاي وب خود بوده و به مهارت ها/آموزش/ابزار براي نظارت بر لاگ ها نیاز می باشد.

6–SCWS: پیکربندي Syslog Facility براي دریافت خطاها

شرح اجمالی:

جهت ارسال لاگ ها به یک syslog، دستور ErrorLog پیکربندي می شود، به طوري که لاگ ها بتوانند همراه با لاگ هاي سیستم پردازش و نظارت شوند.

نحوه پیاده سازی:

دستور ErrorLog را در صورت عدم پیکربندي، اضافه نمایید. هر نوع از سطوح SysLog متناسب در

Local1 مورد استفاده قرار می گیرد.

ErrorLog “syslog:local1”

در صورت نیاز براي هر میزبان مجازي یک دستور ErrorLog مشابه اضافه نمایید.

6–SCWS: تنظیمات لاگ دسترسی

شرح اجمالی:

دستور LogFormat، فرمت و اطلاعات را براي گنجانده شدن در مدخل هاي لاگ دسترسی، تعریف می کند. دستور CustomLog فایل لاگ، syslog facility یا ابزار piped logging را مشخص می کند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

در پیکربندي Apache براي استفاده از فرمت استاندارد و توصیه شده ي combined، دستورهاي

LogFormat را اضافه یا اصلاح کنید.

LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\”” combined

به منظور استفاده از فرمت combined با یک فایل لاگ مناسب ، syslog یا ابزار piped Logging، دستورهاي CustomLog در پیکربندي Apache را اضافه یا اصلاح کنید.

CustomLog log/access_log combined

براي هر میزبان مجازي پیکربندي شده یک دستور CustomLog مشابه اضافه نمایید، اگر افراد مسئول متفاوتی براي میزبان مجازي وب سایت در نظر گرفته شده است. هر فرد یا سازمان مسئول دسترسی به لاگ هاي وب خود بوده و به مهارت ها/آموزش/ابزار براي نظارت بر لاگ ها نیاز می باشد.

فرمت توکن هاي رشته اطلاعات زیر را فراهم می کنند:

h%: نام میزبان یا آدرس IP راه دور، اگر off ، HostnameLookups باشد که مقدار پیش فرض است.

%l: نام لاگ/ شناسه ي راه دور.

%u: کاربر راه دور، اگر درخواست، تأیید شده باشد.

%t: زمان دریافت درخواست،

%r: اولین خط درخواست.

%> s: وضعیت نهایی.

%b: اندازه ي پاسخ بر اساس بایت.

. Referer مقدار متغیر براي هدر :%{ Referer} i

. User Agent مقدار متغیر براي هدر :%{ User-agent} i

6–SCWS: بازبینی و فضاي لاگ

شرح اجمالی:

وجود فضاي دیسک کافی بر روي پارتیشن به منظور نگهداري تمام فایل هاي لاگ تولید شده امر بسیار مهمی می باشد، بازه چرخش لاگ ها، اگر از فضاي ذخیره سازي مرکزي براي ذخیره سازي لاگ ها مورد استفاده قرار نمی گیرد، براي حفظ حداقل 3 ماه یا 13 هفته پیکربندي شود.

نحوه پیاده سازی:

براي پیاده سازی حالت توصیه شده، گزینه a) اگر از Linux logrotate استفاده می کنید، گزینه b) اگر از یک ابزار piped Logging استفاده می کنید، را به کار بگیرید:

File Loggingبا Logrotate:
پیکربندی بازبینی لاگ وب را جهت مطابقت با فایل های لاگ پیکربندی شده ی خود در d/httpd، etc/logrotate، همانند زیر ، اضافه یا اصلاح نمایید.

/var/log/httpd/*log { missingok notifempty sharedscripts postrotate

/bin/kill -HUP `cat /var/run/httpd. pid 2>/dev/null` 2> /dev/null ||

true

endscript

}

2. دوره ي بازنگري و تعداد لاگ ها را طوري اصلاح نمایید که حداقل 13 هفته یا 3 ماه لاگ ها حفظ شوند. این کار ممکن است به صورت پیش فرض براي همه ي لاگ ها در /etc/logrotate. conf یا در پیکربندي بازبینی لاگ مخصوص وب در /etc/logrotate. d/httpd، مانند زیر انجام شود.

# rotate log files weekly

weekly

# keep 1 years of backlogs

rotate 52

براي هر میزبان مجازي پیکربندي شده با فایل هاي لاگ خود که آن فایل هاي لاگ در یک بازبینی لاگ مشابه نیز جاي دارند، اطمینان حاصل نمایید.

: Piped Logging
فواصل بازبینی لاگ و نام هاي فایل لاگ را به یک فاصله ي مناسب مانند روزانه، پیکربندي نمایید.

CustomLog “|bin/rotatelogs -l /var/logs/logfile. %Y. %m. %d 86400” combined

2. اطمینان از اینکه به منظور نام گذاري فایل لاگ و اسکریپت هاي بازبینی، براي باقی ماندن حداقل ماه یا 13 هفته، فراهم شده اند.
براي هر میزبان مجازي پیکربندي شده با فایل هاي لاگ خود که آن فایل هاي لاگ در یک بازبینی مشابه نیز جاي دارند، اطمینان حاصل نمایید.

6–SCWS: اعمال وصله هاي قابل اجرا

شرح اجمالی:

آخرین وصله هاي آپاچی در دسترس قرار گرفته، در بازه یک ماهه را اعمال نمایید.

نحوه پیاده سازی:

آخرین نسخه ي در دسترس از Apache را با توجه به یکی از موارد زیر به روزرسانی نمایید:

هنگام ساخت از منبع:
1. نکات منتشر شده و اطلاعات امنیتی مرتبط با آن را بخوانید.
2. آخرین منبع و هر ماژول وابسته مانند mod-security را دانلود نمایید.
3. نرم افزار جدید Apache را با توجه به روند ساخت خود با گزینه هاي پیکربندي مشابه ایجاد نمایید.
4. نرم افزار جدید را با توجه به فرآیند تست سازمانی خود، نصب و آزمایش نمایید.
5. با توجه به روند توسعه ي سازمانی خود، نرم افزار را به تولید انتقال بدهید.
هنگام استفاده از بسته هاي پلتفرم:
1. نکات منتشر شده و اطلاعات امنیتی مرتبط با آن را بخوانید.
2. آخرین بسته ي موجود Apache و هر نرم افزار وابسته را دانلود نمایید.
3. نرم افزار جدید را با توجه به فرآیند تست سازمانی خود، نصب و آزمایش نمایید.
4. با توجه به روند توسعه ي سازمانی خود، نرم افزار را به تولید انتقال دهید.

6–SCWS: راه اندازي و فعال سازي ModSecurity

شرح اجمالی:

ModSecurity یک فایروال جهت برنامه هاي تحت وب (WAF) و منبع باز براي نظارت، ثبت، و کنترل دسترسی بلا درنگ براي برنامه تحت وب است. این فایروال مجموعه قوانین قابل تنظیم قدرتمند را که ممکن است براي شناسایی و جلوگیري از حملات متداول برنامه تحت وب مورد استفاده قرار گیرند، فعال می کند اما قوانین پیش فرض آن داراي قدرت مناسبی نیستند. نصب و راه اندازي ModSecurity بدون یک مجموعه قوانین، امنیت بیشتري را براي برنامه تحت وب حفاظت شده فراهم نمی کند. براي جزئیات بیشتر در مورد یک مجموعه قوانین توصیه شده، به توصیه معیار “نصب و فعال سازي مجموعه قوانین اصلی OWASP ModSecurity” مراجعه کنید.

توجه: همانند سیستم هاي امنیت نرم افزار/ فایروال امنیتی، Mod_Security نیز نیازمند تعهد قابل توجه کارکنان براي تنظیم اولیه قوانین و کنترل هشدار هاست. در برخی موارد، این امر ممکن است نیازمند زمان کار اضافه تري از جانب توسعه دهندگان/ نگه داران برنامه، براي اصلاح آن بر اساس تجزیه و تحلیل نتایج لاگ ها می باشد. بعد از راه اندازي، تعهد دائمی کارکنان، به ویژه بعد از ارتقاء/پچ ها، براي تنظیم مداوم مورد نیاز است. بدون این تعهد به تنظیم و نظارت، نصب Mod_Security ممکن است مؤثر نباشد و یک امنیت کاذب ارائه دهد.

نحوه پیاده سازی:

در صورت عدم نصب ماژول ModSecurity در modules/mod_security2. so، نصب نمایید. این ماژول، ممکن است از طریق نصب بسته ي OS (مانند apt-get یا yum) یا ساخته شده از فایل هاي منبع، نصب شود. به منظور کسب جزئیات بیشتر به آدرس https://www. modsecurity. org/download. Html مراجعه نمایید.
در صورت عدم وجود دستور LoadModule در پیکربندي Apache، آن را اضافه یا اصلاح نمایید. دستور LoadModule معمولاً در فایلی به نام conf که در پیکربندي Apache قرار دارد، جاي گرفته است.

LoadModule security2_module modules/mod_security2. so

7–6–SCWS: راه اندازي و فعال سازي مجموعه قوانین اصلی OWASP ModSecurity

شرح اجمالی:

مجموعه قوانین اصلی (CRS) OWASP ModSecurity، مجموع هاي از قوانین دفاعی برنامه تحت وب منبع باز براي فایروال برنامه تحت وب (WAF) است. OWASP ModSecurity CRS حفاظت هاي اولیه را در دسته هاي حمله/تهدید زیر فراهم می کند:

حفاظت HTTP – تشخیص نقض هاي پروتکل HTTP و یک سیاست استفاده تعریف شده به صورت محلی.
متغیرهاي لیست سیاه بلادرنگ – استفاده از اعتبار IP شخص ثالث
انکار حفاظت هاي خدمات HTTP – دفاع در برابر جاري شدن HTTP و حملات HTTP DoS آهسته
حفاظت از حملات متداول وب – تشخیص حملات علیه برنامه هاي وب
خودکارسازي تشخیص – تشخیص باتها ، crawlers، اسکنرها و سایر فعالیت هاي مخرب سطحی
ادغام با اسکن AV براي آپلود فایل – تشخیص فایل هاي مخرب آپلود شده از طریق برنامه تحت وب
پیگیري اطلاعات حساس – پیگیري استفاده از کارت اعتباري و مسدود کردن نشتی ها
حفاظت در برابر تروجان – تشخیص دسترسی به تروجان ها
شناسایی ناهنجاري هاي برنامه – هشدار در مورد پیکربندي هاي اشتباه برنامه
تشخیص خطا و پنهان کردن – پنهان کردن پیامهاي خطاي ارسال شده توسط سرور

نحوه پیاده سازی:

OWASP ModSecurity Core Rule Setرا نصب، پیکربندي و تست کنید:

OWASP ModSecurity CRS را از صفحه ي پروژه

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Proj. etc

دانلود کنید.

دستورالعمل هاي فایل INSTALL را دنبال کنید.
فایل modsecurity_crs_10_setup.conf مورد نیاز است و قوانین دایرکتوري base_rules، پایه ي مفیدي براي بیشتر کاربردها هستند.
برنامه ي کاربردي را براي عملکرد درست پس از نصب CRS، تست نمایید. لاگ هاي خطاي وب سرور و فایل the modsec_audit.log را براي درخواست هاي مسدود شده ي ناشی از false positiveها، بررسی نمایید.
همچنین، توصیه می شود که پاسخ برنامه ي کاربردي به ترافیک مخرب، مانند یک اسکنر خودکار برنامه ي تحت وب، براي حصول اطمینان از فعال بودن قوانین، تست شود. لاگ هاي خطاي وب سرور و فایل هاي the modsec_audit. log بایستی لاگ حملات و کدهاي پاسخ سرورها را نشان دهند.

SSL/TSL استفاده از: SCWS-7

SCWS-7-1: نصب و راه اندازیmod_ssl و یا mod_nss

شرح اجمالی:

لایه سوکت هاي امن(SSL) توسط Netscape توسعه داده شده و تبدیل به یک استاندارد فراگیر شده است، و به عنوان بخشی از فرآیند به امنیت لایه انتقال( TLS) تغییر نام داده شد. TLS براي حفاظت از ارتباطات، مهم می باشد و احراز هویت سرور و حتی کلاینت را فراهم می کند. با این حال برخلاف ادعاهاي تولیدکننده، پیاده سازی SSL به طور مستقیم وب سرور شما را امن تر نمی کند! چرا که SSL براي رمزگذاري ترافیک مورد استفاده قرار می گیرد و در نتیجه محرمانگی اطلاعات خصوصی و اعتبارات کاربر را تأمین می کند. با این حال به خاطر داشته باشید تنها به خاطر این که شما مسیر داده ها را رمزگذاري کرده اید به این معنا نمی باشد که اطلاعات ارائه شده توسط کلاینت امن است ، زیرا که این اطلاعات بر روي سرور قرار دارد. همچنین از SSL نمی توان انتظار حفاظت از وب سرور را داشت، زیرا مهاجمان به راحتی وب سرورهاي داراي SSL را هدف قرار داده و حمله در کانال رمزگذاري شده پنهان خواهد شد. ماژول mos_ssl استاندارد و پر استفاده ترین ماژولی است که SSL/TLS را براي آپاچی پیاده سازی می کند. یک ماژول جدیدتر بر روي سیستم هاي Red Hat می تواند یک تعریف یا جایگزینی براي mod_ssl باشد، و قابلیت هاي مشابه به علاوه خدمات امنیتی بیشتري را فراهم نماید. mod_nss یک ماژول آپاچی جهت پیاده سازی نرم افزار خدمات امنیت شبکه (NSS) از Mozilla است و طیف گسترده اي از توابع رمزنگاري به علاوه TLS را پیاده سازی می کند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده یکی از موارد زیر را اجرا نمایید:

براي نصب Apache با استفاده از توزیع هاي سورس، از گزینه ي with-ssl=– براي مشخص کردن مسیر openssl و از گزینه ي پیکربندي enable-ssl– براي اضافه کردن ماژول هاي SSL به ساخت، استفاده نمایید. در صورت ناسازگاري با نسخه پلتفرم پیکربندي گزینه with-included-apr– ضروري می باشد.

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache

http://httpd. apache. org/docs/2. 2/install. html

مراجعه نمایید:

#. /configure –with-included-apr –with-ssl=$OPENSSL_DIR –enable-ssl

براي نصب با استفاده از بسته هاي OS، معمولاً تنها نکته مهم حصول اطمینان از نصب بسته ي mod_ssl می باشد. همچنین بسته ي mod_nss نیز ممکن است نیاز به نصب داشته باشد. دستورات yum زیر براي Red Hat Linux مناسب هستند.

# yum install mod_ssl

2–7–SCWS: نصب یک گواهی مورد اعتماد معتبر

شرح اجمالی:

گواهی SSL پیش فرض، self-signe می باشد و قابل اعتماد نیست. لذا می بایست یک گواهی قابل اعتماد معتبر نصب نمایید. گواهی براي معتبر بودن می بایست:

توسط یک مرجع گواهی مورد اعتماد امضا شده باشد.
منقضی نشده باشد، و
یک نام مشترك منطبق بر نام میزبان وب سرور داشته باشد ، مانند example. com.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

درباره ي نام میزبان استفاده شده در گواهی، تصمیم بگیرید. مهم این است که به یاد داشته باشید مرورگر نام میزبان در URL را با نام موجود در گواهی، مقایسه می کند. بنابراین مطابقت با نام صحیح میزبان از اهمیت بالایی برخوردار است. به خصوص زمانی که، نام میزبان example. com با نام example. com و ssl. example. com یکی نباشد.
یک کلید خصوصی با استفاده از openssl تولید کنید. اگرچه طول کلید اعتبارسنجی رایج در گذشته

1024 بوده، اما براي اعتبارسنجی قدرتمندتر، طول کلید 2048 توصیه می شود. کلید بایستی محرمانه باقی بماند و به طور پیش فرض با یک عبارت عبور، رمزگذاري شود. در همین راستا مراحل زیر را طی نمایید:

به منظور کسب جزئیات بیشتر به مستندات مربوط به Apache یا OpenSSL مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/ssl/ssl_faq. html#realcert http://www. openssl. org/docs/HOWTO/certificates. Txt

# cd /etc/pki/tls/certs

# umask 077

# openssl genrsa -aes128 2048 > example. com. key

Generating RSA private key, 2048 bit long modulus … +++

………… +++

e is 65537 (0x10001) Enter pass phrase:

Verifying – Enter pass phrase:

درخواست امضاي گواهی( CSR) را به منظور امضا توسط یک مرجع گواهی، تولید نمایید. مهم این است که یک نام مشترك، دقیقا نام میزبان وب را تشکیل دهد.

# openssl req -utf8 -new -key www. example. com. key -out www. example. com. csr

Enter pass phrase for example. com. key:

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) [GB]:US

State or Province Name (full name) [Berkshire]:New York

Locality Name (eg, city) [Newbury]:Lima

Organization Name (eg, company) [My Company Ltd]:Durkee Consulting Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server’s hostname) []:www. example. com

Email Address []:ralph@example. com

Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []:

An optional company name []:

# mv www. example. com. key /etc/pki/tls/private/

CSR را به یک مرجع امضاي گواهی براي امضا بفرستید و دستورالعمل هاي آن ها را براي ارائه و اعتبارسنجی، دنبال نمایید. CSR و گواهی امضا شده ي نهایی، تنها متن رمزگذاري شده اي هستند که یکپارچگی آن ها، نه محرمانگی شان، بایستی محافظت شود. با این حال این گواهی براي هر اتصال SSL فرستاده خواهد شد.
گواهی امضا شده ي نتیجه ممکن است example. com. crt نامیده شده و در /etc/pki/tls/certs/ جاي بگیرد که براي همه قابل خواندن است (mode 0444). توجه کنید که مرجع گواهی، نیازي به کلید خصوصی ندارد ( example. com. key) و این فایل بایستی به دقت، محافظت شود. با یک کپی رمزگشایی شده از کلید خصوصی، رمزگشایی همه ي تعاملات با سرور، امکان پذیر است.
عبارت عبور استفاده شده براي رمزگذاري کلید خصوصی را فراموش نکنید. این عبارت، هر زمان که سرور در حالت https آغاز به کار می کند لازم است. اگر جلوگیري از نیاز به تایپ عبارت ورود در زمان شروع httpd ضروري است، کلید خصوصی ممکن است در یک متن ساده، ذخیره شود. ذخیره ي کلید خصوصی در یک متن ساده، باعث راحتی می شود، در حالی که ریسک افشاي کلید را افزایش می دهد، اما اگر خطرات آن به خوبی مدیریت شود ممکن است براي راه اندازي مجدد مناسب باشد. مطمئن شوید که فایل کلید تنها توسط ریشه، قابل خواندن است. براي رمزگشایی کلید خصوصی و ذخیره ي آن در فایل متنی، ممکن است از دستور openssl زیر استفاده شود. شما می توانید با استفاده از هدر هاي کلید خصوصی، رمز بودن یا متن ساده بودن آن را تشخیص دهید.

# cd /etc/pki/tls/private/

# umask 077

# openssl rsa -in www. example. com. key -out www. example. com. key. clear

محل فایل پیکربندي Apache براي mod-ssl را تعیین نموده و دستورهاي SSLCertificateFile و SSLCertificateKeyFile را براي داشتن مسیر صحیح براي کلید خصوصی و فایل هاي گواهی امضا شده، اضافه یا اصلاح نمایید. اگر به یک کلید متن ساده، ارجاع داده شود به عبارت عبور نیازي نیست. درضمن شما از گواهی CA که به جاي بسته ي نرم افزاري CA، گواهی شما را امضا کرده، براي سرعت بخشیدن به اتصال SSL اولیه می توانید استفاده نمایید.

SSLCertificateFile /etc/pki/tls/certs/example. com. crt SSLCertificateKeyFile /etc/pki/tls/private/example. com. key

# Default CA file, can be replaced with your CA’s certificate.

SSLCACertificateFile /etc/pki/tls/certs/ca-bundle. crt

در نهایت سرویس httpd را شروع یا راه اندازي مجدد کرده و عملکرد صحیح آن را با مرورگر مورد علاقه ي خود، اعتبارسنجی نمایید.

3–SCWS7: حفاظت از کلید خصوصی سرور

شرح اجمالی:

محافظت از کلید خصوصی سرور بسیار مهم می باشد. به طور پیش فرض کلید خصوصی سرور به عنوان یک سیستم حفاظت از سرور، رمزنگاري شده است. با این حال، رمزنگاري آن به این معنا می باشد که هر بار سرور راه اندازي می شود به کلمه عبور نیاز دارد، و در حال حاضر محافظت از کلمه عبور نیز ضروري و مهم می باشد. کلمه عبور ممکن است در برخی مواقع به صورت دستی تنظیم شده، یا توسط یک برنامه که به صورت خودکار تولید شود.

به منظور کسب جزئیات بیشتر به لینک زیر مراجعه نمایید:

http://httpd. apache. org/docs/2. 2/mod/mod_ssl. html#sslpassphrasedialog

به طور خلاصه، Option های موجود عبارتند از:

1. استفاده از SSLPassPhraseDialog builtin، – نیازمند یک کلمه عبور براي ورود به صورت دستی 2. استفاده از SSLPassPhraseDialog |/path/to/program براي ارائه کلمه عبور
استفاده از SSLPassPhraseDialog exec:/path/to/program برای ارائه کلمه عبور
ذخیره کلید خصوصی به صورت واضح به طوري که یک کلمه عبور مورد نیاز نباشد.

هر یک از گزینه هاي 1 الی 4 بالا تا زمانی که کلید و کلمه عبور به شرح زیر محافظت شوند، قابل قبول اند. گزینه 1 مزیت امنیت بیشتري نسبت به عدم ذخیره سازي کلمه عبور دارد، اما این مورد به طور کلی براي اکثر وب سرورهاي تولیدي قابل قبول نیست، چون مستلزم این است که وب سرور به صورت دستی آغاز شود. در مورد گزینه هاي 2 و 3 در صورتی که برنامه هایی که آن ها را ارائه می دهند امن باشند می توانند امنیت بیشتري ارائه دهند. گزینه 4 از همه ساده تر است، و به طور گسترده مورد استفاده قرار گرفته و تا زمانی که کلید خصوصی به طور مناسب محافظت شود، قابل قبول می باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

می بایست کلیه کلیدهاي خصوصی جدا از کلیدهاي عمومی ذخیره گردند. دستورهاي SSLCertificateFile را در فایل هاي پیکربندي آپاچی بیابید. براي هر یک از دستورهاي SSLCertificateFile که داراي دستور SSLCertificateKeyFile متناظري نباشد، کلید را به فایلی مجزا از گواهی انتقال دهید ، و دستور SSLCertificateKeyFile را براي فایل کلید اضافه نمایید.
براي هر یک از دستورهاي SSLCertificateKeyFile، مالکیت و مجوز بر روي سرور کلید خصوصی را به root:root با مجوز 0400 تغییر دهید.

4–7–SCWS: غیرفعال کردن پروتکل هاي SSL ضعیف

شرح اجمالی:

دستور SSLProtocol، پروتکل هاي SSL و TLS مجاز را مشخص می کند. می بایست هر دو پروتکل SSL v2 و SSLv3 در این دستور غیرفعال شوند، زیرا تاریخ گذشته بوده و نسبت به افشاي اطلاعات آسیب پذیر می باشند.

بدین منظور تنها می بایست پروتکل هاي TLS فعال شوند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور SSLProtocol را در فایل هاي پیکربندي Apache جستجو نمایید؛ در صورتی که دستور موجود نبود، آن را اضافه نموده یا مقدار آن را براي مطابقت با یکی از مقادیر زیر، تغییر دهید. زمانی که غیرفعال کردن پروتکل

TLSv1.0 قابل قبول باشد تنظیمات “TLS1.2 TLSv1.1” به عنوان اولین تنظیمات ترجیح داده می شوند.

SSLProtocol TLSv1. 1 TLSv1. 2

SSLProtocol TLSv1

5–7–SCWS: محدود کردن رمزهاي ضعیف SSL

شرح اجمالی:

رمزنگاري SSL ضعیف را با استفاده از دستورهاي SSLCipherSuite و SSLHonorCipherOrder غیرفعال نمایید. رمزنگاري هاي مجاز در مذاکره با کلاینت توسط دستور SSLCipherSuite مشخص می شوند. در حالی که SSLHonorCipherOrder باعث می شود سرور در خصوص انتخاب استفاده از چه نوع رمزنگاري به جاي کلاینت تصمیم گیري کند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

خط زیر را در پیکربندي سطح سرور Apache و هر میزبان مجازي که SSL آن فعال شده است، اضافه یا اصلاح نمایید.

SSLHonorCipherOrder On

SSLCipherSuite ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!MD5:!RC4

انطباق با استاندارد FIPS: مشخصات رمزنگاري بالا ممکن است براي سروري مورد استفاده قرار بگیرد که تحت شرایط انطباق با 2-FIPS140 شکست بخورد ، 52-SP800 دستورالعمل هایی براي رمزنگاري TLS را فراهم می کند، زیرا سبب حذف استفاده از رمزنگاري RC4 و Hash نمودن MD5 می شود که به نظر نمی رسد با FIPS سازگار باشد.

غیرفعالسازي رمزهاي SSLv3: همانطور که توصیه شده است اگر پروتکل SSLv3 غیرفعال شده باشد، پس رمزنگاري مرتبط با SSLv3 نیز مورد استفاده قرار نخواهد گرفت، و می توان آن را از مجموعه مشخصات رمزنگاري حذف نمود.

SSLCipherSuite ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!SSLv3:!MD5:!RC4

: SCWS-7 محدود نمودن SSL ناامن Renegotiation

شرح اجمالی:

یک نوع حمله مرد در میان در SSLv3 و TLSv1 در نوامبر 2009 کشف شد.

ابتدا، یک راه حل و سپس یک اصلاح به عنوان یک استاندارد اینترنت به صورت RFC 574 در فوریه 2010 تصویب شد. راه حلی که Renegotiation را حذف می کند، از OpenSSL نسخه 0.9.8l و نسخه هاي جدیدتر قابل دسترس است. براي جزئیات بیشتر به لینک http://www. openssl. org/news/secadv_20091111. txt مراجعه نمایید.

دستور SSLInsecureRenegotiation در Apache 2.2.15 براي وب سرورهاي مرتبط با OpenSSL نسخه 0.9.8m و بالاتر اضافه گردیده است. تا اجازه Renegotiation ناامن جهت ایجاد یک ارتباط سازگار با Client هایی با نسخه SSL قدیمی را دهد. هنگامی که یک ارتباط سازگار ایجاد می گردد، فعال نمودن دستور SSLInsecureRenegotiation سرور را همچنین براي حملاتی مانند CVE-2009-3555) man-in-the-middle) آسیب پذیر می نماید. بنابراین، دستور SSLInsecureRenegotiation نباید فعال گردد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور SSLInsecureRenegotiation را در فایل هاي پیکربندي Apache جستجو نمایید؛ در صورت وجود دستور مذکور، مقدار آن را به off اصلاح نمایید. اما در صورت عدم وجود نیاز به انجام عمل خاصی نمی باشد.

SSLInsecureRenegotiation off

7–SCWS: اطمینان از فعال نبودن فشرده سازي SSL

شرح اجمالی:

دستور SSLCompression فشرده سازي SSL هنگام سرویس دهی به محتواي HTTPS توسط آپاچی را کنترل می کند که آیا مورد استفاده قرار گرفته است یا خیر. توصیه می شود که دستور SSLCompression بر روي Off تنظیم شود.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

با استفاده از دستور httpd –v از نسخه 2.24 و یا بالاتر Apache اطمینان حاصل نمایید.
دستور SSLCompression را در فایل هاي پیکربندي Apache جستجو نمایید.
در صورت وجود دستور، آن را به مقدار off تغییر داده و بروزرسانی نمایید.

7–SCWS: غیر فعال کردن پروتکل 0

شرح اجمالی:

پروتکل TLSv1.0 در صورت امکان می بایست از طریق دستور SSLProtocol غیر فعال شود، همانطور که بیان شده است این پروتکل نسبت به افشاي اطلاعات آسیب پذیر می باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور SSLProtocol را در فایل هاي پیکربندي Apache جستجو نمایید و در صورت عدم وجود آن را اضافه نمایید و یا مقدار آن را به 1 TLSv1. 2 تغییر دهید.

: SCWS-7 فعال کردن OCSP Stapling

شرح اجمالی:

Online Certificate Status Protocol) OCSP) وضعیت ابطال کنونی یک گواهی X. 509 را ارائه کرده و اجازه می دهد یک مرجع گواهی، اعتبار یک گواهی امضا شده را قبل از تاریخ انقضاي آن لغو کند. URI براي سرور OCSP در گواهی گنجانده شده و توسط مرورگر تأیید می شود. دستور SSLUseStapling همراه با دستور SSLStaplingCache براي فعال کردن OCSP Stapling توسط وب سرور توصیه می شوند. اگر کلاینت OCSP stapling را درخواست نماید، در آن صورت وب سرور شامل پاسخ سرور OCSP همراه با گواهی X.509 وب سرور باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

در سطح پیکربندي آپاچی سرور و هر میزبان مجازي که SSL در آن فعال می باشد ، SSLUseStapling را به on تغییر دهید. همچنین می بایست SSLStaplingCache به یکی از Chache هایی که مشابه به مثال زیر آمده تنظیم گردد.

SSLUseStapling On SSLStaplingCache “shmcb:logs/ssl_staple_cache(512000)”

or –

SSLStaplingCache “dbm:logs/ssl_staple_cache. db”

or –

SSLStaplingCache dc:UNIX:logs/ssl_staple_socket

HTTP Strict Transport Securityفعال کردن : SCWS-7-10

شرح اجمالی:

امنیت انتقال اسکریپت (HSTS) HTTP یک مکانیزم سیاست امنیتی وب سرور انتخابی است که توسط یک هدر سرور HTTP مشخص شده است. هدر HSTS به یک سرور اجازه می دهد تا اعلام کند که تنها ارتباطات HTTPS باید به جاي ارتباطات HTTP مورد استفاده قرار گیرند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور Header را همانطور که به صورت زیر نشان داده شده است در سطح سرور آپاچی و هر میزبان مجازي که داراي SSL می باشد، پیکربندي نمایید. ممکن است Flag هاي includedSubDomain و preload در هدر گنجانده شوند در صورتی که لازم و ضروري نمی باشد.

Header always set Strict-Transport-Security “max-age=600”; includedSubDomain; preload

یا

Header always set Strict-Transport-Security “max-age=600”

8-SCWS: نشت اطلاعات

: SCWS-8 تنظیم Server Token به ‘Prod’

شرح اجمالی:

اگر می خواهید نسخه وب سرور شما هنگام ارتباطات فاش نشود بایستی این موارد را به دقت اجرا کنید. افشای اطلاعات نسخه وب سرور به مهاجمان برای فعالیت های شناسایی شان سرعت می دهد. تنظیمات پیش فرض آپاچی، ورژن و سیستم عامل آن را فاش می کند.

با تنظیم مقدار دستور ServerTokens بر روي Prod یا ProductOnly، آپاچی را براي ارائه حداقل اطلاعات پیکربندي نمایید. در اینصورت، به جاي ارائه جزئیات در مورد ماژول ها و نسخه هاي نصب شده “Apache”، تنها اطلاعات نسخه، در هدر پاسخ HTTP قابل ارائه خواهد بود.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

مقدار دستور ServerTokens را در پیکربندي آپاچی به Prod و یا ProductOnly همانند بند زیر تغییر دهید.

ServerTokens Prod

: SCWS-8 تنظیم ServerSignature بر روی Off

شرح اجمالی:

امضاهاي سرور، که یک خط امضا به صورت یک پانویس انتهایی در پایین اسناد توسط سرور ایجاد شده، (مانند صفحات خطا)، را غیر فعال نمایید.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

مقدار دستور ServerSignature را در پیکربندي آپاچی به off همانند بند زیر تغییر دهید.

ServerSignature Off

8–SCWS: نشت اطلاعات از طریق محتواي پیش فرض Apache

شرح اجمالی:

در توصیه هاي قبلی، ما محتواي پیش فرض مانند دفترچه هاي راهنماي آپاچی و برنامه هاي CGI پیش فرض را حذف کردیم. با این حال، اگر می خواهید نشت اطلاعات مربوط به وب سرور را بیشتر محدود کنید، مهم است که محتواي پیش فرض مانند آیکون ها بر روي وب سایت باقی نماند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

به طور پیش فرض در توزیع سورس، محل پیکربندي هاي auto-index و icon را در فایل-extra/httpdautoindex. conf در نظر می گیرد، بنابراین می تواند با کامنت نمودن خطوط در فایل conffile ، مانند ذیل اقدام به غیرفعال نمودن آن ها نمایید.

# Fancy directory listings

#Include conf/extra/httpd-autoindex. conf

در روش دیگر ، می توان دستور alias و پیکربندي کنترل دسترسی دایرکتوري را همانند زیر به کامنت تبدیل نمود:

# We include the /icons/ alias for FancyIndexed directory listings. If

# you do not use FancyIndexing, you may comment this out.

#Alias /icons/ “/var/www/icons/”

#<Directory “/var/www/icons”>

# Options Indexes MultiViews FollowSymLinks

# AllowOverride None

# Order allow,deny

# Allow from all

#</Directory>

8-4 SCWS: آسیب پذیری Etag

در آپاچی نسخه 2.4.x مقدار پیش فرض این سرآیند به مهاجم راه دور اجازه می دهد تا اطلاعات حساس مانند inode number, multipart MIME boundry و فرآیند های فرزند را از طریق سرآیند Etag به دست آورید. برای جلوگیری از این آسیب پذیری نیاز به تنظیم PCI compliance است.

در تنظیمات httpd.conf مورد زیر را اجرا کنید:

FileETag None

9– SCWS: انکار سرویس Mitigation

9–SCWS: تنظیم Timeout به 10 یا کمتر

شرح اجمالی:

دستور TimeOut حداکثر زمان را بر اساس ثانیه که سرویس دهنده وب آپاچی باید براي یک فراخوانی ورودي/ خروجی براي کامل شدن، منتظر بماند را تعیین می کند. لذا توصیه می گردد که مقدار TimeOut را بر روي 10 یا کمتر تنظیم نمایید.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

مقدار دستور Timeout را در پیکربندي آپاچی به 10 ثانیه و یا کمتر تغییر دهید.

Timeout 10

: SCWS-9تنظیم KeepAlive به On

شرح اجمالی:

دستور KeepAlive، استفاده مجدد آپاچی از اتصال TCP یکسان به ازاي هر کلاینت، به منظور آنکه بتواند درخواست هاي HTTP بعدي از آن کلاینت را کنترل کند، بکار می رود. توصیه می شود که دستور KeepAlive بر روي On تنظیم گردد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

به منظور فعال بودن ارتباطات Keepalive مقدار دستور KeepAlive را در پیکربندي Apache به مقدار On، اصلاح نمایید.

KeepAlive On

: SCWS-9تنظیم MaxKeepAliveRequest به 100 یا بیشتر

شرح اجمالی:

دستور MaxKeepAliveRequests تعداد درخواست هاي مجاز در هر اتصال را هنگامی که KeepAlive فعال باشد، محدود می کند. اگر این دستور با مقدار 0 تنظیم شود، درخواست هاي نامحدود، مجاز خواهند شد. لذا توصیه می گردد که دستور MaxKeepAliveRequest به 100 و یا بیشتر تنظیم شده باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

مقدار دستور MaxKeepAliveRequests را در پیکربندي Apache به مقدار 100 یا بیشتر اصلاح نمایید.

MaxKeepAliveRequests 100

: SCWS-9 تنظیم KeepAliveTimeout به 15 یا کمتر

شرح اجمالی:

تعداد ثانیه هایی را که آپاچی براي درخواست بعدي منتظر می ماند، قبل از این که اتصالی که فعال نگه داشته شده را ببندد، بوسیله دستور keepAliveTimeout مشخص می شوند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور KeepAliveTimeout را در پیکربندي Apache به منظور داشتن مقدار 15 یا کمتر، اضافه یا اصلاح نمایید.

KeepAliveTimeout 15

9–SCWS: تنظیم محدودیت Timeout براي درخواست Headers

شرح اجمالی:

دستور RequestReadTimeout اجازه پیکربندي محدودیت هاي زمانی براي درخواست هاي کلاینت را می دهد. بخش هدر دستور یک مقدار timeout اولیه، یک حداکثر timeout و یک میزان حداقل timeout ارائه می دهد. حداقل میزان timeout مشخص می کند که بعد از timeout اولیه، سرور 1 ثانیه بیشتر براي هر N بایت دریافت شده منتظر می ماند. تنظیمات توصیه شده به منظور داشتن یک حداکثر وقفه 40 ثانیه یا کمتر است. به خاطر داشته باشید که براي میزبان هاي مجازي SSL/TLS زمان براي handshake TLS باید در وقفه جاي داده شود.

نحوه پیاده سازی:

با استفاده از پیکربندي زیر ماژول mod_requesttimeout را در پیکربندي آپاچی بارگذاري نمایید.

LoadModule reqtimeout_module modules/mod_reqtimeout. so

دستور RequestReadTimeout همانند خط زیر با تنظیم ماکزیمم مقدار وقفه هدر درخواست بر روي

40 ثانیه یا کمتر اضافه نمایید.

RequestReadTimeout header=20-40, MinRate=500 body=20, MinRate=500

9–SCWS: تنظیم محدودیت Timeout براي درخواست Body

شرح اجمالی:

دستور RequestReadTimeout تنظیم مقادیر وقفه براي body یک درخواست را میسر می سازد. این دستور یک مقدار timeout اولیه، و یک حداکثر timeout و یک میزان حداقل timeout ارائه می کند. میزان حداقل مشخص می کند که بعد از timeout اولیه، سرور 1 ثانیه بیشتر براي هر N بایت دریافت شده منتظر خواهد ماند. تنظیمات توصیه شده به منظور داشتن یک حداکثر وقفه 20 ثانیه یا کمتر است که مقدار پیش فرض body=20،

است. MinRate=500

نحوه پیاده سازی:

با استفاده از پیکربندي زیر ماژول mod_requesttimeout را در پیکربندي آپاچی بارگذاري نمایید.

LoadModule reqtimeout_module modules/mod_reqtimeout. so

دستور RequestReadTimeout همانند خط زیر با تنظیم ماکزیمم مقدار وقفه body بر روي 20 ثانیه یا کمتر اضافه نمایید.

RequestReadTimeout header=20-40, MinRate=500 body=20,MinRate=500

10-SCWS: محدودیت هاي درخواست

SCWS-10-1: تنظیم دستور LimitRequest به 512 یا کمتر

شرح اجمالی:

دستور LimitRequestLine میزان حداکثر تعداد بایت هایی را که آپاچی از هر خط از یک درخواست HTTP می تواند بخواند را تنظیم می نماید. لذا توصیه می گردد که مقدار LimitRequestLine بر روي 512 و یا کمتر تنظیم شود.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

مقدار دستور LimitRequestline را در پیکربندي آپاچی به 512 یا کمتر تغییر دهید.

LimitRequestline 512

10–SCWS: اطمینان از تنظیم دستور LimitRequestFields به 100 یا کمتر

شرح اجمالی:

دستور LimitRequestFields حداکثر محدودیتی که بر روي تعداد هدرهاي درخواست HTTP که به ازاي هر درخواست اجازه داده می شوند، را مشخص می سازد. لذا توصیه می گردد که دستور LimitRequestFields به 100 و یا کمتر تنظیم شده باشد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور LimitRequestFields در پیکربندي Apache را براي داشتن مقدار 100 یا کمتر، اضافه یا اصلاح نمایید. اگر دستور موجود نباشد، به طور پیش فرض به پیکربندي زمان کامپایل بستگی دارد که مقدار پیش فرض 100 می باشد.

LimitRequestFields 100

: SCWS-10 تنظیم دستور LimitRequestFieldsize به 1024 یا کمتر

شرح اجمالی:

دستور LimitRequestFieldSize ماکزیمم اندازه فیلد هدر درخواست HTTP را تنظیم می کند. لذا توصیه می شود که دستور LimitRequestFieldSize بر روي 1024 یا کمتر تنظیم گردد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور LimitRequestFieldsize در پیکربندي Apache را براي داشتن مقدار 1024 یا کمتر اصلاح نمایید.

: SCWS-10 تنظیم دستور LimitRequestBody به 102400 یا کمتر

شرح اجمالی:

دستور LimitRequestBody حداکثر اندازه body درخواست HTTP را تنظیم می کند. لذا توصیه می شود که دستور LimitRequestBody بر روي 102400 یا کمتر تنظیم گردد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

دستور LimitRequestBody در پیکربندي Apache را براي داشتن مقدار 102400 (100K) یا کمتر، اضافه یا اصلاح کنید. لطفا مستندات Apache را مطالعه نموده سپس در می یابید که این دستور، اندازه ي آپلودهاي فایل به وب سرور را محدود می کند.

LimitRequestBody 102400

11-SCWS: فعال نمودن SELinux به منظور محدود نمودن فرآیندهاي Apache

Enforcing در حالت SELinux فعال نمودن: SCWS-11-1

شرح اجمالی:

Security-Enhanced Linux) SELinux) یک ماژول امنیتی هسته لینوکس می باشد و سیستم نظارتی آن براساس Mandatory Access Control) MAC) یا کنترل دسترسی اجباري با حالت Enforcing می باشد. این ماژول توسط آژانس امنیت ملی آمریکا ایجاد گردید و بر اساس سیاست هاي تعریف شده، قوانین مربوط به فایل ها و فرآیندها را در یک سیستم لینوکس اجرا و اقدامات مربوطه را محدود کند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

در صورت عدم فعال بودن SELinux در فایل پیکربندي، فایل /etc/selinux/config را ویرایش کرده و مقدار

SELinux را به حالت enforcing تغییر داده و سیستم را براي قبول پیکربندي جدید، مجدداً راه اندازي نمایید.

SELINUX=enforcing

اگر حالت جاري ، enforcing نیست و راه اندازي مجدد به صورت فوري، امکان پذیر نبود، می توان حالت جاري را با دستور setenacle به enforcing تنظیم نمود.

# setenforce 1

2–11–SCWS: اجراي فرآیندهاي آپاچی در متن محدود شده httpd_t

شرح اجمالی:

SELinux شامل سیاست هاي هدفمند قابل تنظیمی می باشد که ممکن است براي محدود کردن سرور http آپاچی براي اجراي حداقل امتیازات مورد استفاده قرار گیرد، به طوري که سرور httpd تنها حداقل دسترسی را به دایرکتوری ها، فایل ها و پورت هاي شبکه داشته باشد. دسترسی توسط انواع فرآیندهاي (دامنه ها) تعریف شده براي فرآیندهاي httpd کنترل می شود. بیش از صد httpd تکی مربوط به انواع تعریف شده در یک سیاست پیش فرض SELinux آپاچی وجود دارد که شامل بسیاري از افزونه ها و برنامه هاي متداول آپاچی مانند nagios ، php، smokeping و نمونه هاي دیگر می باشد. سیاست هاي پیش فرض SELinux براي نصب یک آپاچی پیش فرض به خوبی عمل می کنند، اما پیاده سازی سیاست هاي مورد نظر SELinux در زمینه یک وب سرور پیچیده یا بسیار سفارشی شده نیازمند یک توسعه نسبتاً قابل توجه و تست کردن مناسب آن است که هم روش کار SELinux و هم عملیات ها و الزامات دقیق برنامه وب را در بر می گیرد. تمام دایرکتوری ها و فایل ها براي این که توسط فرآیند وب سرور قابل دسترس باشند، باید برچسب هاي امنیتی مناسب داشته باشند.

در زیر نمونه هایی از پر استفاده ترین ها ارائه شده است:

http_port_t – پورت هاي شبکه مجاز براي شنود
httpd_sys_content_t – دسترسی خواندن به دایرکتوری ها و فایل ها با محتواي وب
httpd_log_t – دایرکتوری ها و فایل هایی که باید براي لاگ ها قابل نوشتن مورد استفاده قرار گیرند.
httpd_sys_script_exec_t – دایرکتوری ها و فایل هایی براي محتواي قابل اجرا.

نحوه پیاده سازی:

اگر فرآیندهاي httpd در حال اجرا به محتواي httpd-t SELinux محدود نشده باشند، محتوا را براي باینري httpd و باینري apachetl بررسی کرده و باینري httpd را براي داشتن محتواي http-exec-t و apachetl را براي داشتن محتواي initrc-exec-t مانند زیر، تنظیم کنید. همچنین، در نظر داشته باشید که بر روي برخی از پلتفرم ها مانند Ubuntu ، به جاي httpd، فایل اجرایی apache2 ، Apache نامیده می شود.

# ls -alZ /usr/sbin/httpd /usr/sbin/httpd. * /usr/sbin/apachectl

-rwxr-xr-x. root root system_u:object_r:initrc_exec_t:s0 /usr/sbin/apachectl

-rwxr-xr-x. root root system_u:object_r:httpd_exec_t:s0 /usr/sbin/httpd

-rwxr-xr-x. root root system_u:object_r:httpd_exec_t:s0 /usr/sbin/httpd. worker

-rwxr-xr-x. root root system_u:object_r:httpd_exec_t:s0 /usr/sbin/httpd. event

اگر فایل هاي اجرایی به درستی برچسب گذاري نشده باشند، ممکن است با دستور chcon دوباره برچسب گذاري شوند، با این حال، برچسب گذاري فایل سیستم، مبتنی بر سیاست هاي محتوایی فایل SELinux است و سیستم فایل ها در برخی موقعیت ها با توجه به این سیاست، مجددا برچسب گذاري می شوند.

# chcon -t initrc_exec_t /usr/sbin/apachectl

# chcon -t httpd_exec_t /usr/sbin/httpd /usr/sbin/httpd. *

از آنجایی که ممکن است سیستم فایل بر اساس سیاست SELinux دوباره برچسب گذاري شود، بهتر است سیاست SELinux با گزینه ي semanage fcontext “-l” بررسی شود. اگر این سیاست موجود نباشد، آنگاه الگو با استفاده از گزینه ي a”-” اضافه می شود. دستور restorecon که در زیر نشان داده شده، برچسب محتواي فایل را با توجه به سیاست جاري، بازیابی می کند و زمانی مورد نیاز می باشد که الگو اضافه شود.

# ### Check the Policy

# semanage fcontext -l | fgrep ‘apachectl’

/usr/sbin/apachectl regular file system_u:object_r:initrc_exec_t:s0

# semanage fcontext -l | fgrep ‘/usr/sbin/httpd’

/usr/sbin/httpd regular file system_u:object_r:httpd_exec_t:s0

/usr/sbin/httpd. worker regular file system_u:object_r:httpd_exec_t:s0

/usr/sbin/httpd. event regular file system_u:object_r:httpd_exec_t:s0

# ### Add to the policy, if not present

# semanage fcontext -f — -a -t httpd_exec_t ‘/usr/sbin/httpd’

# semanage fcontext -f — -a -t httpd_exec_t ‘/usr/sbin/httpd. worker’

# semanage fcontext -f — -a -t httpd_exec_t ‘/usr/sbin/httpd. event’

# semanage fcontext -f — -a -t initrc_exec_t /usr/sbin/apachectl

# ### Restore the file labeling accord to the SELinux policy

# restorecon -v /usr/sbin/httpd /usr/sbin/httpd. * /usr/sbin/apachectl

11-3–SCWS: اطمینان از عدم قرارگیري مد http_t بر روي Permissive

شرح اجمالی:

علاوه بر تنظیم کل پیکربندي SELinux در حالت مجاز، می توان انواع Process هاي مجزا (Domains) مانند httpd_t را در حالت مجاز نیز تنظیم نمود. حالت مجاز هیچ دسترسی و یا عملکردي را محدود نمی نماید، در عوض هر اقدامی که منع شده باشد را تنها Log می نماید.

نحوه پیاده سازی: در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

اگر http_t از نوع مجاز باشد، دراینصورت می بایست حالت مجاز سفارش شده با استفاده از دستور semanage حذف گردد.

# semanage permissive -d httpd_t

11-4–SCWS: اطمینان از فعال بودن بولین هاي ضروري SELinux

شرح اجمالی:

بولین هاي SELinux اجازه رفتار مختص وب سرور آپاچی را یا می دهند یا نمی دهند. نمونه هاي متداول در این خصوص عبارتند از این که آیا اجراي CGI مجاز است، یا آیا سرور httpd براي برقراري ارتباط با ترمینال فعلی (tty) مجاز است. برقراي ارتباط با ترمینال، ممکن است براي وارد کردن یک کلمه عبور به منظور رمزگشایی یک کلید خصوصی در طول راه اندازي، ضروري باشد.

نحوه پیاده سازی:

به منظور غیرفعال نمودن بولین هاي httpd که غیرضروري شناخته شده اند، از دستور setsebool به صورت زیر استفاده گردد که با استفاده از p ” option– ” اعمال تغییرات به صورت دائمی صورت می پذیرد.

# setsebool -P httpd enable cgi off

# getsebool httpd enable cgi

httpd_enable_cgi –> off

12-SCWS: فعال نمودن AppArmor به منظور محدود نمودن فرآیندهاي Apache

: SCWS-12 فعال نمودن AppArmor Framework

شرح اجمالی:

AppArmor یک ماژول امنیتی هسته لینوکس است که کنترل دسترسی اجباري مبتنی بر نام، به همراه سیاست هاي امنیتی ارائه می دهد. AppArmor قوانین مربوط به برنامه ها را به منظور دسترسی فایل، اتصالات شبکه و محدود کردن اقدامات مبتنی بر سیاست هاي تعریف شده اجرا می کند.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

درصورت عدم وجود دستور aa-status، بسته AppArmor نصب نشده و نیاز به نصب یک بسته مناسب مدیریتی از توزیع لینوکس می باشد. به عنوان مثال:

# apt-get install apparmor

# apt-get install libapache2-mod-apparmor

مطابق با شرح زیر به منظور فعالسازي فریم ورك AppArmor می بایست اسکریپت d اجرا گردد.

# /etc/init. d/apparmor start

12–SCWS: سفارشی نمودن مشخصات AppArmor آپاچی

شرح اجمالی:

AppArmor شامل پروفایل هاي قابل تنظیمی می باشد که براي محدود کردن وب سرور آپاچی به اجراي حداقل امتیازات مورد استفاده قرار می گیرد به طوري که سرور تنها حداقل دسترسی را به دایرکتوری ها، فایل ها و پورت هاي شبکه داشته باشد. دسترسی به وسیله پروفایلی که براي process مخصوص apache2 تعریف شده کنترل می گردد. پروفایل پیش فرض AppArmor معمولاً یک پروفایل مجاز است که اجازه دسترسی خواندن-نوشتن را به تمام سیستم فایل ها می دهد. بنابراین توجه به این نکته مهم است که پروفایل پیش فرض به منظور به اجرا درآوردن حداقل امتیازات، سفارشی شود. از ابزارهاي AppArmor مانند aacomplain ، aa-autodep، و aa-logprof را می توان جهت ایجاد یک پروفایل اولیه براساس استفاده واقعی بهره برد. با این حال، تست کامل، بررسی و سفارشی سازي براي اطمینان از این که محدودیت هاي پروفایل آپاچی قابلیت هاي لازم را در حین پیاده سازی حداقل امتیازات میسر می سازند، ضروري خواهد بود.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

سرور Apache را متوقف کنید.

# service apache2 stop

پروفایل خالی apache2 را بر اساس وابستگی هاي برنامه ایجاد نمایید.

# aa-autodep apache2

Writing updated profile for /usr/sbin/apache2

پروفایل apache2 را در حالت complain تنظیم نمایید، به طوري که اقدامات مقابل تخلفات دسترسی اجازه اجرا داده شده و لاگ ثبت گردد.

# aa-complainapache2

Setting /usr/sbin/apache2 to complain mode.

سرویس apache2 را آغاز نمایید.

# service apache2 start

برنامه ي تحت وب را با بررسی همه ي قابلیت ها به صورت کامل تست نمایید، به طوري که AppArmor، همه ي لاگ ها ضروري از منابع در دسترس را تولید کند. لاگ ها از طریق ابزار syslog فرستاده شده و معمولاً در یکی از فایل هاي /var/log/syslog یا /var/log/messages یافت می شوند. همچنین لازم بذکر است، متوقف کردن و راه اندازي مجدد وب سرور نیز، بخشی از فرآیند تست می باشد.
از aa-logprof براي بروزرسانی پروفایل بر اساس لاگ ها تولید شده در طول تست، استفاده نمایید. این ابزار براي اصلاحات پیشنهادي بر روي پروفایل، بر اساس لاگ ها به کار گرفته می شود. همچنین، ممکن است لاگ ها به منظور بروزرسانی پروفایل، به صورت دستی مجدداً مورد بازنگري قرار داده شوند.

# aa-logprof

با حذف محتواي نامناسب و اضافه کردن قوانین دسترسی مناسب، پروفایل را بررسی و ویرایش کنید.

دایرکتوری هاي با فایل هاي در دسترس و با مجوزهاي مشابه می توانند با استفاده از wild-cardها ساده شوند. همچنین پروفایل بروزرسانی شده را با استفاده از دستور apparmorparser مجددا بارگذاري نمایید.

# apparmor_parser -r /etc/apparmor. d/usr. sbin. apache2

پروفایل بروز شده جدید را براي بررسی مجدد لاگ ها رد شده ي apparmor تست نمایید. پروفایل را در صورت لزوم، بروزرسانی کرده و مجدداً بارگذاري نمایید. همچنین تست هاي برنامه را تا زمانی که هیچ لاگ رد شده ي apparmor ایجاد نشده ( به جز دسترسی که بایستی ممنوع باشد) تکرار نمایید.

# tail -f /var/log/syslog

پروفایل apache2 را در حالت enforce قرار داده، apparmor را مجددا بارگذاري نموده و سپس عملکرد وب سایت را مجددا تست نمایید.

# aa-enforce /usr/sbin/apache2

# /etc/init. d/apparmor reload

3–12–SCWS: اطمینان از قرارگیري پروفایل AppArmor در حالت Enforce

شرح اجمالی:

پروفایل هاي AppArmor ممکن است در یکی از این سه حالت باشند: complain ، disable یا enforce. در حالت enforce، هر گونه تخطی از کنترل هاي دسترسی ثبت می شود، اما محدودیتی اجرا نمی شود. همچنین توصیه می شود هنگامی که حالت یک پروفایل تغییر پیدا کرد لذا لازم است که سرور آپاچی مجدد راه اندازي شود، در غیر اینصورت فرآیند در حال اجرا ممکن است با این سیاست محدود نگردد.

نحوه پیاده سازی:

در راستاي پیاده سازي وضعیت توصیه شده موارد زیر را اجرا نمایید:

وضعیت پروفایل را در حالت enforce تنظیم نمایید.

# aa-enforce apache2 Setting /usr/sbin/apache2 to enforce mode.

فعالیت سرور آپاچی را متوقف نموده و از عدم اجراي آن اطمینان حاصل نمایید. در برخی موارد ممکن است AppArmor از متوقف شدن صحیح وب سرور جلوگیري و ممانعت نماید که در این حالت شاید نیازمند متوقف نمودن دستی سرویس و یا راه اندازي مجدد سرور باشیم.

# service apache2 stop

Stopping web server apache2

# service apache2 status

apache2 is not running
سرویس آپاچی را مجدد راه اندازي نمایید.

# service apache2 start

* Starting web server apache2

نکات امنیتی Apache Http Server 2.4.x

برخی از اشارات و نکات مربوط به مسائل امنیتی در راه اندازی یک سرور وب، اشاره شده است. برخی از پیشنهادات کلی هستند، برخی دیگر مختص سرور آپاچی هستند.

13.1 بروز نگه داشتن آپاچی (Keep up to Date)

HTTP سرور آپاچی رکورد های خوبی برای مسائل امنیتی دارد و دارای یک جامعه توسعه دهنده که در مورد مسائل امنیتی توجه ویژه ای دارند. اما برخی از مشکلات اجتناب ناپذیر است، کوچک یا بزرگ بودن آن بعد از انتشار نرم افزار کشف خواهند شد. به همین دلیل، حفظ آگاهی ها از به روز رسانی ها (updates) های داده شده به نرم افزار ها بسیار مهم است. اگر نسخه خود را از HTTP سرور آپاچی به صورت مستقیم به دست آورده اید، به شدت توصیه می کنیم که در لیست اعلان های (Announcements List) HTTP سرور آپاچی اطلاعات خود را با دیگران به اشتراک بگذارید تا بتوانید از اطلاعات جدید و به روزسانی های جدید امنیتی مطلع باشید. خدمات مشابه از سوی عامل های سوم، توزیع کنندگان نرم افزار آپاچی در دسترس است.

البته، اغلب اوقات زمانی که یک سرور وب به خطر می افتد، علت آن به دلیل مشکل موجود در کد HTTP سرور آن نیست. در عوض، این مسئله ناشی از مشکلات مربوط به اضافه کردن کد، اسکریپت های CGI یا سیستم عامل می باشد. بنابراین مهم است که شما باید از مشکلات و بروز رسانی ها از سیستم نرم افزاری خود آگاه باشید.

13.2 حملات منع سرویس (DOS)

تمام سرور های شبکه می توانند در معرض حملات منع سرویس قرار گیرند که تلاش می کنند با گره زدن منابع سرور از پاسخ به کلاینت ها جلوگیری کنند. جلوگیری از چنین حملاتی ممکن نیست، اما شما می توانید کارهایی را انجام دهید تا مشکلاتی که ایجاد شده را کاهش دهید.

اغلب موثرترین ابزار ضد حملات DOS، یک فایروال یا تنظیمات سیستم های عامل هستند. برای مثال، بیشتر فایروال ها می توانند برای محدود کردن تعداد اتصالات همزمان از هر آدرس IP مجزا یا شبکه ای شکل بگیرند در نتیجه از گستره ای از حملات ساده جلوگیری می کنند. البته این مورد هیچ کمکی علیه حملات منع سرویس توزیع شده (DDOS) نمی کند.

همچنین تنظیمات پیکربندی Apache Server HTTP نیز وجود دارد که می تواند به کاهش مشکلات کمک کند:

دستورالعمل های RequestReadTimeout اجازه می دهد زمان ارسال درخواست کلاینت محدود شود.
TimeOut و دستورات مربوط به آن بایستی در سایت هایی که مربوط به حملات DoS هستند، کاهش یابند. تنظیم این مسئله تا زمانی که در حد چندثانیه کوتاه باشد، مناسب است. همانطور که TimeOut در حال حاضر برای چندین عملیات مختلف استفاده می شود، تنظیم آن به یک مقدار پایین، مشکلاتی را با استفاده از اسکریپت های CGI در طول اجرا بلند مدت ایجاد می کند.
دستورالعمل KeepAliveTimeout در سایت هایی که مستعد به حملات DoS هستند، خطرات را کاهش می دهد. برخی از سایت ها به طور کامل keepalives را با viaKeepAlive خاموش می کنند که البته اشکالاتی را در عملکردشان ایجاد می کنند.
مقادیر دستورالعمل های مربوط به مدت زمان مختلف ارائه شده توسط ماژول های دیگر بایستی بررسی شوند.
دستورالعمل های LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine و LimitXMLRequestBody بایستی به دقت بررسی شوند تا مصرف منابع ایجاد شده توسط درخواست کلاینت را محدود کنند.
سیستم عامل هایی که از آن ها پشتیبانی می کنند مطمئن شوید که از دستورالعمل های AcceptFilter برای انتقال بخشی از پردازش درخواست به سیستم عامل استفاده می کنید. این مورد به طور پیش فرض در Apache httpd فعال است، اما ممکن است نیازمند پیکربندی(تنظیمات) مجدد kernel (هسته) شما باشد.
تنظیم دستورالعمل MaxRequestWorkers برای اجازه دهی به سرور برای مدیریت به حداکثر تعداد اتصالات همزمان بدون استفاده از منابع. همچنین برای تنظیم کارآیی آنها به اسناد مربوطه شان مراجعه کنید.
استفاده از mpm threaded ممکن است به شما این امکان را دهد که ارتباطات همزمان بیشتری را کنترل کنید در نتیجه حملات DoS را کاهش دهید. علاوه بر این، رویداد mpm از پردازش غیرهمزمان برای اجتناب از اختصاص یک رشته (thread) به هر اتصال استفاده می کند. به دلیل ماهیت کتابخانه OpenSSL، رویداد mpm درحال حاضر با mod_ssl و دیگر فیلترهای ورودی ناسازگار است. در این موارد در دسته رفتار worker mpm قرار می گیرید.
تعدادی از ماژول های عامل سوم وجود دارد که از طریق http://modules.apache.org/ موجود است و می تواند رفتارهای خاص کلاینت را محدود کند و در نتیجه مشکلات و مسائل DoS را کاهش دهد.

13.3 مجوز های مربوط به دایرکتوری های ServerRoot (Permissions on ServerRoot Directories)

در یک عملیات معمول، Apache توسط کاربر root راه اندازی(start) می شود، و به کاربر تعریف شده توسط User directive برای serve hits (دادن خدمت) تغییر داده می شود. همانطور که در مورد هر فرمان که توسط root اجرا می شود، بایستی مراقبت باشید که از تغییرات توسط کاربران غیر root محافظت شود. نه تنها فایل ها بایستی با دسترسی root نوشته شوند بلکه بایستی دایرکتوری ها و همه دایرکتوری های والد نیز توسط دستور root نوشته شوند.

برای مثال، اگر می خواهید ServerRoot را در مکان usr/local/apache انتخاب کنید پیشنهاد می شود که دایرکتوری را به عنوان root ایجاد کنید با عبارت هایی مانند موارد زیر این کار انجام می شود:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

فرض بر این است که /, /usr و /usr/local محل هایی هستند که تنها با دسترسی root قابل تغییر هستند. زمانی که فایل قابل اجرای httpd را نصب می کنید بایستی اطمینان حاصل کنید که به طور مشابه محافظت می شوند:

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

شما می توانید یک زیر دایرکتوری htdocs قابل تغییر به کاربران دیگر را ایجاد کنید – چون کاربر root هیچ فایلی خارج از آن را نمی تواند اجرا کند، و نباید در آنجا پرونده هایی ایجاد کند.

اگر به کاربران غیر root اجازه دهید هر فایلی را اصلاح کنند در صورتی که فقط کاربر root می تواند آن را اجرا یا بنویسد بنابراین شما سیستم خود را نسبت به خطرات مجوزهای دسترسی root ، آسیب پذیر می کنید. برای مثال، یک نفر می تواند باینری httpd را جایگزین آن کند به طوری که در دفعات بعدی زمانی که آن را شروع کردید، یک کد مخرب دلخواه فرد اجرا شود. اگر دایرکتوری لاگ فایل قابل نوشتن باشد (توسط کاربری غیر root)، ممکن است کسی فایل لاگی را با یک فایل symlink به یک فایل سیستمی دیگری جایگزین کند و سپس ممکن است root آن فایل ایجاد شده را با داده های خود بازنویسی کند. اگر فایل های لاگ خودشان قابل نوشتن باشند (توسط کاربر غیر root)، پس ممکن است یک نفر بتوانند فایل لاگ را با داده های ساختگی (bogus) پر کند.

13.3.1 Include های سمت سروری (Server Side Includes)

Include های سمت سرور (SSI) مدیر سرور را با چندین خطر بالقوه امنیتی روبرو می کند.

اولین خطر load شدن افزایشی روی سرور است. تمام فایل ها با قابلیت فعال شدن SSI بایستی توسط آپاچی تجزیه (parsed) شوند اگرچه دستورالعمل های SSI وجود داشته باشند که در فایل ها، Include شده اند. در حالی این افزایش بار(load) جزئی باشد که این موارد در محیط اشتراک گذاشته شده می توانند قابل توجه باشند.

فایل های SSI نیز همان خطراتی را نشان می دهند که با اسکریپت های CGI در حالت کلی مرتبط هستند. با استفاده از عنصر cmd exec، فایل های قابل فعال سازی SSI می توانند هر گونه اسکریپت CGI یا برنامه کامپیوتری تحت کنترل کاربر و گروه Apache را اجرا کند، همانطور که در httpd.conf پیکربندی (configured) شده است.

راه هایی برای افزایش امنیت پرونده های SSI وجود دارد در حالی که هنوز از مزایایی که ارائه می دهند بهره می بریم.

برای جدا کردن (ایزوله کردن) یک آسیب، فایل SSI می تواند عامل آن باشد، مدیر سرور می تواند suexec را به گونه ای که در بخش عمومی CGI توضیح داده شده است، فعال کند.

فعال کردن SSI برای فایل ها با پسوند .html یا .htm می تواند خطرناک باشد. این امر به خصوص در یک محیط اشتراکی و یا ترافیک بالای محیط سرور صدق می کند. فایل هایی با قابلیت فعال سازی SSI هم بایستی یک پسوند جداگانه داشته باشند، مانند پسوند های مرسوم .shtml این کار به نگه داشتن load مناسب سرور در حداقل و امکان مدیریت آسان ریسک کمک می کند.

راه حل دیگر، غیرفعال کردن اجرای اسکریپت ها و برنامه ها از صفحات SSI است. برای انجام این کار، Includes را با IncludesNOEXEC در گزینه های دستورالعمل جایگزین کنید. توجه داشته باشید که کاربران هنوز هم ممکن است از include virtual=”…” –> #<– برای اجرای اسکریپت های CGI استفاده کنند در صورتی که این متن در دایرکتوری های تعیین شده توسط دستور العمل ScriptAlias طراحی شده است.

تنظیمات مربوطه در آپاچی نسخه 2.4.x بدین صورت می باشد.

به دایرکتوری $Web_Server/conf بروید. و httpd.conf را باز کنید. دایرکتوری را جستجو می کنید و دستور العمل زیر را اضافه کنید.

Options-Indexes_Includes

Order allow, denyAllow from all

</Directory>

CGI 13.4 به صورت کلی (CGI in General)

در ابتدا، همیشه بایستی به خاطر داشته باشید که به نویسندگان اسکریپت ها/ برنامه های CGI و توانایی آنها در تشخیص حفره های امنیتی بالقوه در کامپیوتر اعتماد داشته باشید، چه آنها موارد را به صورت آگاهانه و یا به صورت تصادفی انجام دهند. اسکریپت های CGI می توانند اساساً دستور دلخواه خود را بر روی سیستم شما با سطح مجوز دسترسی کاربر وب سرور اجرا کنند بنابراین اگر به صورت دقیق بررسی نشده باشند می توانند بسیار خطرناک باشند.

همه ی اسکریپت های CGI در همان کاربر موجود اجرا خواهند شد، بنابراین آنها پتانسیل تصادم (عمدی یا صحفی) را با اسکریپت های دیگر دارند به عنوان مثال کاربر A از کاربر B تنفر دارد، بنابراین یک اسکریپت به “پایگاه داده CGI” کاربر B می نویسد و آن را حذف می کند. یک برنامه که می تواند برای اجازه دادن به اسکریپت ها برای اجرا به عنوان کاربران مختلف استفاده شود suEXEC است که با Apache به نام 1.2 استفاده می شود و تله ی خاص (special hooks) در کد سرور آپاچی نامیده می شود. یک روش محبوب دیگر برای انجام این کار استفاده از CGIWrap است.

13.4.1 نام جایگزین (مستعار) غیر اسکریپتی CGI (Non Script Aliased CGI)

اجازه دادن به کاربران برای اجرای اسکریپت های CGI در هر دایرکتوری بایستی تنها در صورتی در نظرگرفته شود که:

شما به کاربران خود اطمینان دارید که عمدی یا صحفی اسکریپتی ننویسند و سیستم شما را در معرض حمله قرار دهند.
شما بایستی امنیت سایت خود را در مناطق دیگر هم در نظر بگیرید تا منطقه ای بسیار ضعیف نباشد، در نتیجه یک حفره بالقوه دیگر را بی اهمیت نشان ندهد.
شما هیچ کاربری و هیچ کسی را ندارید که از سرور شما بازدید کند.

13.4.2 اسکریپت های جایگزین CGI (Script Aliased CGI)

محدود کردن CGI به دایرکتوری های خاصی، کنترل Admin (مدیر) را در مورد آنچه که در دایرکتوری ها قرار دارد باعث می شود. این امر به طور اجتناب ناپذیر امن تر از اسکریپت های non script aliased CGI است، اما تنها در صورتی کاربرانی که به دایرکتوری ها دسترسی نوشتن داشته باشند، مورد اعتماد خواهند بود و یا مدیر مایل باشد هر برنامه/ اسکریپت جدید CGI را برای حفره های امنیتی بالقوه امتحان کند.

اغلب سایت ها این گزینه ها را بر روی رویکرد non script aliased CGI انتخاب می کنند.

13.5 منابع دیگر محتوای پویا (Other sources of dynamic content)

گزینه های اسکریپت های توکار(جاسازی شده) که به عنوان بخشی از خود سرور اجرا می شود، مانند mod_php, mod_perl, mod_tcl و mod_python تحت هویت خود سرور اجرا می شوند (دستورالعمل های کاربر را ببینید)، و بنابراین اسکریپت های اجرا شده توسط این موتور ها به طور بالقوه می توانند به هر چیزی که کاربر دسترسی دارد دسترسی پیدا کنند. برخی از موتور های اسکریپت ممکن است محدودیت هایی را ایجاد کنند، اما بهتر است ایمن باشند و موردی را از قبل فرض نکنند.

13.5.1 امنیت محتوای پویا (Dynamic content security)

هنگامی که محتوای پویا را تنظیم می کنید، مانند mod_php, mod_perl یا mod_python بسیاری از ملاحظات امنیتی از محدوده خود httpd خارج می شوند و شما بایستی از اسناد خود ماژول ها استفاده کنید. برای مثال، PHP به شما اجازه می دهد تا حالت ایمن (Safe Mode) را راه اندازی کنید، که اغلب به صورت پیش فرض غیرفعال می شود. برای اطلاعات بیشتر در مورد آن، هر سند پروژه را مطالعه کنید.

در سطح آپاچی، یک ماژول به نام mod_security را می توان به عنوان یک فایروال HTTP مشاهده کرد و اگر به خوبی آن را پیکربندی (configure) کنید، می تواند به شما کمک کند تا امنیت محتوای پویای خود را افزایش دهید.

13.6 محافظت از تنظیمات سیستم (Protecting System Settings)

برای هدایت یک کشتی در محدوده باریک، شما بایستی کاربران را از تنظیمات فایل .htaccess باز دارید که با انجام این کار می توانند مشخصه های امنیتی که از قبل پیکربندی نموده اید، را باز نویسی کنند. فقط یک راه حل برای انجام این کار وجود دارد.

در فایل پیکربندی سرور قرار دهید:

<Directory “/”> AllowOverride None</Directory>

این کار مانع از استفاده از فایل .htaccess در تمام دایرکتوری ها جدا از آنهایی که فعال سازی شده اند، می شود.

توجه داشته باشید این تنظیمات به صورت پیش فرض در آپاچی 2.39 موجود هستند.

13.7 محافظت فایل های پیش فرض سرور (Protect Server Files by Default)

یک جنبه از آپاچی که گهگاهی به اشتباه فهمیده می شود، ویژگی دسترسی پیش فرض است. یعنی اگر شما برای تغییر آن اقدام لازمی را انجام ندهید، سرور بتواند راه خود را به پرونده از طریق نگاشت قوانین URL معمولی پیدا کند، بنابراین می تواند به تقاضای کلاینتان خدمت دهد.

مثال زیر را در نظر بگیرید:

# cd /; ln -s / public_html
Accessing http://localhost/~root/

این مورد به کلاینت ها اجازه می دهد تا کل فایل سیستم (filesystem) را طی کنند. برای کار در این مورد، بلوک زیر را به پیکربندی سرور اضافه کنید:

<Directory “/”> Require all denied</Directory>

این مورد باعث جلوگیری از دسترسی پیش فرض به موقعیت های فایل سیستم (filesystem) خواهد شد. بلوک های راهنمای مناسبی را اضافه کنید تا تنها به مناطقی که می خواهید دسترسی داشته باشید. برای مثال:

<Directory “/usr/users/*/public_html”> Require all granted</Directory><Directory “/usr/local/httpd”> Require all granted</Directory>

توجه ویژه ای به تعاملات موقعیت و دستورالعمل های دایرکتوری توجه داشته باشید، به عنوان مثال، حتی اگر <Directory “/” > دسترسی را منع می کند، یک دستور العمل <Location “/”> ممکن است آن را تغییر دهد.

همچنین نسبت به بازی کردن با دستورالعمل UserDir محتاط باشید، و آن را به چیزی به این مورد ./ تنظیم کنید که همان تأثیر قبلی را خواهد داشت. برای root، به عنوان مثال در بالا ما قویاً توصیه می کنیم که خط زیر را در فایل های پیکره بندی سرور خود بگنجانید:

UserDir disabled root

13.8 به لیست log ها هم توجه کنید (Watching Your Logs)

برای به روز نگه داشتن آنچه که در سرور علیه شما در حال انجام است بایستی فایل های لاگ را بررسی کنید. حتی با وجود اینکه فایل های لاگ فقط گزارش می دهند که چه اتفاقاتی واقعاً رخ داده است، آنها به شما درکی از آنچه که حملات سرور انجام شده است را خواهند داد و اجازه بررسی می دهند که آیا سطح لازم از امنیت وجود دارد یا نه.

یک جفت مثال:

grep -c “/jsp/source.jsp?/jsp/ /jsp/source.jsp??” access_log
grep “client denied” error_log | tail -n 10

اولین مثال، تعداد حملاتی را که برای بهره برداری از آپاچی Tomcat برای تقاضا های مخرب Source.JSP از آسیب پذیری افشای اطلاعات را لیست می کند. مثال دوم، ده کلاینت آخر منع شده را می دهد به عنوان مثال:

[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

همانطور که می توانید ببینید، فایل های لاگ تنها گزارشی می دهند که چه اتفاقاتی رخ داده است، بنابراین اگر کلاینت بتواند به فایل .htpasswd دسترسی داشته باشد. ممکن است چیزی شبیه به این مورد اتفاق بیفتد:

foo.example.com – – [12/Jul/2002:01:59:13 +0200] “GET /.htpasswd HTTP/1.1”

در log دسترسی شما. این مورد بدان معنی است که شما احتمالاً موارد زیر را در پرونده پیکربندی کارگزار خود بیان کرده اید:

<Files “.ht*”> Require all denied</Files>

13.9 ادغام بخش های پیکربندی (Merging of configuration sections)

ادغام بخش های پیکربندی پیچیده و گاهی اوقات دستور خاصی لازم دارد. همیشه هنگام ایجاد وابستگی های مربوط به نحوه ادغام دستورها، تغییرات خود را تست کنید.

برای ماژول هایی که هیچ منطق ادغام مانند mod_access_compat را اجرا نمی کند رفتار در بخش های بعدی بستگی به این دارد که بخش بعدی هر دستورالعمل از ماژول را داشته باشد. این پیکربندی تا زمانی به ارث می رسد که یک تغییر ایجاد شود، که در آن نقطه پیکربندی جایگزین و ادغام نشده باشد.

امنیت نرم افزار تحت وب

وب سرور آپاچی و تنظیمات غلط آن یا به درستی محکم نشده اند و می توانند از نرم افزار تحت وب بهره کشی کنند. محکم کردن پیکربندی سرور دشواری خاصی داشته باشد.

14.1 کوکی ها

14.1.1 غیرفعال کردن درخواست Trace HTTP :

به طور پیش فرض متد Trace در وب سرور های آپاچی فعال است. فعال بودن این مورد می تواند حمله ی Cross Site Tracing را به دنبال داشته باشد و به مهاجم فرصت دزیده شدن اطلاعات کوکی شما را بدهد. در هنگام telnet به درخواست Trace به سروری روی پورت مشخص ، آن سرور پاسخ درخواست را می دهد برای غیرفعال کردن آن بایستی اقدامات زیر را انجام دهیم:

به دایرکتوری $Web_Server/conf بروید و دستورالعمل زیر را وارد کرده و در httpd.conf ذخیره کنید.

Restart apache

14.1.2 کوکی را با مقدار HttpOnly و پرچم ایمن مقدار دهی کنید

شما می توانید اغلب حملات cross site scripting را با استفاده از HttpOnly و مسدود کردن پرچم ایمن در کوکی، کاهش دهید. بدون داشتن HttpOnly و پرچم ایمن، امکان سرقت یا دستکاری نشست ها در نرم افزار کاربردی وبی و کوکی آنها وجود دارد و این مورد خطرناک است.

پیاده سازی:

اطمینان حاصل کنید mod_headers.so در تنظیمات httpd.conf فعال است. به مسیر دایرکتوری $Web_Server/conf بروید و در httpd.conf دستورات زیر را ذخیره کنید.

Header edit Set-Cookie ^(.*)$$1; HttpOnly; Secure

14.2 حمله clickjacking

Clickjacking آسیب پذیری شناخته شده ای در نرم افزار وبی است.

پیاده سازی:

اطمینان حاصل کنید که mod_headers.son در httpd.conf فعال است. به دایرکتوری $web_server / conf بروید و در httpd.conf دستورات زیر را ذخیره کنید.

Header always append x-Frame-Options SAMEORIGIN

14.3 حفاظت XSS

حفاظت حمله ی xss می تواند در بسیاری از مرورگرها دور زده شوند. شما می توانید این حفاظ را برای نرم افزاری وبی خود به کار ببرید اگر این مورد توسط توسط کاربر غیرفعال شده باشد.

پیاده سازی:

اطمینان حاصل کنید که mod_headers.so در httpd.conf فعال است. به دایرکتوری $web_server /conf بروید و در httpd.conf دستورات زیر را ذخیره کنید.

Header set X-SS-Protection “1; mode=block”

14.4 پروتکل HTTP 1.0 را غیر فعال کنید.

زمانی در مورد امنیت صحبت می کنیم، بایستی بیش از بیش حفاظت را رعایت کنیم. چرا بایستی ما از نسخه قدیمی HTTP استفاده کنیم، بنابراین بایستی آن را غیرفعال کنیم.

HTTP 1.0 ضعف امنیتی نسبت به ربایش نشست ها دارد. با استفاده از ماژول mod_rewrite می توانیم آن را غیرفعال کنیم.

پیاده سازی:

اطمینان حاصل کنیم که ماژول mod_rewrite در فایل httpd.conf لود شده است.

دستورالعمل RewriteEngine را فعال کنید در مثال زیر و شرط Rewrite را برای اجازه به only HTTP 1.1 اضافه کنید.

RewriteEngine On

RewriteCond %{THE_REQUEST}

!HTTP/1.1$

RewriteRule .*-[F]

پیوست

در این بخش چک لیستی به منظور ممیزي محصول مورد نظر ارائه شده است. این چک لیست شامل سه جدول است. جدول اول، جدول ممیز می باشد. در این جدول، اطلاعات مربوط به شخصی که پیکربندي امن را انجام می دهد یا آن را ممیزي می کند، وارد می شود. همچنین نتایج پیکربندي یا ممیزي به صورت اختصار در این جدول درج می گردد. جدول دوم، محل وارد کردن مشخصات سروري است که Apache HTTP Server روي آن نصب شده است. جدول سوم، جدول تنظیماتی است که باید بررسی یا اعمال شوند. در صورت صحت اعمال تنظیم در هر ردیف، ستون وضعیت مربوط به آن با علامت √ نمایش داده خواهد شد.

ممیز
تاریخ:		نام: ایمیل: تلفن:	ممیز:
توضیحات	تعداد	تنظیمات
			تطابق
		عدم تطابق
		تنظیمات حذف شده
		تنظیمات اضافه شده
		مجموع تنظیمات اعمال شده

مشخصات سرور
	آدرس MAC
	آدرس IP
	نام ماشین
	شماره اموال
نام : ایمیل:
تلفن:	مدیر سیستم
	تاریخ

جدول ممیزي

جدول ممیزي خلاصه اي از تمامی الزامات بیان شده در متن سند می باشد. قابل ذکر است که ستون هاي “وضعیت” و “قابلیت پیاده سازی” باید توسط ممیز و براي هر سیستم حاوي این برنامه تکمیل گردد. در ستون وضعیت، ممیز باید از عبارت هاي “قبول” و “رد” متناسب با وضعیت الزام در محصول مورد ارزیابی استفاده نماید. در ستون قابلیت پیاده سازی، ممیز باید قابلیت پیاده سازی الزام براي محصول مورد ارزیابی را با عبارات “دارد” و “ندارد” بیان نماید. در صورتی که الزامی براي محصول مذکور قابلیت پیاده سازی نداشته باشد، علت عدم قابلیت پیاده سازی آن باید در ذیل جدول توضیح داده شود.

مقدار مطلوب	مقدار پیش فرض	قابلیت پیاده سازی تنظیمات	تنظیمات	وضعیت	شناسه
			برنامه ریزي و راه اندازي		SCWS 1
تهیه چک لیست و اعمال آن	ندارد	دارد	تهیه چک لیست برنامه ریزي پیش از راه اندازي		SCWS- 1-1
غیرفعال	فعال	دارد	عدم نصب سرویس هاي مختلف بر روي یک سرور		SCWS- 1-2
استفاده از معیار منتشر شده جهت نصب	ندارد	دارد	نصب Apache		SCWS 1-3
			به حداقل رساندن ماژول هاي Apache		SCWS 2
فعال	ندارد	دارد	فعال نمودن ماژول هاي احراز هویت و اعطاي مجوز ضروري		SCWS 2-1
فعال	ندارد	دارد	فعال نمودن ماژول پیکربندي Log		SCWS 2-2
غیرفعال	ندارد	دارد	غیرفعال نمودن ماژول WebDAV		SCWS 2-3
غیرفعال	ندارد	دارد	غیرفعال نمودن ماژول Status		SCWS 2-4
غیرفعال	ندارد	دارد	غیرفعال نمودن ماژول Autoindex		SCWS 2-5
غیرفعال	ندارد	دارد	غیرفعال نمودن ماژول Proxy		SCWS 2-6
غیرفعال	ندارد	دارد	غیرفعال نمودن ماژول هاي دایرکتوری هاي کاربر		SCWS 2-7

غیرفعال	ندارد	دارد	غیرفعال نمودن ماژول info	SCWS 2-8
			اصول، مجوزها و مالکیت	SCWS 3
اجرا با کاربري غیر root و Group و User پیکربندي	ندارد	دارد	اجراي وب سرور Apache با کاربري غیر root	SCWS 3-1
در نظر گرفتن پوسته نامعتبر یاnologin به منظور ورود	ندارد	دارد	درنظر گرفتن پوسته نامعتبر براي حساب کاربري آپاچی	SCWS 3-2
استفاده از دستور passwd به منظور غیرفعال نمودن حساب کاربري	ندارد	دارد	قفل نمودن حساب کاربري Apache	SCWS 3-3
مطابق نحوه پیاده سازی اجرا گردد.	به صورت پیش فرض مالکیت از آن کاربري می باشد که نرم افزار را ایجاد کرده و کاربر root	دارد	تنظیم مالکیت بر روي دایرکتوری ها و فایل هاي Apache	SCWS 3-4
مطابق نحوه پیاده سازی اجرا گردد.	به صورت پیش فرض مالکیت از آن کاربري می باشد که نرم افزار را ایجاد کرده و کاربر root	دارد	تنظیم شناسه گروه بر روي دایرکتوری ها و فایل هاي Apache	SCWS 3-5
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	محدود کردن دیگر دسترسی هاي Write بر روي دایرکتوری ها و فایل هاي Apache	SCWS 3-6
تنظیم دستور CoreDumpDirectory براي دایرکتوری هاي متعلق به کاربر ریشه	ندارد	دارد	امن نمودن دایرکتوري Core Dump	SCWS 3-7
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	Lock File امن نمودن	SCWS 3-8
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	امن نمودن Pid فایل	SCWS 3-9
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	امن نمودن فایل ScoreBoard	SCWS 3-10
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	محدود کردن دسترسی هاي Write گروه بر روي دایرکتوری ها و فایل هاي Apache	SCWS 3-11
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	محدود نمودن دسترسی Write گروه بر روي ریشه اصلی پوشه و فایل ها	SCWS 3-12

			کنترل دسترسی آپاچی	SCWS 4
مسدود کردن دسترسی به دایرکتوري ریشه سیستم عامل	ندارد	دارد	منع دسترسی به دایرکتوري ریشه OS	SCWS 4-1
استفاده از از دستورات Allow Require یا	مطابق بند 1 از توضیحات پیش فرض جدول	دارد	اجازه دسترسی مناسب به محتواي وب	SCWS 4-2
تنظیم مقدار بر روي AllowOverride none	<Directory /> … AllowOverride None … </Directory>	دارد	محدودسازي نادیده گرفتن براي دایرکتوري ریشه OS	SCWS 4-3
تنظیم مقدار همه دستورهايAllowOverride بر روي none	ندارد	دارد	محدودسازي نادیده گرفتن OverRide براي کلیه دایرکتوری ها	SCWS 4-4
			به حداقل رساندن قابلیت ها، محتوا و گزینه ها	SCWS 5
تنظیم مقدار Option بر روي none	ندارد	دارد	محدود نمودن Optionها براي دایرکتوري ریشه OS	SCWS 5-1
تنظیم مقدار همه دستورهاي Option و بر روي none یا Multiviews	ندارد	دارد	محدود نمودن Optionها براي دایرکتوري ریشه وب	SCWS 5-2
تنظیمات همانند بند -1-SCR 5-2	ندارد	دارد	به حداقل رساندن Optionها براي دیگر دایرکتوری ها	SCWS 5-3
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	حذف نمودن محتواي پیش فرض HTML	SCWS 5-4
از دایرکتوري printenv حذف cgi-bin	ندارد	دارد	CGI Content حذف پیش فرض Printenv	SCWS 5-5
حذف test-cgi از دایرکتوري cgi-bin	ندارد	دارد	CGI Content test- حذف پیش فرض cgi	SCWS 5-6
مطابق نحوه پیاده سازی اجرا گردد.	بدون محدودیت	دارد	محدود نمودن متدهاي HTTP Request	SCWS 5-7
تنظیم TraceEnable با مقدار off در پیکربندي سطح سرور	ندارد	دارد	غیر فعال کردن متد HTTP TRACE	SCWS 5-8
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	محدود نمودن نسخه پروتکل HTTP	SCWS 5-9
مطابق نحوه پیاده سازی اجرا گردد.	غیرقابل دسترس	دارد	محدود نمودن دسترسی به فایل هاي. ht*	SCWS 5-10

مطابق نحوه پیاده سازی اجرا گردد.	بدون محدودیت	دارد	محدود نمودن پسوند فایل ها	SCWS 5-11
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	فیلترینگ درخواست ها بر اساس آدرس IP	SCWS 5-12
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	محدود نمودن دستور Listen	SCWS 5-13
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	محدود نمودن Optionهاي فریم مرورگر	SCWS 5-14
			عملیات ورود، نظارت و نگهداري	SCWS 6
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	پیکربندي لاگ خطا	SCWS 6-1
ErrorLog”syslog:local1″	ErrorLog”logs/error_log”	دارد	یکربندي Syslog Facility براي دریافت خطاها	SCWS 6-2
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	تنظیمات لاگ دسترسی	SCWS 6-3
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	بازبینی و فضاي لاگ	SCWS 6-4
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	اعمال وصله هاي قابل اجرا	SCWS 6-5
راه اندازي و فعالسازي ModSecurity	غیرفعال	دارد	راه اندازي و فعالسازي ModSecurity	SCWS 6-6
نصب و پیکربندي OWASP ModSecurity Core Rule Set	غیرفعال	دارد	راه اندازي و فعالسازي مجموعه قوانین اصلی OWASP ModSecurity	SCWS 6-7
			پیکربنديSSL/TSL	SCWS 7
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	نصب و راه اندازي mod_ssl و یا mod_nss	SCWS 7-1
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	نصب یک گواهی مورد اعتماد و معتبر	SCWS 7-2
مطابق نحوه پیاده سازی اجرا گردد.	ندارد	دارد	حفاظت از کلید خصوصی سرور	SCWS 7-3
مطابق نحوه پیاده سازی اجرا گردد.	SSLProtocol all –SSLv2	دارد	غیرفعال کردن پروتکل SSL V3.0	SCWS 7-4

مطابق نحوه پیاده سازی اجرا گردد.	مطابق بند 2 از توضیحات پیش فرض جدول	دارد	محدود کردن رمزهاي ضعیف SSL	SCWS 7-5
تنظیم SSLInsecurRenegotiation به off	SSLInsecureRenegotiation off	دارد	غیرفعال نمودن SSL ناامن Renegotiation	SCWS 7-6
به SSLCompression تنظیم off	در SSLCompression مقدار نسخه 2. 2. 24 تا 2. 2. 25، on و براي نسخه 2. 2. 26، off	دارد	اطمینان از فعال نبودن فشرده سازي SSL	SCWS 7-7
به SSLProtocol تنظیم TSLv1. 1 یا TLSv1. 2	SSLProtocol all -SSLv2	دارد	غیر فعال کردن پروتکل TSLv1. 0	SCWS 7-8
یه SSLUseStapling تنظیم on	SSLUseStapling Off SSLStaplingCache no default value	دارد	OCSP فعال کردن Stapling	SCWS 7-9
پیکربندي دستور Header همانند نمونه ذکر شده در قسمت نحوه پیاده سازی	غیرفعال	دارد	HTTP Strict فعال کردن Transport Security	SCWS 7-10
			نشت اطلاعات	SCWS 8
Full	ندارد	دارد	به ServerToken تنظیم ’Prod‘	SCWS 8-1
off	ندارد	دارد	تنظیم امضاء سرور بر روي Off	SCWS 8-2
عدم دسترسی به آیکون هاي آپاچی	ندارد	دارد	نشت اطلاعات از طریق محتواي پیش فرض Apache	SCWS 8-3
			انکار سرویس Mitigation	SCWS 9
10 یا کمتر	ندارد	دارد	تنظیم Timeout به 10 یا کمتر	SCWS 9-1
به KeepAliveتنظیم دستور on	ندارد	دارد	تنظیم دستور KeepAlive به on	SCWS 9-2
100 یا بیشتر	ندارد	دارد	تنظیم MaxKeepAliveRequest به 100 یا بیشتر	SCWS 9-3
15 و یا کمتر	ندارد	دارد	تنظیم به KeepAliveTimeout 15 یا کمتر	SCWS 9-4
40 ثانیه	header=20-40 MinRate=500	دارد	تنظیم محدودیت Timeout براي درخواست Headers	SCWS 9-5

20 ثانیه	body=20 MinRate=500	دارد	تنظیم محدودیت Timeout براي درخواست Body	SCWS 9-6
			محدودیت هاي درخواست	SCWS 10
512 و کمتر	ندارد	دارد	تنظیم دستور به LimitRequestLine 512 یا کمتر	SCWS 10-1
100 و کمتر	ندارد	دارد	تنظیم دستور به LimitRequestFields 100 یا کمتر	SCWS 10-2
1024 و کمتر	ندارد	دارد	تنظیم دستور LimitRequestFieldsize به 1024 یا کمتر	SCWS 10-3
102400 و کمتر	ندارد	دارد	تنظیم دستور به LimitRequestBody 102400 یا کمتر	SCWS 10-4
			فعال نمودن SELinux به منظور محدود نمودن فرآیندهاي Apache	SCWS 11
Enforcing	غیرفعال SELinux	دارد	فعال نمودن SELinux در Enforcing حالت	SCWS 11-1
مطابق نحوه پیاده سازی اجرا گردد.	غیرفعال SELinux	دارد	اجراي فرآیندهاي آپاچی در متن محدود شده httpd_t	SCWS 11-2
غیر فعال نمودن از حالت Permissive	عدم وجود در حالت غیرمجاز	دارد	اطمینان از عدم قرارگیري مد Permissive بر روي http_t	SCWS 11-3
فعال بودن بولین هاي ضروري SELinux	غیرفعال SELinux	دارد	اطمینان از فعال بودن بولین هاي ضروري SELinux	SCWS 11-4
			فعال نمودن AppArmor به منظور محدود نمودن فرآیندهاي Apache	SCWS 12
فعال	فعال AppArmor	دارد	AppArmor فعال نمودن Framework	SCWS 12-1
تغییر پروفایل پیش فرض به حداقل امتیازات	پروفایل آپاچی به صورت پیش فرض غیرسخت گیرانه می باشد.	دارد	سفارشی نمودن مشخصات AppArmor آپاچی	SCWS 12-2
enforce	enforce	دارد	اطمینان از قرارگیري پروفایل در حالت AppArmor Enforce	SCWS 12-3

توضیحات مقادیر پیش فرض جدول:

2-4-1-SCWS: تنظیمات مسیر ریشه وب به صورت زیر نمایش داده شده است:

…

Require all granted

…

</Directory>

5-7-1-SCWS: مقادیر پیش فرض به صورت زیر نمایش داده شده است:

SSLCipherSuite default depends on OpenSSL version.

SSLHonorCipherOrder Off

برای دیدن فلیم های سینماییِ مهیج و جذاب”در حوزه امنیت اطلاعات، اوسینت و هوش مصنوعی“، بر روی اینجا کلیک کنید.

آدرس کانال تلگرام سایت بیگ دیتا:

t.me/bigdata_channel

آدرس کانال سروش ما:
https://sapp.ir/bigdata_channel

جهت دیدن سرفصل های دوره های آموزشی بر روی اینجا کلیک کنید.

جهت ثبت نام در دوره های آموزشی بر روی اینجا کلیک کنید.

منابع و مراجع

[1] https://geekflare.com/apache-web-server-hardening-security/

[2] https://www.tecmint.com/apache-security-tips/

[3] https://geekflare.com/10-best-practices-to-secure-and-harden-your-apache-web-server/

[4] https://httpd.apache.org/docs/2.4/misc/security_tips.html

[5] https://www.slashroot.in/how-to-secure-apache-web-server

مرکز مدیریت راهبردی آفتا Apache Http Server [6]

ادامه مطلب را از فایل روبرو دانلود کنید. امنیت آپاچی سرور

بازدیدها: 1382

خانه بیگ دیتا تحلیل شبکه های اجتماعی، متن کاوی، داده کاوی، اوسینت و داده های حجیم

امنیت آپاچی سرور

تنظیمات

1-SCWS: برنامه ریزي و راه اندازي

2-SCWS: به حداقل رساندن ماژول هاي Apache

3-SCWS: اصول، مجوزها و مالکیت

3-1-SCWS: اجراي وب سرور Apache با کاربري غیر root

4-SCWS: کنترل دسترسی آپاچی

5-SCWS: به حداقل رساندن قابلیت ها، محتوا و گزینه ها

6-SCWS: عملیات ورود، نظارت و نگهداري

8-SCWS: نشت اطلاعات

11-SCWS: فعال نمودن SELinux به منظور محدود نمودن فرآیندهاي Apache

12-SCWS: فعال نمودن AppArmor به منظور محدود نمودن فرآیندهاي Apache

پیوست

جدول ممیزي

نوشته های مرتبط

همچنین ببینید

پايگاه داده کاساندرا، روش نصب و بررسی نقاط ضعف و قوت

خصوصیات بیگ دیتا یا کلان داده چیست؟ و جایگاه هدوپ کجاست

دیدگاهتان را بنویسید