امنیت یک سرور Windows RDP دقیقاً به اندازهی روزی است که آن را سختسازی کردهاید — این راهنما شما را از یک سرور تازه تا یک دسکتاپ ریموت آفشور کاملاً قفلشده و قابلاعتماد همراهی میکند.
پروتکل دسکتاپ ریموت (RDP) سریعترین راه برای اجرای یک محیط کامل ویندوز از هر نقطه است، اما در عین حال یکی از سرویسهایی است که بیوقفه در اینترنت اسکن میشود. پیکربندی پیشفرض آن به همان اندازه که راحت است، خطرناک نیز هست.
این راهنما به کار اصلی میپردازد: راهاندازی اولیه Windows RDP، تنظیماتی که واقعاً جلوی حملات brute-force و بهرهبرداری از آسیبپذیریها را میگیرند، و اینکه چگونه کل فرآیند را از همان مرحله تهیه سرور تا استفاده روزانه، آفشور نگه دارید.
چیزی که واقعاً در حال راهاندازی آن هستید
RDP بهصورت پیشفرض در تمام نسخههای Windows Server و Windows Pro وجود دارد. این پروتکل یک دسکتاپ گرافیکی را از طریق پورت TCP 3389 در معرض دید قرار میدهد که تنها با اعتبارنامهها و قوانین شبکهای که پیکربندی میکنید — یا پیکربندی نمیکنید — محافظت میشود.
پروتکل
RDP دسکتاپ و ورودیها را از طریق یک کانال رمزنگاریشده پخش میکند. رمزنگاری بهتنهایی هویت کلاینت را احراز نمیکند — این دقیقاً همان کاری است که NLA انجام میدهد.
ریسک
پورت 3389 بهطور مداوم و انبوه اسکن میشود. یک سرور در معرض دید با رمز عبور ضعیف، در عرض چند ساعت - نه چند هفته - نفوذ میشود.
هدف
سروری که فقط خودتان به آن دسترسی دارید، پیش از بارگذاری دسکتاپ احراز هویت میشود، و به هویت واقعی شما مرتبط نیست.
مرحله ۱ — فعالسازی و پیکربندی صحیح RDP
- 1
فعالسازی Remote Desktop
به مسیر System > Remote Desktop بروید و آن را فعال کنید. یا معادل آن در PowerShell را اجرا کنید: مقدار fDenyTSConnections را در کلید رجیستری Terminal Server برابر با 0 قرار دهید.
- 2
الزامی کردن Network Level Authentication
NLA را فعال کنید تا کلاینتها پیش از ایجاد نشست، مجبور به احراز هویت شوند. همین یک تنظیم بهتنهایی جلوی بخش بزرگی از حملات پیش از احراز هویت را میگیرد.
- 3
ایجاد یک حساب مدیریتی اختصاصی
هرگز RDP را با حساب Administrator داخلی اجرا نکنید. یک حساب با نام مشخص ایجاد کنید، یک عبارت عبور طولانی برای آن تعیین کنید و فقط همین حساب را به گروه Remote Desktop Users اضافه کنید.
- 4
غیرفعال کردن حساب پیشفرض Administrator
نام حساب Administrator داخلی را تغییر دهید یا آن را غیرفعال کنید تا ابزارهای خودکار نتوانند یک نام کاربری شناختهشده را هدف قرار دهند.
NLA باارزشترین تنظیم در این فهرست است. اگر کلاینت شما از NLA پشتیبانی نمیکند، کلاینت را اصلاح کنید — آن را روی سرور غیرفعال نکنید.
مرحله ۲ — قفل کردن مسیر شبکه
بیشتر نفوذها به RDP، حاصل بهرهبرداریهای هوشمندانه نیستند — بلکه حملات مبتنی بر اعتبارنامه علیه پورتی هستند که برای کل اینترنت باز مانده است. ابتدا این میزان در معرض دید بودن را کاهش دهید.
- پورت گوشدهی را از 3389 به پورت دیگری تغییر دهید — این کار جلوی بیشتر اسکنرهای خودکار را میگیرد، هرچند این صرفاً پنهانکاری است، نه امنیت واقعی.
- اگر یک آدرس IP ثابت برای اتصال دارید، قانون RDP در Windows Firewall را به IPهای مبدأ مشخصی محدود کنید.
- بهتر از آن، اصلاً RDP را در معرض اینترنت عمومی قرار ندهید — آن را از طریق یک VPN یا اینترفیس WireGuard تونل کنید و پورت 3389 را فقط برای همان اینترفیس در فایروال باز بگذارید.
- RDP را بهطور کامل روی هر سروری که نیازی به ورود تعاملی ندارد، غیرفعال کنید.
هشدار: تغییر پورت در برابر یک مهاجم هدفمند صرفاً ظاهری است. آن را با فهرستسفید IP یا یک VPN ترکیب کنید — هرگز یک پورت غیراستاندارد را بهعنوان مرز امنیتی در نظر نگیرید.
مرحله ۳ — سختسازی احراز هویت
فرض کنید مهاجمان سرانجام پورت را پیدا خواهند کرد. خط دفاعی بعدی این است که اعتبارنامهها را طوری بسازید که حدس زدنشان بیفایده و brute-force کردنشان دشوار باشد.
عبارات عبور طولانی
از عبارات عبور تصادفی با ۲۰ کاراکتر یا بیشتر استفاده کنید، نه رمزهای عبور بهظاهر هوشمندانه. در برابر روشهای مدرن کرک کردن، طول از پیچیدگی مهمتر است.
سیاست قفل شدن حساب
یک آستانه قفل شدن تنظیم کنید تا تلاشهای ناموفق مکرر، حساب را برای مدتی مسدود کند. این کار حمله brute-force را به مانعی برای پیشرفت خود مهاجم تبدیل میکند.
محدود کردن کاربران RDP
فقط حسابهای موجود در گروه Remote Desktop Users میتوانند وارد شوند. این گروه را تا حد امکان کوچک نگه دارید — در حالت ایدهآل فقط یک حساب.
افزودن یک فاکتور دوم
در جایی که روند کاریتان اجازه میدهد، یک راهکار MFA یا گیتوی/گواهی را جلوی RDP قرار دهید. رمز عبور بهتنهایی یک نقطهی شکست منفرد است.
مرحله ۴ — بهروزرسانی، ثبت رویداد و پایش
RDP سابقهای از آسیبپذیریهای جدی پیش از احراز هویت دارد. سروری که پچ نشده، صرفنظر از قدرت رمز عبورتان، قابل بهرهبرداری است.
- Windows Update را همیشه بهروز نگه دارید — بدترین آسیبپذیریهای (CVE) RDP قابلیت انتشار خودکار (wormable) داشتند و مدتها پیش از سوءاستفاده گسترده، پچ شدند.
- ممیزی رویدادهای ورود (logon) را فعال کنید تا بتوانید ورودهای ناموفق و موفق را در Security event log مشاهده کنید.
- بهطور دورهای Event ID 4625 (ورودهای ناموفق) و 4624 (ورودهای موفق) را بررسی کنید — افزایش ناگهانی در 4625 یعنی سرور شما در حال پروب شدن است.
- از ابزاری استفاده کنید که پس از تلاشهای ناموفق مکرر، IPها را بهطور خودکار مسدود میکند تا کمپینهای brute-force مداوم را خنثی کنید.
آفشور کردن سرور
سختسازی از سرور محافظت میکند. حریم خصوصی از شما محافظت میکند. این دو، مسائل جداگانهای هستند و بیشتر آموزشهای RDP مورد دوم را بهکلی نادیده میگیرند.
حریم خصوصی از لحظهی تهیه سرور آغاز میشود
حریم خصوصی چیزی نیست که بتوانید بعداً به سرور اضافه کنید. اگر سرور با نام واقعی، ایمیل و کارت شما سفارش داده شده باشد، سرور از نظر فنی سختسازی شده اما از نظر هویتی در معرض دید است. ردپای هویتی شما درست در لحظهی پرداخت شکل میگیرد.
- سرور را از میزبانی تهیه کنید که برای راهاندازی سرور نیازی به KYC یا تأیید هویت شخصی ندارد.
- بهجای کارتی که به نام شماست، از یک موجودی پیشپرداخت رمزارزی پرداخت کنید — بهویژه Monero که هیچ ردی در دفتر کل عمومی باقی نمیگذارد.
- برای این حساب از یک ایمیل مستعار اختصاصی استفاده کنید، نه صندوق ورودی اصلی خود.
- به سرور نهایی از طریق یک VPN یا مسیری سازگار با Tor متصل شوید تا IP واقعی شما هرگز مستقیماً با پورت 3389 در تماس نباشد.
این دقیقاً همان مدلی است که ChainVPS بر پایهی آن ساخته شده. سرورهای RDP آفشور ما بدون KYC تهیه میشوند و از موجودی پیشپرداخت رمزارزی در میان 21 ارز از جمله Monero پرداخت میشوند، بنابراین دستگاه هرگز به یک هویت واقعی مرتبط نمیشود — برای مشاهدهی پیکربندیهای فعلی ویندوز به صفحهی /offshore-rdp مراجعه کنید.
نکتهی کلیدی: یک سرور RDP امن که با هویت واقعی شما سفارش داده شده، همچنان یک ریسک برای حریم خصوصی است. حریم خصوصی یک تصمیم در مرحلهی تهیه سرور است، نه یک گزینه که بعد از راهاندازی تیک بزنید.
انتخاب محل استقرار سرور
برای یک پیکربندی مبتنی بر حریم خصوصی، حوزهی قضایی به همان اندازهی پیکربندی فنی اهمیت دارد. سروری که در مکانی با حفاظت قوی از دادهها و بدون افراط در نگهداری داده قرار دارد، بهمراتب سختتر میتوان مجبورش کرد اطلاعات را افشا کند.
انتخاب یک منطقهی دارای سطح حریم خصوصی بالا مانند سوئیس یا ایسلند، سختسازی فنی بالا را با یک محیط قانونی که به آن احترام میگذارد، همراه میکند. برای بارهای کاری تعاملی سنگینتر، همین مدل آفشور به سرورهای اختصاصی (dedicated) و GPU ما نیز گسترش مییابد.
یک چکلیست فشرده پیش از راهاندازی
- NLA فعال و الزامی شده باشد.
- حساب Administrator داخلی غیرفعال شده باشد؛ فقط یک حساب با نام مشخص در گروه Remote Desktop Users باشد.
- RDP در معرض اینترنت باز نباشد — از VPN، فهرستسفید IP، یا هر دو استفاده شود.
- یک عبارت عبور تصادفی طولانی به همراه سیاست قفل شدن حساب.
- ویندوز کاملاً پچ شده و ممیزی ورود (logon auditing) فعال باشد.
- سرور بدون KYC تهیه شده و از موجودی پیشپرداخت رمزارزی پرداخت شده باشد.
آیا تغییر پورت RDP از 3389 برای ایمنسازی آن کافی است؟
خیر. این کار شما را از دید اسکنرهای بیهدف پنهان میکند اما در برابر مهاجمی هدفمند که همهی پورتها را اسکن میکند، کاری از پیش نمیبرد. آن را صرفاً کاهش نویز در نظر بگیرید و آن را با NLA، محدودیتهای IP یا یک VPN، و سیاست قوی قفل شدن حساب ترکیب کنید.
Network Level Authentication چیست و چرا اهمیت دارد؟
NLA کلاینت را مجبور میکند پیش از ایجاد نشست دسکتاپ توسط ویندوز، احراز هویت شود. این کار جلوی طیف گستردهای از حملات پیش از احراز هویت را میگیرد و منابعی را که مهاجم میتواند مصرف کند کاهش میدهد؛ به همین دلیل هرگز نباید آن را غیرفعال کرد.
آیا یک سرور RDP واقعاً میتواند آفشور باشد؟
بله، اما فقط در صورتی که حریم خصوصی از همان مرحلهی تهیه سرور در نظر گرفته شده باشد. از یک میزبان بدون KYC سفارش دهید، از موجودی پیشپرداخت رمزارزی مانند Monero پرداخت کنید، از یک ایمیل مستعار استفاده کنید و از طریق VPN متصل شوید تا IP واقعی شما هرگز با سرور در تماس نباشد.
برای یک سرور RDP خصوصی چه مکانی را انتخاب کنم؟
یک حوزهی قضایی با سطح حریم خصوصی بالا و حفاظت قوی از دادهها — ChainVPS در میان 15 مکان خود، NL، CH، RO، IS، MD و LU را ارائه میدهد. ترکیب یک محیط قانونی قوی با مراحل سختسازی بالا، بهترین وضعیت کلی را برایتان فراهم میکند.
