چکلیست حریم خصوصی سلفهاستینگ
Guides · 9 دقیقه مطالعه
چرا یک چکلیست از یک راهاندازی یکباره بهتر است
بیشتر شکستهای حریم خصوصی سلفهاستینگ نمایشی نیستند. آنها شکافهای کوچک و انباشتهاند: فایل لاگی که بهآرامی آدرسهای IP را برای ماهها نگه میدارد، پورت پیشفرض SSHای که چون چرخاندنش غیرضروری بهنظر میرسیده باز مانده، یک نسخه پشتیبان که رمزنگارینشده روی یک لپتاپ ذخیره شده، رکورد WHOISای که هنوز به یک نام واقعی اشاره میکند. هیچکدام بهتنهایی فوری بهنظر نمیرسند، و دقیقاً به همین دلیل باقی میمانند.
یک چکلیست کار میکند چون حریم خصوصی را بهعنوان ویژگیای مداوم از یک سیستم میبیند، نه یک گام پیکربندی یکباره. سرورها منحرف میشوند. بستهها نصب میشوند، پورتها برای یک تست سریع باز میشوند و هیچوقت بسته نمیشوند، و سرویسی که فراموشش کردهاید شروع به نوشتن لاگهای پرحرف میکند. مرور دوباره همان لیست ماهانه یا بعد از هر تغییر، این انحراف را پیش از تبدیلشدن به معرضبودن میگیرد.
- با سختکردن حریم خصوصی مثل نگهداری رفتار کنید، نه یک وظیفه روز راهاندازی
- بعد از هر سرویس، بسته یا تغییر پیکربندی جدید، لیست را دوباره بررسی کنید
- فرض کنید تنظیمات پیشفرض بازند تا زمانی که خلافش را تأیید کنید
لایه یک: چه کسی میتواند حساب را ردیابی کند
پیش از دستزدن به یک ترمینال، خود حساب اغلب ضعیفترین حلقه است. یک VPS با استانداردهای نظامی همچنان قابلردیابی است اگر ثبتنام از یک ایمیل واقعی، صورتحساب کارت، یا اسکن مدرک هویتی استفاده کرده باشد. این لایه درباره شکستن زنجیره میان یک روش پرداخت و یک سرور است، پیش از آنکه هر سختکردن فنیای حتی آغاز شود.
روندهای ثبتنام ناشناس دقیقاً به همین دلیل وجود دارند. VPS GOAT، برای نمونه، در زمان ثبتنام تنها یک کلید حساب هششده صادر میکند بهجای جمعآوری ایمیل یا مدرک هویتی، دقیقاً به همان الگوی سبک Mullvad که ارائهدهندگان VPN حریمخصوصیمحور استفاده میکنند، و پرداخت را تنها از طریق Paymento و با ارز دیجیتال تسویه میکند، با توصیه مونرو بهخاطر حریم خصوصی سطحتراکنشش، در کنار بیتکوین، USDT، لایتکوین، اتریوم و ترون. هر ارائهدهندهای که استفاده میکنید، همان پرسشها را بپرسید: ثبتنام چه داده شناساییکنندهای جمع میکند، پرداخت چه چیزی را فاش میکند، و اگر ارائهدهنده مجبور به افشا شود، آن داده چه سرنوشتی پیدا میکند.
- از یک کلید حساب ناشناس یا ایمیل شبهناشناس استفاده کنید، هرگز از ایمیلی مرتبط با هویت واقعی خود
- با یک ارز دیجیتال حریمخصوصیمحور پرداخت کنید، نه با کارتی که به نامتان است
- از استفاده مجدد یک نامکاربری، کلید PGP یا اثرانگشت کلید SSH میان یک پروژه ناشناس و یک پروژه شخصی خودداری کنید
- پیش از ثبتنام، نه بعد از آن، بررسی کنید فرایند ایجاد حساب ارائهدهنده واقعاً چه چیزی ذخیره میکند
لایه دو: چطور یک VPS را در سطح سیستمعامل امن کنیم
وقتی حساب پاک باشد، لایه بعدی خود سیستمعامل است. امنسازی یک VPS با حذف هر مسیر دسترسیای که صراحتاً به آن نیاز ندارید شروع میشود، سپس با قفلکردن آنهایی که نگه میدارید ادامه مییابد. این همان بخشی از چکلیست است که مستقیمترین تأثیر را در تعیین اینکه آیا یک اسکنر فرصتطلب میتواند پایگاهی به دست بیاورد دارد.
SSH اولین هدف تقریباً هر حمله خودکار علیه یک VPS تازه است، پس بیشترین توجه را میطلبد. احراز هویت با رمز عبور را کاملاً غیرفعال کنید و به جفتکلیدها متکی شوید، ترجیحاً کلیدهای Ed25519 که بهصورت محلی تولید شدهاند و هرگز جایی آپلود نشدهاند. SSH را از پورت ۲۲ فقط بهعنوان یک کاهنده جزئی نویز جابهجا کنید، نه یک کنترل امنیتی واقعی، و آن را با fail2ban یا ابزاری مشابه برای کندکردن خودکار تلاشهای بروتفورس همراه کنید.
- ورود روت از طریق SSH و احراز هویت رمز عبور را غیرفعال کنید، فقط دسترسی مبتنی بر کلید
- یک فایروال (ufw، nftables یا iptables) با سیاست پیشفرض رد ورودی و قوانین مجاز صریح اعمال کنید
- fail2ban یا crowdsec را نصب کنید تا تلاشهای مکرر ناموفق ورود را خودکار مسدود کند
- بهروزرسانیهای امنیتی را طبق برنامه اعمال کنید؛ unattended-upgrades برای Debian و Ubuntu این کار را خودکار انجام میدهد
- برای مدیریت روزانه یک کاربر sudo غیرروت بسازید و روت را برای موارد استثنایی نگه دارید
- سرویسهای بلااستفاده را غیرفعال کنید و هر پورتی که به سرویسی که فعال اجرایش میکنید مرتبط نیست را ببندید
لایه سه: سختکردن سرور برای حریم خصوصی، نه فقط امنیت
امنیت و حریم خصوصی همپوشانی دارند اما یکسان نیستند. یک سرور میتواند نفوذ به آن سخت باشد و در همان حال آدرس IP هر بازدیدکننده را برای یک سال بهصورت متن ساده لاگ کند، که یک شکست حریم خصوصی است حتی اگر یک نفوذ امنیتی نباشد. سختکردن یک سرور برای حریم خصوصی یعنی کاهش فعالانه آنچه ثبت و نگهداری میکند، علاوه بر خط مبنای امنیتی استاندارد.
رمزنگاری کامل دیسک (LUKS در لینوکس) در صورت توقیف یک درایو فیزیکی یا کپیشدن غیرمجاز یک اسنپشات، از داده در حالت سکون محافظت میکند؛ پلنهای VPS GOAT بهطور پیشفرض روی NVMe رمزنگاریشده در سطح زیرساخت اجرا میشوند، که لایه سختافزار را پوشش میدهد، اما رمزنگاری دیسک خودتان و انضباط لاگگیری در سطح اپلیکیشن همچنان برای آنچه در سیستمعامل مهمان کنترل میکنید، اهمیت دارد. فراتر از رمزنگاری، رفتار لاگگیری پیشفرض هر سرویس را بازبینی کنید: وبسرورها، سرورهای ایمیل، و حتی تاریخچه شل میتوانند آدرس IP، مهر زمانی و رشتههای کوئری را بسیار بیشتر از نیاز واقعی نگه دارند.
همگامسازی زمان و انتخاب DNS هم اهمیت دارند. سروری با منطقه زمانی نادرست یا یک ریزالور DNS که هر جستجو را تا زیرساخت شما لاگ میکند، ردپای متادیتایی میسازد که چون در استفاده روزمره نامرئی است، بهآسانی نادیده گرفته میشود.
- داده در حالت سکون را با LUKS یا رمزنگاری کامل دیسک معادل، درون سیستمعامل مهمان رمزنگاری کنید
- لاگهای دسترسی پرحرف را در nginx، Apache و سرورهای اپلیکیشن، جایی که نگهداری لازم نیست، کوتاه یا غیرفعال کنید
- لاگها را بهجای انباشتن نامحدود، بهشدت چرخش و منقضی کنید (logrotate با نگهداری کوتاه)
- بهجای DNS پیشفرض ISP دسترسیتان، از یک ریزالور DNS حریمخصوصیمحور روی DNS-over-TLS یا DNS-over-HTTPS استفاده کنید
- تاریخچه شل را از دستورهای حساس پاک کنید و برای اسکریپتهای خودکاری که به رمزهای مخفی دسترسی دارند، تاریخچه bash را غیرفعال کنید
- NTP را روی یک منبع زمانی خنثی تنظیم کنید، نه چیزی مرتبط با موقعیت فیزیکی شما
بکاپها، اسنپشاتها و دام بازیابی
بکاپها همان جایی هستند که سختکردن حریم خصوصی اغلب بهآرامی میشکند. یک سرور زنده کاملاً سختشده اگر اسنپشات شبانهاش رمزنگارینشده روی یک باکت ذخیرهسازی شخصثالث بنشیند، یا اگر ویژگی اسنپشات خودکار یک ارائهدهنده یک تصویر کامل دیسک را جایی خارج از کنترل شما ذخیره کند، معنای چندانی ندارد.
راهحل رفتار با رمزنگاری بکاپ با همان جدیت دیسک زنده است. آرشیوهای بکاپ را پیش از خروج از سرور، سمت کلاینت رمزنگاری کنید، با ابزاری مثل restic یا borg و یک عبارتعبور قوی که آفلاین ذخیره شده، طوری که حتی اگر مقصد بکاپ لو برود، داده درونش غیرقابلخواندن بماند. اگر ارائهدهنده شما اسنپشات داخلی ارائه میدهد، بفهمید کجا ذخیره میشوند و آیا همان رمزنگاری حجم مبدأ را به ارث میبرند.
- بکاپها را پیش از آپلود، سمت کلاینت رمزنگاری کنید، نه فقط در مقصد ذخیرهسازی
- بازیابیها را بهطور دورهای تست کنید؛ یک بکاپ تستنشده یک امید است، نه یک برنامه
- بررسی کنید آیا اسنپشاتهای مدیریتشده توسط ارائهدهنده رمزنگاریشدهاند و فیزیکاً کجا ذخیره میشوند
- حداقل یک نسخه بکاپ را خارج از همان حوزه قضایی سرور زنده نگه دارید
نشتیهای لایه اپلیکیشن که باید آخر بررسی شوند
با پوششدادن حساب، سیستمعامل و بکاپها، لایه آخر اپلیکیشنهایی است که واقعاً اجرا میکنید. اینجاست که سختکردن حریم خصوصی بهصورت مخصوص هر اپلیکیشن درمیآید: یک سرور ایمیل سلفهاستشده، یک وبلاگ ایستا، و یک سرویس مخفی Tor هرکدام سطح نشتی متفاوتی دارند، اما چند بررسی تقریباً جهانیاند.
متادیتا رایجترین سهو است. فایلهای آپلودشده میتوانند داده EXIF، فیلدهای مؤلف سند، یا مهرهای زمانی افشاکننده منطقه زمانی حمل کنند. اپلیکیشنهای وب میتوانند هدرهای سرور، نسخههای نرمافزار، یا صفحات خطای پرجزئیات را افشا کنند که نقشه راهی به مهاجم میدهند. هیچکدام از اینها برای رفعکردن عجیبوغریب نیستند، اما هر مورد باید صریحاً بررسی شود چون پیشفرضها بهندرت آن را برایتان پنهان میکنند.
- پیش از انتشار هر فایل یا تصویر، EXIF و متادیتا را از آن حذف کنید
- هدرهای پرجزئیات سرور (Server، X-Powered-By) را سرکوب کنید و صفحات خطای مفصل را در محیط تولید غیرفعال کنید
- هر فرم تماس یا سیستم نظردهی را برای لاگگیری IPای که قصد فعالکردنش را نداشتهاید بررسی کنید
- اگر در کنار یک سایت clearnet یک سرویس مخفی Tor هم ارائه میدهید، مطمئن شوید این دو داراییهای شناساییکننده مثل گواهیهای TLS یا اسکریپتهای آنالیتیکس را مشترک ندارند
| لایه | چه چیزی را بررسی کنیم | ابزار یا تنظیم رایج |
|---|---|---|
| حساب | هویت ثبتنام، ردپای پرداخت | کلید حساب ناشناس، مونرو از طریق Paymento |
| دسترسی | معرضبودن SSH، ریسک بروتفورس | SSH فقط با کلید، fail2ban، فایروال با رد پیشفرض |
| ذخیرهسازی | داده در حالت سکون در صورت کپیشدن دیسک یا اسنپشات | رمزنگاری کامل دیسک LUKS، NVMe رمزنگاریشده |
| لاگها | نگهداری IPها و مهرهای زمانی | نگهداری کوتاه logrotate، لاگهای دسترسی حداقلی |
| بکاپها | معرضبودن در صورت نفوذ به مقصد بکاپ | رمزنگاری سمت کلاینت با restic یا borg |
| اپلیکیشنها | نشتی متادیتا و هدر | حذف EXIF، هدرهای سرور سرکوبشده |
سوالات متداول
مهمترین گام برای امنسازی یک VPS برای حریم خصوصی چیست؟+
اگر ارائهدهنده از قبل ذخیرهسازی را رمزنگاری کرده، آیا رمزنگاری کامل دیسک لازم است؟+
چکلیست حریم خصوصی سلفهاستینگ را چند وقت یکبار باید مرور کنم؟+
آیا سختکردن سرور برای حریم خصوصی آن را کند میکند؟+
آیا میتوانم این چکلیست را روی هر ارائهدهنده VPS اجرا کنم، یا فقط یک ارائهدهنده حریمخصوصیمحور؟+
آماده رفتن به آفشور هستید؟
بدون KYC، بدون ایمیل — فقط یک کلید ناشناس و رمزارز. راهاندازی در ~55 ثانیه.
VPS خود را پیکربندی کنید →