امنیت هاست و cPanel؛ مهم‌ترین تنظیمات برای جلوگیری از هک سایت

امنیت هاست و cPanel یعنی محافظت از حساب میزبانی، فایل‌های سایت، پایگاه داده، ایمیل‌ها، دسترسی‌های FTP/SSH، دامنه‌ها و سرویس‌های مرتبط در برابر دسترسی غیرمجاز و بدافزار. برای جلوگیری از هک سایت باید حداقل رمز عبور منحصربه‌فرد و قوی، 2FA، HTTPS، ModSecurity، نسخه به‌روز PHP و CMS، Permission مناسب فایل‌ها، Backup مستقل، محدودسازی دسترسی‌ها، اسکن بدافزار و Monitoring را به‌صورت هم‌زمان اجرا کنید.

بسیاری از مدیران سایت زمانی که درباره امنیت وب‌سایت صحبت می‌کنند، تمام تمرکز خود را روی وردپرس، افزونه امنیتی یا WAF قرار می‌دهند؛ در حالی که یک لایه پایین‌تر از Application، خود Hosting Account و کنترل پنلی مانند cPanel قرار دارد.

اگر مهاجم به حساب cPanel شما دسترسی پیدا کند، داشتن افزونه امنیتی وردپرس دیگر کمک زیادی نمی‌کند.

کاربری که کنترل cPanel را به دست آورده باشد، بسته به امکانات هاست ممکن است بتواند:

• فایل‌های سایت را تغییر دهد؛
• فایل جدید ایجاد کند؛
• نسخه‌ای از Database دریافت کند؛
• Password پایگاه داده را مشاهده یا تغییر دهد؛
• ایمیل‌های جدید ایجاد کند؛
• Cron Job اضافه کند؛
• Redirect ایجاد کند؛
• SSL و دامنه‌ها را مدیریت کند؛
• Backup دانلود کند؛
• FTP Account بسازد؛
• یا محتوای سایت را مستقیماً از File Manager دست‌کاری کند.

به همین دلیل امنیت هاست و cPanel باید یک لایه مستقل از امنیت خود سایت در نظر گرفته شود.

یک سایت ممکن است WordPress کاملاً به‌روزی داشته باشد، اما اگر Password مربوط به cPanel ضعیف باشد، همان سایت همچنان در معرض خطر جدی قرار دارد.

از طرف دیگر، نباید تصور کرد هر گزینه‌ای که در مقاله‌های «امن‌سازی cPanel» مشاهده می‌کنیم در اختیار صاحب یک هاست اشتراکی است.

بعضی تنظیمات در خود cPanel قابل انجام هستند؛ مانند 2FA، SSL، مدیریت Fileها، SSH Key، FTP Account و Backup.

اما مواردی مانند cPHulk، Firewall، Security Advisor، تنظیمات سراسری ModSecurity، سرویس‌های SSH Server یا Patch کردن سیستم‌عامل معمولاً در اختیار مدیر سرور و WHM هستند.

در این مقاله از رخنه‌کاو، امنیت هاست و cPanel را مرحله‌به‌مرحله بررسی می‌کنیم و مشخص می‌کنیم کدام تنظیمات واقعاً برای جلوگیری از هک سایت اهمیت بیشتری دارند.

امنیت هاست و cPanel دقیقاً شامل چه چیزهایی می‌شود؟

برای امن کردن سایت ابتدا باید مرزهای سیستم را بشناسیم.

یک وب‌سایت معمولی از چند لایه تشکیل شده است:

کاربر
↓
DNS / CDN
↓
HTTPS / TLS
↓
Firewall / WAF
↓
Web Server
↓
Hosting Account / cPanel
↓
PHP / Runtime
↓
WordPress یا Application
↓
Database
↓
Files / Uploads

اگر فقط یکی از این لایه‌ها امن باشد، کل سیستم الزاماً امن نیست.

مثلاً داشتن Cloudflare نمی‌تواند Password لو رفته cPanel را جبران کند.

2FA روی cPanel هم نمی‌تواند آسیب‌پذیری SQL Injection موجود در Application را برطرف کند.

در Security Architecture باید از Defense in Depth یا دفاع چندلایه استفاده شود.

یعنی اگر یک Layer شکست خورد، لایه‌های دیگر هنوز مانع تصاحب کامل سیستم شوند.

تفاوت امنیت cPanel با امنیت خود سایت چیست؟

cPanel یک Hosting Control Panel است.

از طریق آن معمولاً سرویس‌هایی مانند موارد زیر مدیریت می‌شوند:

• Domain
• Subdomain
• Files
• Database
• Email
• FTP
• SSL
• Cron Jobs
• PHP
• Backup
• SSH
• DNS در برخی سرویس‌ها

اما خود سایت ممکن است WordPress، Laravel، Joomla یا یک Application اختصاصی باشد.

برای مثال اگر Plugin وردپرس دارای XSS باشد، این مشکل Application Security است.

اگر Password حساب cPanel سرقت شود، مسئله Hosting Account Security است.

اگر SSH Server اجازه Loginهای نامحدود بدهد، مسئله Server Security است.

هر سه به هم مرتبط هستند، اما یکسان نیستند.

مهم‌ترین اصل امنیت cPanel؛ از حساب اصلی محافظت کنید

حساب اصلی cPanel یکی از حساس‌ترین Credentials سایت است.

در بسیاری از سرویس‌های هاست اشتراکی، حساب cPanel به بخش بزرگی از داده‌های سایت دسترسی دارد.

بنابراین Password آن نباید:

• با Password وردپرس یکی باشد؛
• با Password ایمیل یکی باشد؛
• روی چند سایت استفاده شود؛
• قابل حدس باشد؛
• در فایل متنی معمولی ذخیره شود.

بهترین روش استفاده از Password Manager و تولید یک Password کاملاً منحصربه‌فرد است.

NIST در راهنمای فعلی Authentication تأکید زیادی روی طول Password دارد و برای Passwordهایی که به‌صورت Single Factor استفاده می‌شوند حداقل ۱۵ کاراکتر را در استاندارد خود الزام می‌کند. همچنین NIST توصیه نمی‌کند کاربران بدون شواهدی از Compromise مجبور به تغییر دوره‌ای Password شوند.

آیا تغییر هر ماه Password امنیت را بیشتر می‌کند؟

الزاماً خیر.

تغییر بی‌دلیل و دائمی Password می‌تواند باعث شود کاربران Passwordهای قابل پیش‌بینی انتخاب کنند.

رویکرد بهتر:

• Password طولانی و Unique؛
• Password Manager؛
• 2FA؛
• تغییر فوری در صورت احتمال افشا.

اگر Password cPanel را در اختیار طراح، برنامه‌نویس یا نیروی پشتیبانی قرار داده‌اید، پس از پایان همکاری آن را تغییر دهید.

فعال کردن احراز هویت دو مرحله‌ای برای cPanel

یکی از اولین تنظیماتی که باید بررسی کنید Two-Factor Authentication یا 2FA است.

در cPanel، در صورتی که Hosting Provider این قابلیت را فعال کرده باشد، می‌توان علاوه بر Password از یک کد امنیتی شش‌رقمی تولیدشده توسط Authenticator استفاده کرد.

جریان Login سپس به شکل زیر خواهد بود:

Username
+
Password
↓
عامل اول تأیید شد
↓
کد 2FA
↓
ورود به cPanel

اگر Password شما در Phishing، Malware یا Data Breach افشا شود، مهاجم هنوز به Factor دوم نیاز دارد.

آیا 2FA روی وردپرس کافی است؟

خیر.

ممکن است wp-admin دارای 2FA باشد، اما cPanel فاقد آن باشد.

در این صورت مهاجم با دسترسی به cPanel می‌تواند فایل‌های WordPress را مستقیماً تغییر دهد.

بنابراین حساب‌های زیر را مستقل بررسی کنید:

• cPanel
• WHM
• WordPress Administrator
• ایمیل اصلی
• Registrar دامنه
• CDN
• سرویس Backup

هرکدام در صورت پشتیبانی باید MFA مناسب داشته باشند.

ایمیل متصل به هاست را هم امن کنید

یکی از بخش‌هایی که معمولاً فراموش می‌شود Email Recovery است.

فرض کنید cPanel دارای Password بسیار قوی باشد، اما ایمیلی که برای Reset Password استفاده می‌شود ضعیف باشد.

مهاجم به‌جای حمله مستقیم به cPanel ممکن است ایمیل را هدف قرار دهد.

به همین دلیل ایمیل اصلی مدیریت سایت باید:

• Password منحصربه‌فرد داشته باشد؛
• 2FA داشته باشد؛
• روی Deviceهای ناشناس Login نباشد؛
• Recovery Method امن داشته باشد.

امنیت Account Recovery به اندازه Login اهمیت دارد.

SSL و HTTPS را برای تمام دامنه‌های سایت بررسی کنید

HTTPS برای رمزگذاری ارتباط Browser و Server ضروری است.

در cPanel می‌توانید از بخش SSL/TLS Status وضعیت Certificate دامنه‌ها را بررسی کنید.

این بخش می‌تواند دامنه‌های:

• Active
• Expired
• Expiring Soon
• Unsecured
• دارای مشکل AutoSSL

را نمایش دهد.

اگر دامنه Certificate معتبر دارد، در بخش Domains نیز معمولاً گزینه Force HTTPS Redirect قابل استفاده است تا کاربران از HTTP به HTTPS هدایت شوند.

چرا HTTPS برای امنیت cPanel مهم است؟

HTTPS مانع شنود ساده Credentials در مسیر ارتباط می‌شود.

اگر صفحه Login یا سایت روی HTTP باشد، اطلاعات در مسیر Transport حفاظت کافی ندارند.

cPanel & WHM در نسخه‌های فعلی از TLS 1.2 و TLS 1.3 پشتیبانی می‌کند.

آیا SSL جلوی هک سایت را می‌گیرد؟

خیر.

SSL:

• SQL Injection را برطرف نمی‌کند؛
• Malware را حذف نمی‌کند؛
• Password ضعیف را قوی نمی‌کند؛
• Plugin آسیب‌پذیر را Patch نمی‌کند.

TLS فقط یک Layer از Security Architecture است.

AutoSSL را بررسی کنید

یکی از قابلیت‌های کاربردی cPanel & WHM، AutoSSL است.

AutoSSL می‌تواند Certificateهای Domain Validation را برای Domainهای مربوطه Provision و Renew کند.

از بخش:

Security → SSL/TLS Status

بررسی کنید:

• تمام دامنه‌های موردنیاز دارای Certificate هستند؟
• Certificate منقضی نشده؟
• AutoSSL Error وجود ندارد؟
• Subdomainهای حساس امن هستند؟

خطای SSL را ماه‌ها نادیده نگیرید.

ModSecurity را بدون دلیل خاموش نکنید

ModSecurity یک Web Application Firewall Engine است که می‌تواند Requestهای وب را براساس Ruleهای امنیتی بررسی کند.

در بسیاری از هاست‌های cPanel، Hosting Provider آن را همراه یک Ruleset مانند OWASP CRS ارائه می‌کند.

مستندات رسمی cPanel به‌صراحت توصیه می‌کند ModSecurity برای تمام Domainها فعال باشد و فقط برای Troubleshooting مشکلات مرتبط، به‌طور موقت غیرفعال شود.

اشتباه رایج

یک Plugin یا Script با Error 403 روبه‌رو می‌شود.

کاربر وارد cPanel می‌شود و:

ModSecurity → Disable

را می‌زند.

مشکل ظاهراً حل می‌شود و WAF برای همیشه خاموش می‌ماند.

این روش درست نیست.

اگر False Positive وجود دارد باید:

1. Rule مشکل‌ساز مشخص شود؛
2. Log بررسی شود؛
3. Hosting Provider Rule را اصلاح یا Exception محدود ایجاد کند؛
4. ModSecurity مجدداً فعال بماند.

خاموش کردن کل WAF برای یک Endpoint مشکل‌دار سطح Attack Surface را افزایش می‌دهد.

WAF جای به‌روزرسانی سایت را نمی‌گیرد

حتی بهترین ModSecurity Rules نیز جای Patch کردن Vulnerability را نمی‌گیرد.

فرض کنید یک Plugin وردپرس دارای آسیب‌پذیری شناخته‌شده است.

وجود WAF می‌تواند برخی Exploit Attemptها را متوقف کند، اما Plugin همچنان باید Update یا حذف شود.

معماری صحیح:

Secure Code
+
Updated Software
+
WAF
+
Monitoring

است.

نسخه PHP هاست را به‌روز نگه دارید

بخش مهم دیگری از امنیت هاست و cPanel، Runtime سایت است.

بسیاری از سایت‌های PHP برای سال‌ها روی یک نسخه قدیمی PHP باقی می‌مانند، چون مدیر سایت نگران خراب شدن Theme یا Plugin است.

اما ادامه استفاده از Runtime قدیمی می‌تواند:

• Patchهای امنیتی جدید را از بین ببرد؛
• Dependencyهای قدیمی را حفظ کند؛
• سطح حمله را افزایش دهد.

در cPanel معمولاً MultiPHP Manager امکان مشاهده و تغییر PHP Version هر Domain را فراهم می‌کند.

آیا باید همیشه آخرین PHP را فوراً انتخاب کنیم؟

نه لزوماً.

روال درست:

1. Backup بگیرید.
2. Compatibility سایت را بررسی کنید.
3. در Staging تست کنید.
4. Plugin و Theme را به‌روز کنید.
5. PHP Supported Version را انتخاب کنید.
6. Error Log را بررسی کنید.

امنیت نباید به قیمت شکستن Production باشد، اما Compatibility نیز نباید بهانه‌ای برای استفاده دائمی از Software منقضی باشد.

WordPress، Plugin و Theme را نیز Update کنید

امنیت هاست نمی‌تواند Application قدیمی را نجات دهد.

در سایت WordPress باید به‌طور منظم موارد زیر بررسی شوند:

• WordPress Core
• Pluginها
• Theme
• PHP
• Libraryهای Third-party

Pluginهایی که دیگر Update نمی‌شوند یا توسط Developer رها شده‌اند باید جدی بررسی شوند.

Unused Plugin نیز بهتر است Delete شود، نه اینکه فقط Deactivate شود.

هر Code موجود روی Server می‌تواند Attack Surface ایجاد کند.

File Permissionها را براساس Least Privilege تنظیم کنید

File Permission تعیین می‌کند چه User یا Processهایی اجازه:

• Read
• Write
• Execute

دارند.

یکی از خطرناک‌ترین اقدامات در Hosting، استفاده بی‌دلیل از Permission بسیار باز مانند:

777

است.

گاهی Developer برای رفع یک Permission Error، کل Folder را 777 می‌کند.

این کار ممکن است مشکل را ظاهراً حل کند، اما دسترسی Write/Execute بیش از حد ایجاد می‌کند.

آیا همیشه فایل‌ها باید 644 و پوشه‌ها 755 باشند؟

این الگو در بسیاری از Linux Hostingها رایج است، اما نباید بدون شناخت Server Architecture آن را یک قانون مطلق دانست.

PHP Handler، Ownership، ACL، SuEXEC و ساختار Hosting اهمیت دارند.

اصل مهم این است:

هر فایل فقط حداقل Permission موردنیاز را داشته باشد.

اگر Site با Permission محدودتر کار می‌کند، دلیلی برای بازتر کردن آن وجود ندارد.

فایل‌های حساس را شناسایی کنید

بسته به Application، فایل‌هایی وجود دارند که اطلاعات حساس نگهداری می‌کنند.

مثلاً در WordPress:

wp-config.php

ممکن است شامل Database Credential و Secretهای مهم باشد.

در Frameworkهای دیگر:

.env

اهمیت زیادی دارد.

این فایل‌ها نباید:

• Publicly Accessible باشند؛
• در Backup عمومی باقی بمانند؛
• داخل Git Public Repository بروند؛
• Permission بیش از حد باز داشته باشند.

Backupها را داخل public_html رها نکنید

یکی از اشتباهات بسیار رایج این است که مدیر سایت فایلی مانند:

backup.zip
old-site.zip
database.sql
website-backup.tar.gz

در public_html قرار می‌دهد.

حتی اگر Link آن در هیچ صفحه‌ای وجود نداشته باشد، Public Directory محل خوبی برای Backup حساس نیست.

Backup ممکن است شامل:

• Database
• User Data
• Password Hash
• Configuration
• API Key
• Source Code

باشد.

Backup باید در Storage امن و ترجیحاً خارج از Web Root نگهداری شود.

Backup مستقل از هاست داشته باشید

داشتن Backup یکی از مهم‌ترین اجزای امنیت است.

Backup مستقیماً جلوی Attack را نمی‌گیرد، اما در صورت:

• Malware
• Ransomware
• حذف فایل
• Defacement
• Database Corruption
• Human Error

امکان Recovery را فراهم می‌کند.

cPanel دارای Backup Wizard است که امکان تهیه Backup از تمام یا بخشی از سایت را فراهم می‌کند. با این حال مستندات cPanel می‌گوید Restore خودکار Full Backup از داخل cPanel در دسترس نیست و Full Restore در سطح WHM انجام می‌شود.

فقط به Backup شرکت هاست اعتماد نکنید

ممکن است Hosting Provider Backup داشته باشد.

عالی است.

اما شما نیز باید نسخه مستقلی داشته باشید.

اگر:

• حساب Suspend شود؛
• شرکت هاست مشکل Storage پیدا کند؛
• Backup Provider خراب باشد؛
• Account Compromise شامل Backupها نیز شود،

نسخه مستقل می‌تواند حیاتی باشد.

یک Strategy مناسب شامل چند Copy و حداقل یک نسخه خارج از همان Hosting Environment است.

Backup باید تست شود

فایل Backup زمانی ارزش دارد که بتوان آن را Restore کرد.

مشکل رایج:

ماه‌ها Backup گرفته شده، اما هنگام Incident مشخص می‌شود:

• ناقص است؛
• Database ندارد؛
• Archive خراب است؛
• Backup مربوط به Domain اشتباه بوده؛
• Credentials لازم وجود ندارند.

هر چند وقت یک‌بار Recovery Test انجام دهید.

حساب‌های FTP اضافی را حذف کنید

FTP Accountهای قدیمی یکی از Credentialهای فراموش‌شده Hosting هستند.

مثلاً Developer یک سال قبل حسابی ایجاد کرده و هنوز فعال است.

در cPanel می‌توان FTP Accountها را مشاهده و حساب‌های غیرضروری را حذف کرد.

هر Account اضافه یعنی:

• Credential اضافه؛
• Attack Surface بیشتر؛
• مدیریت سخت‌تر.

اصل ساده

اگر Account استفاده نمی‌شود:

Delete.

اگر Account فقط به یک Directory نیاز دارد:

Scope دسترسی آن را محدود کنید.

FTP معمولی یا SFTP؟

FTP سنتی بدون لایه رمزنگاری مناسب انتخاب ایده‌آلی برای انتقال Credential حساس نیست.

اگر Hosting شما SSH/SFTP ارائه می‌کند، استفاده از SFTP گزینه بهتری است.

SFTP روی SSH کار می‌کند و ارتباط رمزگذاری می‌شود.

البته Availability آن به Hosting Provider بستگی دارد.

SSH را فقط در صورت نیاز فعال نگه دارید

SSH ابزار بسیار قدرتمندی است.

اگر Developer هستید می‌تواند برای:

• Composer
• WP-CLI
• Git
• Deployment
• مدیریت فایل‌ها

بسیار مفید باشد.

اما اگر هیچ استفاده‌ای ندارید، وجود Shell Access غیرضروری Attack Surface را افزایش می‌دهد.

cPanel نیز اشاره می‌کند که تمام Hosting Providerها Shell Access ارائه نمی‌کنند.

در سطح Server، مستندات cPanel توصیه می‌کند SSH فقط در اختیار Userهایی قرار گیرد که واقعاً به آن نیاز دارند و برای برخی کاربران از Jailed Shell استفاده شود.

برای SSH از Public Key استفاده کنید

در صورت امکان:

SSH Public Key Authentication

را جایگزین اتکای کامل به Password کنید.

در cPanel بخش SSH Access امکان مدیریت Keyها را فراهم می‌کند، البته اگر Provider آن را فعال کرده باشد.

Private Key باید:

• روی Device امن باشد؛
• Permission مناسب داشته باشد؛
• با دیگران Share نشود؛
• در Git قرار نگیرد.

برای Account حساس استفاده از Passphrase روی Private Key نیز منطقی است.

API Tokenهای cPanel را بررسی کنید

برخی Applicationها یا Automationها ممکن است از cPanel API Token استفاده کنند.

API Token می‌تواند بدون Login Interactive به توابع Account دسترسی بدهد.

cPanel امکان ایجاد، مشاهده و Revoke کردن API Tokenها را ارائه می‌کند. همچنین Tokenهای Expired الزاماً به‌صورت خودکار از List حذف نمی‌شوند و باید مدیریت شوند.

بنابراین به‌طور دوره‌ای بررسی کنید:

• چه Tokenهایی وجود دارند؟
• متعلق به چه Applicationی هستند؟
• هنوز استفاده می‌شوند؟
• Expiration دارند؟
• Token ناشناس وجود دارد؟

Token فراموش‌شده مثل یک Password فراموش‌شده است.

اصل Least Privilege برای همه Accountها

هیچ Developer، Plugin یا Automation نباید بیش از نیاز خود دسترسی داشته باشد.

اگر Contractor فقط باید یک Subdirectory را مدیریت کند، دادن Password اصلی cPanel تصمیم خوبی نیست.

در صورت امکان از:

• Subaccount
• FTP محدود
• Repository Access
• Hosting-specific Team Access

استفاده کنید.

cPanel User Manager نیز امکان مدیریت بعضی Subaccountها برای سرویس‌هایی مانند FTP، Web Disk و Webmail را فراهم می‌کند.

Password را در پیام‌رسان ارسال نکنید

یکی از ضعف‌های عملیاتی امنیت سایت نه Vulnerability فنی، بلکه شیوه اشتراک Credential است.

Password cPanel را در:

• Group Chat
• Screenshot
• Email غیرضروری
• Ticket عمومی
• فایل Excel مشترک

قرار ندهید.

از Password Manager دارای قابلیت Secure Sharing یا Access Control مناسب استفاده کنید.

Cron Jobهای cPanel را بررسی کنید

Cron Jobها دستورهایی هستند که در زمان‌بندی مشخص اجرا می‌شوند.

این قابلیت کاملاً Legitimate است، اما در Incident Response اهمیت زیادی دارد.

اگر مهاجم بتواند Cron Job ایجاد کند، ممکن است از آن برای Persistence استفاده کند.

در cPanel بخش Cron Jobs فهرست Taskهای زمان‌بندی‌شده را نمایش می‌دهد.

به‌طور دوره‌ای بررسی کنید:

• Cron ناشناس وجود ندارد؟
• Script Path معتبر است؟
• Task قدیمی هنوز لازم است؟
• Cron بیش از حد تکرار نمی‌شود؟

cPanel نیز هشدار می‌دهد اجرای بیش از حد Cronها می‌تواند Performance را کاهش دهد.

Malware Scanner را در صورت وجود استفاده کنید

بعضی Hosting Providerها Virus Scanner یا Malware Scanner ارائه می‌کنند.

در cPanel، Virus Scanner در صورت نصب ClamAV توسط Provider می‌تواند:

• Mail
• Home Directory
• Public FTP Space
• Public Web Space

را Scan کند.

اگر Hosting شما ImunifyAV یا سرویس دیگری ارائه می‌دهد، قابلیت‌های آن را نیز بررسی کنید.

آیا Malware Scanner تضمین می‌کند سایت پاک است؟

خیر.

Scanner می‌تواند فایل‌های شناخته‌شده یا Patternهای مخرب را شناسایی کند، اما:

• همه Malwareها Signature شناخته‌شده ندارند؛
• Obfuscation وجود دارد؛
• Backdoor ممکن است شبیه Code عادی باشد؛
• Database Infection ممکن است متفاوت باشد.

Malware Scan بخشی از Defense in Depth است.

ModSecurity و Malware Scanner با هم فرق دارند

ModSecurity:

Requestهای وب را هنگام ورود بررسی می‌کند.

Malware Scanner:

Fileهای موجود روی Storage را بررسی می‌کند.

یکی Preventive/Detection Layer روی Traffic است و دیگری File Analysis انجام می‌دهد.

هر دو مفیدند اما جای یکدیگر را نمی‌گیرند.

Error Log و Access Log را بررسی کنید

امنیت بدون Visibility ناقص است.

cPanel بخش‌هایی مانند Errors و Raw Access دارد.

Raw Access Log شامل اطلاعات Requestهای بازدیدکنندگان و Resourceهای درخواست‌شده است و قابل Download است.

در Incident Analysis می‌توان به دنبال مواردی مانند:

• Requestهای غیرعادی زیاد؛
• درخواست به فایل ناشناس؛
• Endpointهای عجیب؛
• Errorهای تکراری؛
• Login Attemptهای غیرطبیعی

بود.

Log فقط برای Developer نیست

گاهی اولین نشانه هک در Log دیده می‌شود.

برای مثال:

• اجرای PHP ناشناس؛
• Requestهای متعدد به URL جدید؛
• خطای ناگهانی Application؛
• Traffic غیرعادی.

Monitoring باید بخشی از عملیات عادی سایت باشد.

مصرف CPU، RAM و Bandwidth را مانیتور کنید

بعضی Hosting Providerها در cPanel اطلاعات Resource Usage را نمایش می‌دهند.

افزایش غیرطبیعی:

• CPU
• Concurrent Connection
• Bandwidth
• Disk Usage

می‌تواند نشانه Problem باشد.

البته بالا رفتن Resource الزاماً هک نیست.

ممکن است:

• Traffic واقعی افزایش یافته باشد؛
• Cron خراب باشد؛
• Plugin سنگین باشد؛
• Backup اجرا شود.

اما تغییر ناگهانی باید بررسی شود.

Disk Usage را جدی بگیرید

Disk Full می‌تواند سایت را از کار بیندازد.

فایل‌های زیر را بررسی کنید:

• Backup قدیمی
• Log حجیم
• Cache
• Email Attachment
• Temporary Files
• Staging Copy

مهاجم نیز ممکن است با Uploadهای زیاد Resource Exhaustion ایجاد کند.

برای File Uploadهای سایت Limit مناسب داشته باشید.

پوشه‌های حساس را در صورت نیاز Password Protect کنید

cPanel دارای Directory Privacy است که می‌تواند برای Directoryهای مشخص HTTP Authentication ایجاد کند. این قابلیت با تنظیم .htaccess و .htpasswd دسترسی وب به Directory را محدود می‌کند.

این قابلیت می‌تواند برای:

• Staging
• Development Area
• Private Documentation

مفید باشد.

اما توجه کنید Directory Privacy دسترسی از طریق FTP، SFTP یا File System را محدود نمی‌کند.

پس این Feature یک Layer وب است، نه Permission File System.

Staging Site را Public رها نکنید

خیلی از سایت‌ها نسخه‌ای مانند:

dev.example.com
staging.example.com
test.example.com

دارند.

گاهی Production کاملاً امن است اما Staging:

• Password ضعیف دارد؛
• Update نشده؛
• Debug فعال است؛
• Database واقعی دارد؛
• Search Engine آن را Index کرده است.

Staging باید حداقل به اندازه Production جدی گرفته شود.

اگر عمومی بودن لازم نیست:

• Authentication اضافه کنید؛
• Access IP را محدود کنید؛
• Data واقعی را Mask کنید.

فایل‌های قدیمی سایت را حذف کنید

گاهی در Hosting چند نسخه سایت وجود دارد:

/public_html/
/old/
/backup-site/
/test/
/new-site/

نسخه /old/ ممکن است WordPress سه سال قبل با Plugin آسیب‌پذیر باشد.

حتی اگر Link نشده باشد، Web Server ممکن است همچنان آن را Serve کند.

هر Application فراموش‌شده Attack Surface است.

اگر لازم نیست، حذف یا از Web Root خارج کنید.

Subdomainهای فراموش‌شده را بررسی کنید

همین اصل برای Domain و Subdomain نیز صادق است.

در cPanel بخش Domains را مرور کنید.

آیا هنوز مواردی مانند:

demo.
old.
dev.
test.
api-old.

وجود دارند؟

هر Hostname فعال باید:

• Purpose مشخص داشته باشد؛
• SSL داشته باشد؛
• Application آن Update باشد؛
• Owner مشخص داشته باشد.

Database Userها را محدود کنید

در Database Security اصل Least Privilege مهم است.

Application نباید با Database User قدرتمندتر از نیاز خود کار کند.

در هاست اشتراکی معمولاً Database User را از cPanel مدیریت می‌کنید.

موارد مهم:

• Password Unique؛
• Userهای قدیمی حذف شوند؛
• Application فقط Database موردنیاز را داشته باشد؛
• Credential Database در Repository عمومی نباشد.

اگر Database Password افشا شده، فقط تغییر Password کافی نیست؛ Root Cause افشا را نیز پیدا کنید.

phpMyAdmin را در معرض Account ضعیف قرار ندهید

در بسیاری از cPanel Hostingها phpMyAdmin از Authentication خود cPanel استفاده می‌کند یا از طریق Session کنترل پنل قابل دسترسی است.

بنابراین تصاحب cPanel می‌تواند به Database Access نیز تبدیل شود.

این دلیل دیگری برای اهمیت 2FA و حفاظت Credential اصلی است.

Security Headerها را نیز فراموش نکنید

Hosting Layer محل مناسبی برای بعضی HTTP Security Headerها است.

بسته به Server Configuration می‌توان مواردی مانند:

• HSTS
• Content-Security-Policy
• X-Content-Type-Options
• Referrer-Policy

را در Server یا Application Layer مدیریت کرد.

اما Policy را بدون تست Copy-Paste نکنید.

به‌خصوص CSP و HSTS می‌توانند در صورت تنظیم اشتباه عملکرد سایت را مختل کنند.

Hotlink Protection ابزار ضد هک اصلی نیست

cPanel قابلیت Hotlink Protection دارد.

Hotlink زمانی رخ می‌دهد که سایت دیگر Resource شما را مستقیماً Embed کند و Bandwidth شما مصرف شود.

این قابلیت بیشتر برای کنترل Bandwidth و Resource Usage است.

نباید Hotlink Protection را با WAF، Malware Protection یا Access Control اشتباه گرفت.

IP Blocker را هوشمندانه استفاده کنید

cPanel در بعضی Hostingها IP Blocker ارائه می‌کند.

اگر IP مشخصی Abuse ایجاد می‌کند می‌توان آن را Block کرد.

اما Block دستی IP راهکار اصلی در برابر Botnet یا Distributed Attack نیست.

مهاجم می‌تواند IP عوض کند.

برای حملات گسترده‌تر:

• WAF
• Rate Limiting
• CDN
• Firewall

مناسب‌تر هستند.

اگر VPS و WHM دارید مسئولیت شما بیشتر است

تا اینجا بخش زیادی از توصیه‌ها برای صاحب cPanel Account بود.

اما اگر VPS یا Dedicated Server دارید و خودتان WHM Administrator هستید، مسئولیت Server Security نیز با شماست.

موارد مهم شامل:

• OS Updates
• cPanel Updates
• Firewall
• SSH Configuration
• cPHulk
• ModSecurity Rules
• Service Configuration
• Malware Protection
• Backup Infrastructure
• DNS Security
• Mail Security

است.

cPHulk را در WHM فعال و تنظیم کنید

cPHulk قابلیت Brute Force Protection خود cPanel & WHM است.

طبق مستندات رسمی، cPHulk می‌تواند Login Attemptهای مربوط به سرویس‌هایی مانند:

• cPanel
• WHM
• Mail
• FTP
• SSH

را مانیتور و در برابر Brute Force واکنش نشان دهد.

اگر Shared Hosting دارید این تنظیم دست Hosting Provider است.

اگر Server Administrator هستید، Configuration آن را بررسی کنید.

آیا cPHulk جای Firewall است؟

خیر.

cPHulk یک Brute Force Protection Layer است.

Firewall هدف گسترده‌تری دارد.

همچنین WAF با cPHulk متفاوت است.

سه مفهوم:

Firewall → Network Access
cPHulk → Login Brute Force
ModSecurity → HTTP Request / WAF

هستند.

Security Advisor در WHM

اگر WHM در اختیار دارید، Security Advisor یکی از ابزارهایی است که cPanel برای بررسی برخی تنظیمات امنیتی Server ارائه می‌کند.

مستندات cPanel آن را ابزاری معرفی می‌کند که Server را Scan کرده و درباره بعضی Issues امنیتی پیشنهاد ارائه می‌دهد.

Security Advisor جای Audit حرفه‌ای را نمی‌گیرد، اما برای Baseline مفید است.

سرویس‌های غیرضروری را محدود کنید

روی VPS اصل Attack Surface Reduction بسیار مهم است.

اگر Service استفاده نمی‌شود، وجود آن باید توجیه داشته باشد.

مثلاً:

• SSH
• FTP
• Web Disk
• Mail Service
• Database Remote Access

هر Port و Daemon اضافه سطح حمله بالقوه ایجاد می‌کند.

البته در Shared Hosting تصمیم درباره سرویس‌های Server با Provider است.

سیستم‌عامل و cPanel باید Patch شوند

Server Administrator باید Updateها را جدی بگیرد.

آسیب‌پذیری Application فقط بخشی از Threat Model است.

Kernel، OpenSSL، Web Server، Mail Server، PHP و Control Panel نیز Software هستند و Patch نیاز دارند.

Delay طولانی در Security Update خطر Exposure را افزایش می‌دهد.

از هاست معتبر استفاده کنید

همه اقدامات سمت User زمانی ارزش واقعی دارند که Hosting Provider نیز Security Operations مناسبی داشته باشد.

هنگام انتخاب Hosting فقط CPU و Storage را مقایسه نکنید.

موارد مهم:

• Backup Policy چیست؟
• Malware Monitoring دارد؟
• WAF دارد؟
• ModSecurity فعال است؟
• 2FA cPanel را پشتیبانی می‌کند؟
• Serverها Patch می‌شوند؟
• Incident Response چگونه است؟
• Isolation Accountها چگونه انجام می‌شود؟

در Shared Hosting، امنیت Provider بخشی از Security شماست.

چگونه بفهمیم cPanel یا هاست هک شده است؟

نشانه قطعی واحدی وجود ندارد، اما موارد زیر نیازمند بررسی فوری هستند:

• File ناشناس؛
• تغییر ناگهانی .htaccess؛
• Administrator ناشناس؛
• Cron Job ناشناس؛
• FTP Account جدید؛
• Email Account ناشناس؛
• Redirect به سایت دیگر؛
• افزایش Disk Usage؛
• افزایش CPU؛
• ارسال Spam؛
• تغییر صفحه اصلی؛
• Malware Alert؛
• Login Notification ناشناس؛
• API Token ناشناس؛
• Database User جدید؛
• File Timestamp غیرعادی.

یک نشانه به‌تنهایی لزوماً اثبات هک نیست، اما Combination آن‌ها اهمیت زیادی دارد.

اگر احتمال می‌دهیم cPanel هک شده چه کنیم؟

اولین واکنش نباید صرفاً Delete کردن یک فایل مشکوک باشد.

Incident Response باید ساختاریافته باشد.

مرحله اول: دسترسی مهاجم را قطع کنید

از Device سالم:

• Password cPanel را تغییر دهید؛
• 2FA را فعال یا Reset کنید؛
• Password ایمیل Recovery را تغییر دهید؛
• FTP Passwordها را Rotate کنید؛
• SSH Keyهای ناشناس را حذف کنید؛
• API Tokenها را Revoke کنید.

مرحله دوم: Sessionها و دسترسی‌ها را بررسی کنید

در صورت وجود قابلیت مناسب:

• Sessionهای ناشناس را ببندید؛
• Accountهای جدید را حذف کنید؛
• Deviceها را بررسی کنید.

مرحله سوم: Evidence را نابود نکنید

اگر Incident جدی است، پیش از پاک‌سازی کورکورانه:

• Logها؛
• Timestampها؛
• فایل‌های مشکوک؛
• Backup

را حفظ کنید.

برای Forensics ممکن است لازم باشند.

مرحله چهارم: Malware Scan

کل Account را Scan کنید، نه فقط File مشخص.

مرحله پنجم: Application را بررسی کنید

WordPress Core، Plugin، Theme و User Accountها Audit شوند.

مرحله ششم: Database را بررسی کنید

محتوای Injection، Administrator ناشناس و تغییر Settingها بررسی شود.

مرحله هفتم: Root Cause پیدا شود

اگر فقط Malware را Delete کنید ولی مسیر ورود مهاجم باقی بماند، Infection ممکن است برگردد.

Root Cause ممکن است:

• Plugin آسیب‌پذیر؛
• Password سرقت‌شده؛
• FTP Credential؛
• File Upload Vulnerability؛
• Server Compromise

باشد.

مرحله هشتم: Restore در صورت نیاز

گاهی Restore از Backup سالم سریع‌تر و مطمئن‌تر است.

اما Backup باید مربوط به قبل از Compromise باشد.

اشتباهات رایج در امنیت هاست و cPanel

۱. استفاده از یک Password برای همه چیز

وردپرس، cPanel، FTP و Email نباید یک Password داشته باشند.

۲. فعال نکردن 2FA

Password تنها یک Single Point of Failure ایجاد می‌کند.

۳. ذخیره Password در مرورگر یا دستگاه آلوده

حتی Password بسیار پیچیده روی Endpoint آلوده قابل سرقت است.

۴. خاموش کردن ModSecurity

WAF را برای حل یک Error عادی به‌طور دائمی خاموش نکنید.

۵. استفاده از Permission 777

Permission اضافی مشکل را حل نمی‌کند؛ فقط سطح دسترسی را افزایش می‌دهد.

۶. نگهداری Backup در public_html

Backup خصوصی را Publicly Accessible نکنید.

۷. استفاده دائمی از PHP قدیمی

Compatibility باید اصلاح شود، نه اینکه Runtime منقضی برای همیشه حفظ شود.

۸. حساب FTP فراموش‌شده

Credential قدیمی را حذف کنید.

۹. Staging بدون Password

نسخه Test نیز می‌تواند Entry Point باشد.

۱۰. نادیده گرفتن Cron Job

Task ناشناس ممکن است Persistence ایجاد کند.

۱۱. نداشتن Backup خارجی

خرابی همان Hosting نباید تمام Backupها را هم از بین ببرد.

۱۲. اعتماد کامل به Malware Scanner

Scanner تضمین صددرصد نیست.

۱۳. تصور اینکه SSL یعنی سایت امن است

HTTPS فقط Transport Security است.

۱۴. نخواندن Logها

بدون Monitoring ممکن است Compromise هفته‌ها دیده نشود.

۱۵. دادن Password اصلی cPanel به همه توسعه‌دهندگان

برای هر شخص کمترین Access لازم را ایجاد کنید.

چک‌لیست امنیت cPanel برای صاحب هاست اشتراکی

حساب اصلی

• Password طولانی و Unique است؟
• Password در Password Manager ذخیره شده؟
• 2FA فعال است؟
• Recovery Email امن است؟

Domain و HTTPS

• SSL تمام Domainها معتبر است؟
• AutoSSL Error ندارید؟
• Force HTTPS فعال است؟
• Subdomain قدیمی وجود ندارد؟

Fileها

• Permissionها بیش از حد باز نیستند؟
• فایل حساس Public نیست؟
• Backup داخل public_html وجود ندارد؟
• File ناشناس وجود ندارد؟

FTP و SSH

• FTP Account اضافی حذف شده؟
• SFTP در صورت امکان استفاده می‌شود؟
• SSH فقط در صورت نیاز فعال است؟
• SSH Keyهای ناشناس وجود ندارند؟

PHP و Application

• PHP Supported است؟
• WordPress به‌روز است؟
• Pluginها Update هستند؟
• Plugin غیرفعال قدیمی حذف شده؟

WAF

• ModSecurity فعال است؟
• برای رفع Error به‌طور دائمی خاموش نشده؟

Backup

• Backup منظم دارید؟
• نسخه خارج از هاست دارید؟
• Restore را تست کرده‌اید؟

Monitoring

• Error Log بررسی می‌شود؟
• Disk Usage بررسی می‌شود؟
• CPU Usage بررسی می‌شود؟
• Cron Jobها شناخته‌شده هستند؟

Malware

• Scanner هاست در صورت وجود استفاده می‌شود؟
• Malware Alertها پیگیری می‌شوند؟

چک‌لیست اضافه برای مدیر VPS و WHM

اگر Root Access دارید، موارد زیر نیز اضافه می‌شوند:

• cPHulk فعال و تنظیم شده؟
• Firewall فعال است؟
• SSH محدود شده؟
• Root Access محافظت شده؟
• Public Key Authentication بررسی شده؟
• ModSecurity Ruleset فعال است؟
• Security Advisor بررسی شده؟
• سیستم‌عامل Patch است؟
• cPanel Update است؟
• PHP Versionهای منقضی حذف شده‌اند؟
• Serviceهای غیرضروری بسته شده‌اند؟
• Backup Server جداگانه وجود دارد؟
• Malware Monitoring فعال است؟
• Log Monitoring و Alerting دارید؟

اولویت‌بندی امنیت هاست و cPanel

اگر امروز بخواهید امنیت یک Hosting Account را از صفر بهتر کنید، ترتیب زیر منطقی است:

اولویت ۱: حساب cPanel

Password Unique + 2FA

اولویت ۲: ایمیل Recovery

Password Unique + MFA

اولویت ۳: HTTPS

SSL معتبر + Force HTTPS

اولویت ۴: Backup

Backup سالم + نسخه خارج از Hosting

اولویت ۵: Software

PHP + WordPress + Plugin + Theme

اولویت ۶: WAF

ModSecurity فعال

اولویت ۷: Access

FTP، SSH، API Token و Subaccountهای اضافی حذف شوند.

اولویت ۸: Files

Permission، Backup File و فایل‌های ناشناس بررسی شوند.

اولویت ۹: Monitoring

Log، CPU، Disk و Malware Alert بررسی شود.

اولویت ۱۰: Incident Plan

بدانید در صورت هک چگونه Recovery انجام می‌دهید.

آیا امنیت هاست گران است؟

بخش بزرگی از اقدامات امنیتی ضروری هزینه زیادی ندارند.

مواردی مانند:

• Password Manager
• 2FA
• حذف Account اضافی
• Update
• Permission صحیح
• ModSecurity
• Backup Planning

بیشتر به مدیریت صحیح نیاز دارند.

البته برای سایت‌های حساس ممکن است سرویس‌هایی مانند:

• Managed WAF
• Premium Backup
• Malware Removal
• SIEM
• Security Monitoring

نیز ارزشمند باشند.

هزینه Security باید با ارزش Data و Business Risk مقایسه شود.

امنیت cPanel برای سایت وردپرسی مهم‌تر است یا wp-admin؟

هر دو.

این سؤال شبیه این است که بپرسیم قفل در اصلی مهم‌تر است یا در داخلی.

اگر wp-admin هک شود، مهاجم ممکن است سایت را تصاحب کند.

اگر cPanel هک شود، حتی ممکن است کنترل بیشتری داشته باشد.

بنابراین هر دو Account باید مستقل محافظت شوند.

آیا تغییر آدرس ورود cPanel امنیت ایجاد می‌کند؟

Security by Obscurity کنترل اصلی نیست.

مخفی کردن URL ممکن است Noise بعضی Botها را کاهش دهد، اما مهاجم حرفه‌ای می‌تواند Service را شناسایی کند.

امنیت باید بر:

• Authentication
• MFA
• Rate Limiting
• Firewall
• Monitoring

متکی باشد.

آیا تغییر Port SSH جلوی هک را می‌گیرد؟

تغییر Port ممکن است حجم Scanهای Automated را کاهش دهد، اما جای Authentication قوی و Firewall را نمی‌گیرد.

یک SSH روی Port غیرمعمول با Password ضعیف همچنان ناامن است.

اولویت:

• Key Authentication
• Access Restriction
• Rate Limiting
• cPHulk/Firewall

است.

آیا Cloudflare امنیت cPanel را تأمین می‌کند؟

معمولاً Cloudflare از Traffic وب Domain محافظت می‌کند.

Login مستقیم cPanel، SSH، FTP یا Mail ممکن است اصلاً از Cloudflare عبور نکند.

پس فعال بودن CDN نباید باعث شود Account Security را فراموش کنید.

آیا Antivirus کامپیوتر مدیر سایت مهم است؟

بله.

بسیاری از Credential Theftها از خود Server شروع نمی‌شوند.

Infostealer روی Windows یا Browser Extension مخرب می‌تواند:

• Password
• Cookie
• Session
• FTP Credential

را سرقت کند.

پس Device مدیر سایت نیز بخشی از Security Architecture است.

امنیت cPanel فقط مجموعه‌ای از تنظیمات نیست

یکی از مهم‌ترین نکات این مقاله همین است.

شما نمی‌توانید یک‌بار:

• 2FA فعال کنید؛
• SSL نصب کنید؛
• ModSecurity روشن کنید؛

و سپس امنیت را برای همیشه تمام‌شده بدانید.

سایت دائماً تغییر می‌کند.

Developer جدید می‌آید.

Plugin نصب می‌شود.

PHP Upgrade می‌شود.

Subdomain جدید ساخته می‌شود.

API Token ایجاد می‌شود.

Backup منتقل می‌شود.

پس Security باید یک Process باشد.

برنامه پیشنهادی نگهداری امنیت هاست

هفتگی

• بررسی Backup
• Update Application
• بررسی Malware Alert
• بررسی Resource Usage

ماهانه

• Account Audit
• FTP/SSH Audit
• Cron Audit
• Domain Audit
• PHP Version Check
• Log Review

پس از تغییر Developer

• Rotate Password
• Revoke Access
• حذف FTP/SSH Account
• Revoke Token

پس از Incident

• Credential Rotation
• Full Scan
• Log Review
• Root Cause Analysis
• Restore در صورت نیاز
• Hardening مجدد

سؤالات متداول درباره امنیت هاست و cPanel

امنیت هاست و cPanel چیست؟

امنیت هاست و cPanel مجموعه‌ای از کنترل‌ها برای محافظت از حساب Hosting، فایل‌ها، Database، Domain، Email، FTP، SSH و سایر سرویس‌ها در برابر دسترسی غیرمجاز، بدافزار و سوءاستفاده است.

مهم‌ترین کار برای افزایش امنیت cPanel چیست؟

استفاده از Password کاملاً Unique و فعال کردن 2FA دو اقدام بسیار مهم اولیه هستند.

آیا cPanel قابل هک است؟

مانند هر Software و Account دیگری، در صورت وجود Vulnerability، Credential Theft یا تنظیمات ضعیف امکان Compromise وجود دارد. به همین دلیل Update و Authentication قوی ضروری هستند.

آیا 2FA برای cPanel لازم است؟

برای Account حساس Hosting استفاده از 2FA به‌شدت توصیه می‌شود. cPanel نیز قابلیت رسمی Two-Factor Authentication دارد، البته Hosting Provider باید آن را فعال کرده باشد.

آیا SSL امنیت هاست را کامل می‌کند؟

خیر. SSL/TLS فقط ارتباط Client و Server را رمزگذاری می‌کند و جایگزین WAF، Patch، 2FA یا Secure Code نیست.

آیا ModSecurity را فعال کنیم؟

در حالت معمول بله. خود cPanel نیز توصیه می‌کند ModSecurity برای تمام Domainها فعال باشد و فقط هنگام Troubleshooting موقتاً غیرفعال شود.

خطای 403 دارم؛ ModSecurity را خاموش کنم؟

ابتدا مشخص کنید Error واقعاً از ModSecurity است یا نه. اگر Rule باعث False Positive شده، Exception محدود بهتر از Disable کردن کل WAF است.

Permission 777 خطرناک است؟

در اکثر سناریوهای Hosting، Permission 777 بسیار بازتر از نیاز Application است و نباید بدون دلیل استفاده شود.

بهترین Permission برای فایل‌های سایت چیست؟

به Server Architecture بستگی دارد. مقادیر 644 برای File و 755 برای Directory در بسیاری از Hostingهای Linux رایج هستند، اما Rule مطلق نیستند. اصل Least Privilege را رعایت کنید و راهنمای Hosting Provider را در نظر بگیرید.

آیا Backup هاست کافی است؟

بهتر است علاوه بر Backup Provider، نسخه مستقل خارج از همان Hosting نیز داشته باشید.

چند وقت یک‌بار Backup بگیریم؟

به میزان تغییر Data بستگی دارد. فروشگاهی که هر ساعت Order دارد نیاز متفاوتی از یک سایت شرکتی Static دارد.

آیا Backup داخل public_html امن است؟

خیر. Backup حساس نباید Publicly Accessible باشد.

FTP یا SFTP کدام بهتر است؟

در صورت پشتیبانی Hosting، SFTP به دلیل استفاده از ارتباط رمزگذاری‌شده SSH گزینه مناسب‌تری است.

آیا SSH را فعال کنیم؟

فقط اگر نیاز دارید. اگر SSH استفاده نمی‌شود، نگه داشتن Access اضافی ضروری نیست.

آیا SSH Key بهتر از Password است؟

Public Key Authentication در صورت مدیریت صحیح Keyها روش بسیار مناسبی برای SSH است.

آیا Malware Scanner کافی است؟

خیر. Malware Scanner یک Layer است و جایگزین Update، WAF، Secure Code و Monitoring نمی‌شود.

از کجا بفهمیم File مخرب روی هاست وجود دارد؟

Malware Scanner، File Audit، Timestampها، Integrity Monitoring و Log Analysis می‌توانند کمک کنند، اما تشخیص حرفه‌ای ممکن است نیازمند بررسی دستی Code باشد.

آیا cPanel خودش Brute Force Protection دارد؟

در سطح WHM، cPHulk برای مقابله با Brute Force روی سرویس‌هایی مانند cPanel، WHM، Mail، FTP و SSH وجود دارد. این تنظیم معمولاً در اختیار Server Administrator است.

آیا صاحب هاست اشتراکی به cPHulk دسترسی دارد؟

معمولاً خیر. مدیریت cPHulk در سطح WHM/Server است و Hosting Provider آن را کنترل می‌کند.

آیا PHP قدیمی خطرناک است؟

PHP خارج از Support ممکن است Security Updateهای استاندارد را دریافت نکند. بهتر است پس از تست Compatibility به نسخه Supported مهاجرت کنید.

آیا حذف Plugin غیرفعال لازم است؟

اگر Plugin استفاده نمی‌شود، حذف آن Attack Surface و پیچیدگی Maintenance را کاهش می‌دهد.

آیا Subdomain قدیمی خطر دارد؟

بله، اگر Application قدیمی یا بدون Maintenance روی آن اجرا شود می‌تواند Entry Point ایجاد کند.

آیا Cloudflare جلوی هک cPanel را می‌گیرد؟

خیر. CDN/WAF وب الزاماً از Loginهای SSH، FTP یا cPanel محافظت نمی‌کند.

اگر cPanel هک شد اول چه کار کنیم؟

از Device سالم Credentialها را Rotate کنید، 2FA را فعال کنید، دسترسی‌های ناشناس را Revoke کنید، Log و Backup را حفظ کنید، Account را Scan کرده و Root Cause ورود مهاجم را پیدا کنید.

آیا بعد از حذف Malware سایت امن می‌شود؟

نه لزوماً. اگر Vulnerability یا Credential سرقت‌شده‌ای که باعث ورود مهاجم شده همچنان وجود داشته باشد، Infection می‌تواند برگردد.

جمع‌بندی؛ چگونه امنیت هاست و cPanel را افزایش دهیم؟

امنیت هاست و cPanel پایه‌ای است که امنیت Application روی آن قرار می‌گیرد.

اگر حساب Hosting تصاحب شود، مهاجم ممکن است بدون نیاز به Login وردپرس مستقیماً فایل‌ها، Database و Configuration سایت را دست‌کاری کند.

به همین دلیل اولین اولویت، حفاظت از Account اصلی است.

Password cPanel باید طولانی، منحصربه‌فرد و مستقل از Passwordهای دیگر باشد و در Password Manager نگهداری شود. در صورت پشتیبانی Hosting Provider، 2FA نیز باید فعال شود.

در قدم بعدی، SSL/TLS تمام Domainها را بررسی کرده و HTTPS را اجباری کنید. AutoSSL می‌تواند مدیریت Certificate را ساده‌تر کند، اما Errorهای آن باید پیگیری شوند.

ModSecurity یکی دیگر از کنترل‌های مهم است و نباید فقط برای رفع یک Error به‌صورت دائمی Disable شود.

Runtime سایت نیز باید سالم باشد. PHP، WordPress، Pluginها و Theme باید روی نسخه‌های Supported و به‌روز قرار داشته باشند.

در سطح File System، اصل Least Privilege را رعایت کنید. Permissionهایی مانند 777 نباید بدون ضرورت استفاده شوند و Backup یا Configuration File حساس نباید داخل Web Root عمومی رها شود.

تمام Accessهای جانبی را نیز Audit کنید:

• FTP
• SSH
• API Token
• Subaccount
• Cron Job

هر Credential اضافی که دیگر استفاده نمی‌شود باید حذف شود.

برای Recovery نیز Backup مستقل داشته باشید. صرف اینکه Hosting Provider می‌گوید Backup دارد کافی نیست؛ نسخه‌ای خارج از همان Hosting Environment نگه دارید و Restore آن را تست کنید.

Malware Scanner، ModSecurity و Log Monitoring نیز لایه‌های دفاعی مکمل هستند. هیچ‌کدام به‌تنهایی امنیت کامل ایجاد نمی‌کنند.

اگر VPS یا Dedicated Server همراه WHM دارید، مسئولیت شما گسترده‌تر است. در این حالت cPHulk، Firewall، SSH Configuration، Security Advisor، OS Updates، Server Backup و مدیریت Serviceها نیز باید وارد برنامه Hardening شوند.

مهم‌ترین نکته این است که امنیت cPanel را یک تنظیم یک‌باره نبینید.

امنیت یک فرایند دائمی شامل:

Update، Backup، Access Review، Monitoring و Incident Response

است.

یک معماری سالم زمانی شکل می‌گیرد که امنیت Application، Hosting و Server در کنار هم قرار بگیرند:

Password قوی + 2FA
↓
HTTPS
↓
WAF / ModSecurity
↓
Access Control
↓
PHP و Application به‌روز
↓
File Permission امن
↓
Backup مستقل
↓
Malware Detection
↓
Logging & Monitoring
↓
Incident Response

این مدل چندلایه می‌تواند احتمال تبدیل یک اشتباه یا Credential افشاشده به تصاحب کامل سایت را تا حد زیادی کاهش دهد.