xphost
October 17th, 2014, 21:32
بحث اصلی ما سر سکیور کردن وردپرس هست و نه سیستم مدیریت محتوای دیگری . البته قطعا میشود از مطالب این پست ها بصورت غیرمستقیم در سکیور کردن سایر سیستم های مدیریت محتوا استفاده کرد که کار بسیار پیچیده ای نیست ! کافیست این مطالب را بصورت عمیق و مفهومی درک کنید . باقی کار بصورت انتزاعی انجام خواهد شد به دست خود شما .
مباحث این پست مقادیری ممکن هست پیچیده شود . این موضوع دست من نیست . احساس کردم دوستان نیاز به مطالب بیشتر و پایه ای تر دارند که سعی میکنم این پست را هرچه پایه ای تر ، هرچه علمی تر و هرچه کاملتر بنویسم !
مجددا باز میگردم روی قلب اصلی وردپرس . فایل wp-config ؛ اصولا درک مناسبی از این فایل در وبلاگ نویسان عزیزمان وجود ندارد . صرفا وارد کردن سریع اطلاعات دیتابیس و راه اندازی وردپرس را پیش میگیرند که کار غلطی هم نیست ! کمتر کسی به این فایل و محتویاتش توجه میکند . اگر حس میکنید شما بطور کامل توجه میکنید ، باز هم در اشتباهید !
خواندن خط به خط این فایل هم سودی برای شما ندارد . حتی فایل را حفظ باشید و از حفظ هم بنویسید هیچ فایده و نفعی ندارد ! چیزی که نفع دارد درک درست متغیر های تعریف شده در این فایل و عملیات های مربوط به آنهاست .
از طریق این فایل خیلی کارها میتوان کرد . میتوان یک سایت وردپرس راه اندازی کرد و یا یک سایت وردپرسی را به فنا داد !
من سعی کردم در پست قبلی مواردی را برای تغییر در این فایل اشاره کنم که متاسفانه باید اعتراف کنم که اصلا کامل نبود ! احساس نمیکردم نیازی باشد این فایل را به تفصیل شرح دهم . الان هم همچین حسی ندارم و هیچوقت این فایل را به تفصیل شرح نمیدهم ! کار مفیدی نیست بازدهی هم ندارد .
من فقط و فقط متغیر های ضروری و نحوه مقدار دهی آنها را برای شما بررسی میکنم و توضیح میدهم .
من این فایل را به چند بخش تقسیم میکنم . مطابق تقسیم بندی خود مستندات وردپرس (+ (http://codex.wordpress.org/Editing_wp-config.php)) :
قسمت اول ، پر کردن اطلاعات مربوط به دیتابیس هست . بار ها و بارها این بخش را پر کردید . از بر هستید ! همه اینها صحیح . ولی تابحال بصورت دقیق این متغیر ها را مورد بررسی قرار ندادید !
خب ! اولین متغیر DB_NAME هست که باید مقدار نام دیتابیس که عموما ترکیبی از نام کاربری شما در هاستینگ + نام دیتابیسی که ساخته اید باید باشد !
نام دیتابیس خود را غیرقابل حدس انتخاب کنید ، این موضوع ربطی به بلندی نام دیتابیس ندارد ! غیرقابل حدس بودن نام چیز مشخصیست . زیاد سخت نگیرید . قرار نیست این اطلاعات را شما حفظ کنید . مثلا نام دیتابیس oujd نام مناسبی هست . یک عبارت بی معنی و بی مفهوم ! ربطی به سایت ، وبلاگ یا وردپرس ندارد . قابل حدس نیست . خود این حرکت امنیت را تا حدی افزایش میدهد !
دومین متغیر DB_USER میباشد که عینا موارد مربوط به نام دیتابیس را باید برای آن رعایت کنید . اما توجه داشته باشید که این user قرار نیست همه کاری انجام دهد . احیانا اگر هکری به این یوزر با کلمه عبورش دسترسی پیدا کند عین این است که به کل دیتابیس دسترسی پیدا کرده . پس از طریق بخش privileges ، مدیریت دیتابیس خود ، دسترسی های لازم به جداول و در کل به مقدار لازم را به یوزر بدهید ! نه بیشتر نه کمتر .
اصولا دیتابیس میسازند و یوزر را در آن ادد میکنند . موقع انتخاب اکسس ها هم روی Select All کلیک میکنند . آخر هم دنبال بلاگیدن شاد میگردند http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif . کمی غیرمعقول است . موضوع privileges بحث سبکی نیست که اینجا با چند خط مطرح کنم . اما چیز مشخصیست . برای کنترل پنل های مختلف ، مدیریت داده های مختلف این موضوع مختلف است و چیز ثابتی نیست که یک آموزش برای تمامی سیستم ها ارائه شود ! این موضوع را به خودتان واگذار میکنم تا با کند و کاو در سیستم مدیریت پایگاه داده هاستینگتان هم کمی خطر کنید ، هم کمی بترسید و هم چیزی یاد بگیرید http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif
پارامتر بعدی DB_PASSWORD هست . روی این پارامتر ۹۸% دوستان مشکل دارند . فکر میکنند باید پسوردی انتخاب شود که بتوان آنرا بخاطر سپرد ! اصلا اینطور نیست . شما نیازی به این پسورد ندارید ، به هیچ وجه . این پسورد برای وردپرس استفاده میشود . قرار است برای هر بار استفاده وردپرس از این پسورد استفاده کند . قرار نیست شما این را وارد کنید . پس هنگام ساخت یوزر ، به پسورد های رندومی که سیستم برایتان جنریت میکند اکتفا کنید ! نیازی نیست با دست خودتان چیزی تایپ کنید . روی Generate Password کلیک کنید و یک پسورد اتفاقی برگزینید . اگر به این وضعیت هم اطمینان ندارید میتوانید یک برنامه بنویسید که یک رشته با طول دلخواهتان از کاراکتر های دلخواه بصورت رندم بسازد . اینطوری اعتمادتان جلب خواهد شد فکر میکنم !
انتخاب پسورد نامناسب میتواند خطرناک باشد . مثلا پسورد هایی مثل ۱۲۳۴۵۶ که الحمدلله رواج فراوانی دارد میان وبلاگ نویسان وردپرسی !
بگذارید کمی بترسانمتان ! نیاز هست که بترسید تا موضوع را جدی بگیرید .
فرض کنید یکبار پلاگینی چیزی نصب کنید ، یا در برنامه نویسی قالبتان جایی به مشکل بخورید . یا چیز های دیگر که باعث میشود ارور PHP از وردپرس بگیرید ! خب ، اگر ارور از این ارور های معمول باشد که username هاست شما به سادگی لو میرود ! اگر ارور دیتابیس باشد ، یوزر دیتابیس هم لو میرود . با استفاده از پسورد ساده شما میتوان به وردپرس لاگین کرد . به سادگی یکی از پرونده ها را به کد مخربی آلوده کرد و … .
اگر کد مخرب هم وارد سایت نکنند ، میتواند از زندگی شما بک آپ بگیرند ! پسورد وردپرس شما را ب***ند و آنرا با GPU دیکد کنند . احتمالا از آن دسته افرادی هستید که پسورد هایتان همه یکی هست ! http://www.itarashe.net/wp-includes/images/smilies/icon_neutral.gif .
خب ، تبریک میگم . به فنا رفتید .
کمی جلوتر برویم ، از سایت شما Symlink به سایت سایر های روی آن هاستینگ و سرور . بقیه سایت ها هم به فنا میروند . . . مسئول همه این چیزها شما هستید . http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif .
ممکن هم هست هکر کلاه سیاه باشد و قاطی کند ، تمام زحمات چند مدتیه شما را با یک کلیک به باد دهد . کار سختی نیست .
به متغیر DB_HOST میپردازیم .
این متغیر میزبان دیتابیس شما را مشخص میکند . اگر هاستینگ شما از MySQL پشتیبانی میکند روی خود هاستینگ ، کافیست این بخش را با عبارت ۱۲۷٫۰٫۰٫۱ یا localhost پر کنید که نشان دهنده این هست که دیتابیس شما روی همین سرور قرار دارد .
نظر شخصی بنده را میخواهید از آی پی استفاده کنید . وقتی از دومین استفاده میکنید ، تعداد درخواست ها و هیت های بالا به سایت شما باعث میشود این ریسالو و حل شدن دامنه localhost به آی پی ، باز هم آن مقدار میلی ثانیه یا میکرو ثانیه ای که طول میکشد را طولانی تر کند و سایت شما روال کند تری پیدا کند .
البته ، پیشنهادم این هست که کلا از سرور دیتابیس جدا استفاده کنید با اکسس محدود شده بر اساس پورت و آی پی !
یعنی ، میزبان فایل شما جایی باشد ، میزبان دیتابیس شما جای دیگر . این دو با هم در ارتباط خواهند بود ولی زمانی این موضوع فایده پیدا میکند که ارسال درخواست ها از سرور فایل به سرور دیتابیس روی آی پی محدود شده باشد . یعنی هر کسی از خارج نتواند حتی با داشتن یوزر دیتابیس به سرور دیتابیس نفوذ کند !
البته این هم راه حلی دارد ! اگر دسترسی به سایت شما وجود داشته باشد ، آپلود یک اسکریپت PHP کار سختی نیست که از سوی سرور فایل شما به سرور دیتابیس درخواست هایی ارسال شود و کوئری هایی اجرا شود !!!
اما خب ، اگر دسترسی به دیتابیس وجود نداشته باشد و هکر نتوانسته باشد کد مخربی تزریق کند قطعا این موضوع هم اتفاق نمی افتد .
البته بحث را میتوان پیچیده تر هم کرد . مثلا درخواست ها موقع ارسال در سرور دیتابیس توسط یک سری اسکریپت ها و روبات های خاص چک شوند و از ارسال درخواست های اینولید جلوگیری شود .
تعویض پورت SQL میتواند تا حد زیادی کمک کند در این موضوع . البته این پورت نباید لو برود . اگر لو برود فایده ای عملا نداشته تعویض پورت .
ار بحث DB_HOST که بگذریم ، ۲ پارامتر مهم باقی مانده که به مبحث اینکودینگ و یونی کد مربوط میشود . بحث امنیتی نیست . تنظیم ناصحیح این دو پارامتر باعث خرابی در نمایش سایت شما میشود و هیچ ربطی به ما ندارد . بحث ما امنیتیست و نه ظاهری ! برای ویرایش صحیح این دو پارامتر از مستندات وردپرس استفاده کنید برای راهنمایی بیشتر ….
قسمت اول اعمال تغییرات در wp-config.php به اتمام رسید .
بخش دوم مربوط به متغیر های یونیکی هست که برای مخلوط شدن با کوکی های جلساتی هست که کاربران با سایت یا وبلاگ وردپرسی شما استفاده میکنند .
طبیعتا باید این مقادیر با توجه به اسمش ، یونیک باشند !
اگر این مقادیر را بصورت پیشفرض رها کنید ، خب مشخص هست که کوکی های شما با توجه به متغیر های پیشفرض ، به راحتی قابل اسنیف خواهد بود و شما را به دردسر خواهند انداخت .
کافیست کوکی های یک جلسه برای ادمین سایت وردپرسی لو برود و هکر از آنها استفاده کنید تا ادمین سایت شود ! پس جدی بگیرید …
۹ متغیر وجود دارد که باید بصورت دقیق و پیچیده پر شوند ! من در پست قبلی توضیحاتی در مورد پیچیده بودن این متغیر ها دادم که کافی نبود !
مجددا مطرح میکنم و به توضیح و تفصیل می پردازم !
خب ، اولین موضوع این هست که هیچ محدودیتی در انتخاب رشته وجود ندارد . هر نوع کاراکتری قابل استفاده است ! طول رشته هم اهمیت چندانی ندارد . مهم پیچیده بودن هست . مثلا مقدار !@#EEDF@#$R$#gfrkfjip34rfR$F#$Fdsfsd-94350345-43cdsf#@$!#3244sdsa^(&*)*&&dsad مقدار بدی نیست ! .
اما بهتر هست از یکی از قابلیت های api خود وردپرس استفاده کنیم تا برای ۹ متغیر ، رشته های رندوم و با امنیت بالا پیدا کنیم .
از این لینک استفاده کنید : https://api.wordpress.org/secret-key/1.1/salt
با بازکردن این لینک ، متوجه موضوع میشوید ! بله ، بصورت رندوم وردپرس تمامی مقادیر را برای شما پر کرده و آماده عملیات مهیج Copy & Paste هست ! http://www.itarashe.net/wp-includes/images/smilies/icon_neutral.gif
توجه کنید که این مقادیر بر اساس اصولی که در مستندات سیستم salt وردپرس هست ساخته میشوند و مقادیر بیخود و بی جهتی نیستند ! بهتر است از همین مقادیر استفاده کنید تا اینکه خودتان چیزی تایپ کنید . راحت تر هم هستید http://www.itarashe.net/wp-includes/images/smilies/icon_wink.gif
بعد از موضوع متغیر های salt به پیشوند جداول می پردازیم !
خب ، اگر با حملات تزریق کد های SQL آشنایی داشته باشید ، میدانید که دانستن پیشوند جداول در تزریق کد بسیار اهمیت دارد ! پیشوند معمول و پیشفرض جداول وردپرس wp_ هست . اکثر کاربران این پیشوند را دست نمیزنند و بصورت پیشفرض رها میکنند .
در مورد این پیشوند ۲ حالت برای شما وجود دارد . یکی اینکه سایت یا وبلاگ وردپرسی خود را راه اندازی کرده اید و کار تمام شده و دیگری این است که هنوز وبلاگ یا سایت خود را راه اندازی نکردید !
اگر جزو گروه دوم هستید ، کارتان ساده تر است . بدین صورت که این مقدار را با مقدار دلخواه اما کوتاه ، مثلا نهایتا ۶کاراکتری جایگزین کنید . توجه کنید که کاراکتر آندرلاین را در انتهای مقدار حتما درج کنید .
مثلا بجای wp_ مقدار _jfhoe مقدار مناسبیست !
با راه اندازی وردپرس ، پیشوند جداول وردپرس شما چیزی خواهد بود که تنظیم کردید …
اگر وردپرستان راه اندازی شده ، کارتان کمی بیشتر است . باید دیتابیس وردپرس خود را Dump کنید یا Export کنید . بصورتی که یک فایل .sql از دیتابیستان در اختیار داشته باشید !
حال فایل را با یک ادیتور مناسب و ترجیها پیشرفته باز کنید . با استفاده از قابلیت Replace رشته ها ، مقدار wp_ را با مقدار دلخواه x_ خود جایگزین کنید . فایل را ذخیره کنید و در دیتابیس خود ایمپورت کنید ! توجه کنید که محتوای قبلی را پاک کنید … (جداول قدیمی و بعضا به درد نخور http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif )
خب . از موضوع پیشوند جداول که بگذریم ، به متغیر زبان وردپرس میرسیم که نیازی نمیبینم توضیح دهم . یعنی متغیر WPLANG مشخصا زبان وردپرس شما را مشخص میکند . ربطی به امنیت ندارد .
متغیر بعدی WP_DEBUG هست که بسیار اهمیت دارد !
این متغیر میتواند با نمایش پیغام خطاهای بوجود آمده در وردپرس شما ، تا حدی امنیت سایت و وبلاگ وردپرسی شما را به خطر بیاندازد ! حداقل اگر رعایت موارد بالا را نکرده باشید …
اگر توسعه دهنده ، طراح یا برنامه نویس برای وردپرس هستید ، خب مشخصا باید این متغیر را که از نوع Boolean هست برابر true بگذارید . با فعال کردن این متغیر تمامی ارور هایی که در هسته وردپرس و کلا در روند کاری وردپرس بوقوع میپوندد را به شما نمایش میدهد . البته ممکن هست این ارور ها در صفحاتی که نباید هم نشان داده شوند و این موضوع میتواند اطلاعات نسبتا مهمی از وبلاگ یا وبسایت شما را در اختیار هکر گرامی قرار دهد .
اگر سرتان توی لاک خودتان هست بهتر است این متغیر را برابر false قرار دهید .
۲ متغیر باقی میماند که ممکن هست مهم باشند !
متغیر اول ، مسیر شاخه ای که فایل های وردپرس در آن قرار دارند را مشخص میکند و متغیر دوم مسیر فایل setting وردپرس .
این دو مسیر دلخواه اند ، اگر در امنیت میخواهید وسواس به خرج دهید ، بجز متغیر اول ، باید متغیر دوم را تغییر مسیر دهید و در انتها در فایل wp-setting.php مستیر های یاد شده را نیز تصحیح کنید !
خب . الان باز هم زمان بلاگیدن شاد نرسیده !
شما تازه wp-config.php را بصورت کامل کانفیگ کردید ؛ کار مهمی نکردید . هسته اتم نشکافتید ! فقط یک فایل را بصورت استاندارد ادیت کردید .
نوبت به پاسداری از wp-config میرسد . اول از همه ، این فایل را یک پوشه به عقب ببرید ، در پست قبلی هم توضیحاتی دادم که نسبتا کامل بود .
کافیست مسیر /home/uname/public_html/wp-config.php را به مسیر /home/uname/wp-config.php تغییر دهید . (ممکن است مسیر شما بدین صورت نباشد ، مهم نیست . من فقط میخواستم مفهوم یک پوشه به عقب را جا بیاندازم که موفق شدم)
نوبت به تعیین سطح دسترسی فایل wp-config میرسد . به ترتیب این دسترسی ها را تست کنید ، هرکدام جواب نداد بعدی را تست کنید و زمانی که جواب گرفتید تست را متوقف سازید !
۴۰۰
۵۰۰
۶۰۰
۶۴۰
۶۴۴
اکثر وبلاگ ها روی ۴۰۰ مشکلشان حل میشود . این دسترسی فقط خواندن را به خود یوزر میدهد ! بهترین دسترسی برای فایل wp-config همین دسترسی است ! اگر هاستینگان با این دسترسی مشکل داشت یا وردپرس با این دسترسی به فنا رفت مقادیر دیگر را تست کنید .
اصولا مبحث پرمیژن یا CHMOD چیزی نیست که با این توضیحاتی که ارائه دادم بصورت کامل برای شما مشخص و مفهوم گردد . مبحث گسترده ایست . اما من آخر کار را بیان میکنم تا پست به حاشیه کشیده نشود …
بنظرم بد نیست که این فایل را با متدهای متنوعی که الحمدلله هر کودکی امروز در اینترنت بلد هست انکریپت کنید . از هیچی بهتر است !
مثلا ioncube ، zend یا حتی توابع رشته ای خود پی اچ پی مثل base64 ، gzinflate یا str_rot13 یا هرچیز دیگری …
استفاده از این رمزنگاری ها بسیار خوب هست ، مخصوصا اگر مثلا از zend آخرین ورژن بصورت اورجینال بهره ببرید . یا مثلا ioncube بصورت اورجینال و پرمیوم !
خب . بحث و کار ما در مورد wp-config.php به پایان میرسد .اطمینان داریم که قلب وردپرسمان مستحکم تر و امن تر شد !
پست هم مقداری طولانی شد ، حوصله خودم هم سر رفت ! باقی آموزش و مسائل امنیتی را در پست دیگری احتمالا با نام وردپرس ضد گلوله ! قسمت ۳ منتشر خواهم کرد که در آن پست بیشتر به بررسی پلاگین های امنیتی و قالب ها ، سرورهاستینگ ، سطح دسترسی دایکتوری ها و فایلها و … خواهیم پرداخت …
امیدوارم وردپرس امن ، سالم و وبلاگیدن شادی داشته باشید …
پ . ن :
» امنیت هیچگاه ۱۰۰% نیست …
منبع:.itarashe.net
مباحث این پست مقادیری ممکن هست پیچیده شود . این موضوع دست من نیست . احساس کردم دوستان نیاز به مطالب بیشتر و پایه ای تر دارند که سعی میکنم این پست را هرچه پایه ای تر ، هرچه علمی تر و هرچه کاملتر بنویسم !
مجددا باز میگردم روی قلب اصلی وردپرس . فایل wp-config ؛ اصولا درک مناسبی از این فایل در وبلاگ نویسان عزیزمان وجود ندارد . صرفا وارد کردن سریع اطلاعات دیتابیس و راه اندازی وردپرس را پیش میگیرند که کار غلطی هم نیست ! کمتر کسی به این فایل و محتویاتش توجه میکند . اگر حس میکنید شما بطور کامل توجه میکنید ، باز هم در اشتباهید !
خواندن خط به خط این فایل هم سودی برای شما ندارد . حتی فایل را حفظ باشید و از حفظ هم بنویسید هیچ فایده و نفعی ندارد ! چیزی که نفع دارد درک درست متغیر های تعریف شده در این فایل و عملیات های مربوط به آنهاست .
از طریق این فایل خیلی کارها میتوان کرد . میتوان یک سایت وردپرس راه اندازی کرد و یا یک سایت وردپرسی را به فنا داد !
من سعی کردم در پست قبلی مواردی را برای تغییر در این فایل اشاره کنم که متاسفانه باید اعتراف کنم که اصلا کامل نبود ! احساس نمیکردم نیازی باشد این فایل را به تفصیل شرح دهم . الان هم همچین حسی ندارم و هیچوقت این فایل را به تفصیل شرح نمیدهم ! کار مفیدی نیست بازدهی هم ندارد .
من فقط و فقط متغیر های ضروری و نحوه مقدار دهی آنها را برای شما بررسی میکنم و توضیح میدهم .
من این فایل را به چند بخش تقسیم میکنم . مطابق تقسیم بندی خود مستندات وردپرس (+ (http://codex.wordpress.org/Editing_wp-config.php)) :
قسمت اول ، پر کردن اطلاعات مربوط به دیتابیس هست . بار ها و بارها این بخش را پر کردید . از بر هستید ! همه اینها صحیح . ولی تابحال بصورت دقیق این متغیر ها را مورد بررسی قرار ندادید !
خب ! اولین متغیر DB_NAME هست که باید مقدار نام دیتابیس که عموما ترکیبی از نام کاربری شما در هاستینگ + نام دیتابیسی که ساخته اید باید باشد !
نام دیتابیس خود را غیرقابل حدس انتخاب کنید ، این موضوع ربطی به بلندی نام دیتابیس ندارد ! غیرقابل حدس بودن نام چیز مشخصیست . زیاد سخت نگیرید . قرار نیست این اطلاعات را شما حفظ کنید . مثلا نام دیتابیس oujd نام مناسبی هست . یک عبارت بی معنی و بی مفهوم ! ربطی به سایت ، وبلاگ یا وردپرس ندارد . قابل حدس نیست . خود این حرکت امنیت را تا حدی افزایش میدهد !
دومین متغیر DB_USER میباشد که عینا موارد مربوط به نام دیتابیس را باید برای آن رعایت کنید . اما توجه داشته باشید که این user قرار نیست همه کاری انجام دهد . احیانا اگر هکری به این یوزر با کلمه عبورش دسترسی پیدا کند عین این است که به کل دیتابیس دسترسی پیدا کرده . پس از طریق بخش privileges ، مدیریت دیتابیس خود ، دسترسی های لازم به جداول و در کل به مقدار لازم را به یوزر بدهید ! نه بیشتر نه کمتر .
اصولا دیتابیس میسازند و یوزر را در آن ادد میکنند . موقع انتخاب اکسس ها هم روی Select All کلیک میکنند . آخر هم دنبال بلاگیدن شاد میگردند http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif . کمی غیرمعقول است . موضوع privileges بحث سبکی نیست که اینجا با چند خط مطرح کنم . اما چیز مشخصیست . برای کنترل پنل های مختلف ، مدیریت داده های مختلف این موضوع مختلف است و چیز ثابتی نیست که یک آموزش برای تمامی سیستم ها ارائه شود ! این موضوع را به خودتان واگذار میکنم تا با کند و کاو در سیستم مدیریت پایگاه داده هاستینگتان هم کمی خطر کنید ، هم کمی بترسید و هم چیزی یاد بگیرید http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif
پارامتر بعدی DB_PASSWORD هست . روی این پارامتر ۹۸% دوستان مشکل دارند . فکر میکنند باید پسوردی انتخاب شود که بتوان آنرا بخاطر سپرد ! اصلا اینطور نیست . شما نیازی به این پسورد ندارید ، به هیچ وجه . این پسورد برای وردپرس استفاده میشود . قرار است برای هر بار استفاده وردپرس از این پسورد استفاده کند . قرار نیست شما این را وارد کنید . پس هنگام ساخت یوزر ، به پسورد های رندومی که سیستم برایتان جنریت میکند اکتفا کنید ! نیازی نیست با دست خودتان چیزی تایپ کنید . روی Generate Password کلیک کنید و یک پسورد اتفاقی برگزینید . اگر به این وضعیت هم اطمینان ندارید میتوانید یک برنامه بنویسید که یک رشته با طول دلخواهتان از کاراکتر های دلخواه بصورت رندم بسازد . اینطوری اعتمادتان جلب خواهد شد فکر میکنم !
انتخاب پسورد نامناسب میتواند خطرناک باشد . مثلا پسورد هایی مثل ۱۲۳۴۵۶ که الحمدلله رواج فراوانی دارد میان وبلاگ نویسان وردپرسی !
بگذارید کمی بترسانمتان ! نیاز هست که بترسید تا موضوع را جدی بگیرید .
فرض کنید یکبار پلاگینی چیزی نصب کنید ، یا در برنامه نویسی قالبتان جایی به مشکل بخورید . یا چیز های دیگر که باعث میشود ارور PHP از وردپرس بگیرید ! خب ، اگر ارور از این ارور های معمول باشد که username هاست شما به سادگی لو میرود ! اگر ارور دیتابیس باشد ، یوزر دیتابیس هم لو میرود . با استفاده از پسورد ساده شما میتوان به وردپرس لاگین کرد . به سادگی یکی از پرونده ها را به کد مخربی آلوده کرد و … .
اگر کد مخرب هم وارد سایت نکنند ، میتواند از زندگی شما بک آپ بگیرند ! پسورد وردپرس شما را ب***ند و آنرا با GPU دیکد کنند . احتمالا از آن دسته افرادی هستید که پسورد هایتان همه یکی هست ! http://www.itarashe.net/wp-includes/images/smilies/icon_neutral.gif .
خب ، تبریک میگم . به فنا رفتید .
کمی جلوتر برویم ، از سایت شما Symlink به سایت سایر های روی آن هاستینگ و سرور . بقیه سایت ها هم به فنا میروند . . . مسئول همه این چیزها شما هستید . http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif .
ممکن هم هست هکر کلاه سیاه باشد و قاطی کند ، تمام زحمات چند مدتیه شما را با یک کلیک به باد دهد . کار سختی نیست .
به متغیر DB_HOST میپردازیم .
این متغیر میزبان دیتابیس شما را مشخص میکند . اگر هاستینگ شما از MySQL پشتیبانی میکند روی خود هاستینگ ، کافیست این بخش را با عبارت ۱۲۷٫۰٫۰٫۱ یا localhost پر کنید که نشان دهنده این هست که دیتابیس شما روی همین سرور قرار دارد .
نظر شخصی بنده را میخواهید از آی پی استفاده کنید . وقتی از دومین استفاده میکنید ، تعداد درخواست ها و هیت های بالا به سایت شما باعث میشود این ریسالو و حل شدن دامنه localhost به آی پی ، باز هم آن مقدار میلی ثانیه یا میکرو ثانیه ای که طول میکشد را طولانی تر کند و سایت شما روال کند تری پیدا کند .
البته ، پیشنهادم این هست که کلا از سرور دیتابیس جدا استفاده کنید با اکسس محدود شده بر اساس پورت و آی پی !
یعنی ، میزبان فایل شما جایی باشد ، میزبان دیتابیس شما جای دیگر . این دو با هم در ارتباط خواهند بود ولی زمانی این موضوع فایده پیدا میکند که ارسال درخواست ها از سرور فایل به سرور دیتابیس روی آی پی محدود شده باشد . یعنی هر کسی از خارج نتواند حتی با داشتن یوزر دیتابیس به سرور دیتابیس نفوذ کند !
البته این هم راه حلی دارد ! اگر دسترسی به سایت شما وجود داشته باشد ، آپلود یک اسکریپت PHP کار سختی نیست که از سوی سرور فایل شما به سرور دیتابیس درخواست هایی ارسال شود و کوئری هایی اجرا شود !!!
اما خب ، اگر دسترسی به دیتابیس وجود نداشته باشد و هکر نتوانسته باشد کد مخربی تزریق کند قطعا این موضوع هم اتفاق نمی افتد .
البته بحث را میتوان پیچیده تر هم کرد . مثلا درخواست ها موقع ارسال در سرور دیتابیس توسط یک سری اسکریپت ها و روبات های خاص چک شوند و از ارسال درخواست های اینولید جلوگیری شود .
تعویض پورت SQL میتواند تا حد زیادی کمک کند در این موضوع . البته این پورت نباید لو برود . اگر لو برود فایده ای عملا نداشته تعویض پورت .
ار بحث DB_HOST که بگذریم ، ۲ پارامتر مهم باقی مانده که به مبحث اینکودینگ و یونی کد مربوط میشود . بحث امنیتی نیست . تنظیم ناصحیح این دو پارامتر باعث خرابی در نمایش سایت شما میشود و هیچ ربطی به ما ندارد . بحث ما امنیتیست و نه ظاهری ! برای ویرایش صحیح این دو پارامتر از مستندات وردپرس استفاده کنید برای راهنمایی بیشتر ….
قسمت اول اعمال تغییرات در wp-config.php به اتمام رسید .
بخش دوم مربوط به متغیر های یونیکی هست که برای مخلوط شدن با کوکی های جلساتی هست که کاربران با سایت یا وبلاگ وردپرسی شما استفاده میکنند .
طبیعتا باید این مقادیر با توجه به اسمش ، یونیک باشند !
اگر این مقادیر را بصورت پیشفرض رها کنید ، خب مشخص هست که کوکی های شما با توجه به متغیر های پیشفرض ، به راحتی قابل اسنیف خواهد بود و شما را به دردسر خواهند انداخت .
کافیست کوکی های یک جلسه برای ادمین سایت وردپرسی لو برود و هکر از آنها استفاده کنید تا ادمین سایت شود ! پس جدی بگیرید …
۹ متغیر وجود دارد که باید بصورت دقیق و پیچیده پر شوند ! من در پست قبلی توضیحاتی در مورد پیچیده بودن این متغیر ها دادم که کافی نبود !
مجددا مطرح میکنم و به توضیح و تفصیل می پردازم !
خب ، اولین موضوع این هست که هیچ محدودیتی در انتخاب رشته وجود ندارد . هر نوع کاراکتری قابل استفاده است ! طول رشته هم اهمیت چندانی ندارد . مهم پیچیده بودن هست . مثلا مقدار !@#EEDF@#$R$#gfrkfjip34rfR$F#$Fdsfsd-94350345-43cdsf#@$!#3244sdsa^(&*)*&&dsad مقدار بدی نیست ! .
اما بهتر هست از یکی از قابلیت های api خود وردپرس استفاده کنیم تا برای ۹ متغیر ، رشته های رندوم و با امنیت بالا پیدا کنیم .
از این لینک استفاده کنید : https://api.wordpress.org/secret-key/1.1/salt
با بازکردن این لینک ، متوجه موضوع میشوید ! بله ، بصورت رندوم وردپرس تمامی مقادیر را برای شما پر کرده و آماده عملیات مهیج Copy & Paste هست ! http://www.itarashe.net/wp-includes/images/smilies/icon_neutral.gif
توجه کنید که این مقادیر بر اساس اصولی که در مستندات سیستم salt وردپرس هست ساخته میشوند و مقادیر بیخود و بی جهتی نیستند ! بهتر است از همین مقادیر استفاده کنید تا اینکه خودتان چیزی تایپ کنید . راحت تر هم هستید http://www.itarashe.net/wp-includes/images/smilies/icon_wink.gif
بعد از موضوع متغیر های salt به پیشوند جداول می پردازیم !
خب ، اگر با حملات تزریق کد های SQL آشنایی داشته باشید ، میدانید که دانستن پیشوند جداول در تزریق کد بسیار اهمیت دارد ! پیشوند معمول و پیشفرض جداول وردپرس wp_ هست . اکثر کاربران این پیشوند را دست نمیزنند و بصورت پیشفرض رها میکنند .
در مورد این پیشوند ۲ حالت برای شما وجود دارد . یکی اینکه سایت یا وبلاگ وردپرسی خود را راه اندازی کرده اید و کار تمام شده و دیگری این است که هنوز وبلاگ یا سایت خود را راه اندازی نکردید !
اگر جزو گروه دوم هستید ، کارتان ساده تر است . بدین صورت که این مقدار را با مقدار دلخواه اما کوتاه ، مثلا نهایتا ۶کاراکتری جایگزین کنید . توجه کنید که کاراکتر آندرلاین را در انتهای مقدار حتما درج کنید .
مثلا بجای wp_ مقدار _jfhoe مقدار مناسبیست !
با راه اندازی وردپرس ، پیشوند جداول وردپرس شما چیزی خواهد بود که تنظیم کردید …
اگر وردپرستان راه اندازی شده ، کارتان کمی بیشتر است . باید دیتابیس وردپرس خود را Dump کنید یا Export کنید . بصورتی که یک فایل .sql از دیتابیستان در اختیار داشته باشید !
حال فایل را با یک ادیتور مناسب و ترجیها پیشرفته باز کنید . با استفاده از قابلیت Replace رشته ها ، مقدار wp_ را با مقدار دلخواه x_ خود جایگزین کنید . فایل را ذخیره کنید و در دیتابیس خود ایمپورت کنید ! توجه کنید که محتوای قبلی را پاک کنید … (جداول قدیمی و بعضا به درد نخور http://www.itarashe.net/wp-includes/images/smilies/icon_smile.gif )
خب . از موضوع پیشوند جداول که بگذریم ، به متغیر زبان وردپرس میرسیم که نیازی نمیبینم توضیح دهم . یعنی متغیر WPLANG مشخصا زبان وردپرس شما را مشخص میکند . ربطی به امنیت ندارد .
متغیر بعدی WP_DEBUG هست که بسیار اهمیت دارد !
این متغیر میتواند با نمایش پیغام خطاهای بوجود آمده در وردپرس شما ، تا حدی امنیت سایت و وبلاگ وردپرسی شما را به خطر بیاندازد ! حداقل اگر رعایت موارد بالا را نکرده باشید …
اگر توسعه دهنده ، طراح یا برنامه نویس برای وردپرس هستید ، خب مشخصا باید این متغیر را که از نوع Boolean هست برابر true بگذارید . با فعال کردن این متغیر تمامی ارور هایی که در هسته وردپرس و کلا در روند کاری وردپرس بوقوع میپوندد را به شما نمایش میدهد . البته ممکن هست این ارور ها در صفحاتی که نباید هم نشان داده شوند و این موضوع میتواند اطلاعات نسبتا مهمی از وبلاگ یا وبسایت شما را در اختیار هکر گرامی قرار دهد .
اگر سرتان توی لاک خودتان هست بهتر است این متغیر را برابر false قرار دهید .
۲ متغیر باقی میماند که ممکن هست مهم باشند !
متغیر اول ، مسیر شاخه ای که فایل های وردپرس در آن قرار دارند را مشخص میکند و متغیر دوم مسیر فایل setting وردپرس .
این دو مسیر دلخواه اند ، اگر در امنیت میخواهید وسواس به خرج دهید ، بجز متغیر اول ، باید متغیر دوم را تغییر مسیر دهید و در انتها در فایل wp-setting.php مستیر های یاد شده را نیز تصحیح کنید !
خب . الان باز هم زمان بلاگیدن شاد نرسیده !
شما تازه wp-config.php را بصورت کامل کانفیگ کردید ؛ کار مهمی نکردید . هسته اتم نشکافتید ! فقط یک فایل را بصورت استاندارد ادیت کردید .
نوبت به پاسداری از wp-config میرسد . اول از همه ، این فایل را یک پوشه به عقب ببرید ، در پست قبلی هم توضیحاتی دادم که نسبتا کامل بود .
کافیست مسیر /home/uname/public_html/wp-config.php را به مسیر /home/uname/wp-config.php تغییر دهید . (ممکن است مسیر شما بدین صورت نباشد ، مهم نیست . من فقط میخواستم مفهوم یک پوشه به عقب را جا بیاندازم که موفق شدم)
نوبت به تعیین سطح دسترسی فایل wp-config میرسد . به ترتیب این دسترسی ها را تست کنید ، هرکدام جواب نداد بعدی را تست کنید و زمانی که جواب گرفتید تست را متوقف سازید !
۴۰۰
۵۰۰
۶۰۰
۶۴۰
۶۴۴
اکثر وبلاگ ها روی ۴۰۰ مشکلشان حل میشود . این دسترسی فقط خواندن را به خود یوزر میدهد ! بهترین دسترسی برای فایل wp-config همین دسترسی است ! اگر هاستینگان با این دسترسی مشکل داشت یا وردپرس با این دسترسی به فنا رفت مقادیر دیگر را تست کنید .
اصولا مبحث پرمیژن یا CHMOD چیزی نیست که با این توضیحاتی که ارائه دادم بصورت کامل برای شما مشخص و مفهوم گردد . مبحث گسترده ایست . اما من آخر کار را بیان میکنم تا پست به حاشیه کشیده نشود …
بنظرم بد نیست که این فایل را با متدهای متنوعی که الحمدلله هر کودکی امروز در اینترنت بلد هست انکریپت کنید . از هیچی بهتر است !
مثلا ioncube ، zend یا حتی توابع رشته ای خود پی اچ پی مثل base64 ، gzinflate یا str_rot13 یا هرچیز دیگری …
استفاده از این رمزنگاری ها بسیار خوب هست ، مخصوصا اگر مثلا از zend آخرین ورژن بصورت اورجینال بهره ببرید . یا مثلا ioncube بصورت اورجینال و پرمیوم !
خب . بحث و کار ما در مورد wp-config.php به پایان میرسد .اطمینان داریم که قلب وردپرسمان مستحکم تر و امن تر شد !
پست هم مقداری طولانی شد ، حوصله خودم هم سر رفت ! باقی آموزش و مسائل امنیتی را در پست دیگری احتمالا با نام وردپرس ضد گلوله ! قسمت ۳ منتشر خواهم کرد که در آن پست بیشتر به بررسی پلاگین های امنیتی و قالب ها ، سرورهاستینگ ، سطح دسترسی دایکتوری ها و فایلها و … خواهیم پرداخت …
امیدوارم وردپرس امن ، سالم و وبلاگیدن شادی داشته باشید …
پ . ن :
» امنیت هیچگاه ۱۰۰% نیست …
منبع:.itarashe.net