پاسخ کوتاه
چگونه حساب ثبت‌کننده خود را از تصرف محافظت می‌کنید؟
یک حساب ثبت‌کننده را با یک گذرواژه تصادفی طولانی که هیچ‌جای دیگری استفاده نمی‌شود، احراز هویت دو مرحله‌ای، تا جای ممکن کاربر کم، و یک مسیر بازیابی که یک تماس پشتیبانی نمی‌تواند از آن رد شود محافظت کنید. Wardmint در جدولش دو حادثه را شمرده، در جولای 2024 و فوریه 2026، که نقطه ضعف آن ورود یا جریان پشتیبانی یک ثبت‌کننده یا پلتفرم بود، نه رکوردهای DNS.
کنترل‌های حساب و حادثه‌ای که هرکدام پاسخ می‌دهد
| کنترل | چه چیزی را جلوگیری می‌کند | مورد عمومی که پاسخ می‌دهد |
|---|---|---|
| حساب هر دامنه منتقل‌شده را خودتان مطالبه کنید | مهاجم پیش از شما حساب را بسازد | مهاجرت‌های Squarespace، 9 تا 12 جولای 2024 (ضعف OAuth) |
| قاعده تماس پشتیبانی: بدون تغییر با درخواست صوتی | مهندسی اجتماعی یک کارشناس پشتیبانی | Avantis، فوریه 2026 (حساب پس از یک تماس پشتیبانی تصرف شد) |
| احراز هویت دو مرحله‌ای روی حساب | ورود با گذرواژه دزدیده‌شده | توصیه Name.com پس از تغییر مسیر 30 تا 31 اکتبر 2026 |
| گذرواژه یکتا و طولانی در یک گاوصندوق | استفاده مجدد از اعتبارنامه و حدس زدن | رویه عمومی |
| کاربران نام‌برده‌شده کم، و حذف هنگام ترک | دسترسی داخلی و عضو سابق | گردش مشارکت‌کنندگان و DAO |
| نشانی ورود نشانک‌گذاری‌شده | فیشینگ ورود به ثبت‌کننده | رویه عمومی |
چرا حساب ثبت‌کننده هدف است؟
چون می‌تواند سرورهای نام، رکورد DS و مالک را تغییر دهد، و هیچ کدی روی زنجیره شما نمی‌تواند آن را لغو کند. مهاجمی که با نام شما وارد شود می‌تواند دامنه را به هر جا که بخواهد هدایت کند و سپس برای مقصد جدید گواهی درخواست کند.
سابقه عمومی این الگو را نشان می‌دهد. Krebs on Security در جولای 2024 گزارش داد دامنه‌هایی که از Google Domains به Squarespace منتقل شده بودند در معرض مهاجمی بودند که پیش از صاحب دامنه، حسابی با ایمیل مرتبط با دامنه ساخته بود، و Squarespace این را به ضعفی در ورود OAuth نسبت داد. Blockaid در فوریه 2026 نوشت که Avantis از طریق یک حساب Squarespace که پس از استخراج اطلاعات صورتحساب در یک تماس پشتیبانی تصرف شده بود، سازش یافت. در 30 و 31 اکتبر 2026، دامنه‌های حدود دوازده سایت DeFi که نزد یک ثبت‌کننده ثبت شده بودند تغییر مسیر یافتند؛ ثبت‌کننده آن‌ها را بازگرداند و بررسی DNS و احراز هویت دو مرحله‌ای را توصیه کرد.
بر اساس شمارش Wardmint در 12 نوامبر 2026، دو مورد از هفت حادثه جدول آن (موج جولای 2024 و مورد Avantis در فوریه 2026) بر یک ورود یا جریان پشتیبانی در یک ثبت‌کننده یا پلتفرم محورند. مجموعه کامل در کدام پروژه‌های کریپتو به دلیل ربودن DNS کاربران خود را از دست دادند است.
چه تنظیم گذرواژه و ورودی باید استفاده کنید؟
یک گذرواژه تصادفی با حداقل 20 نویسه، که مدیر گذرواژه تولید و نگه می‌دارد، استفاده کنید و هرگز آن را دوباره به کار نبرید. یک پیام گفتگوی مشترک یا یک صفحه‌گسترده گاوصندوق نیست. اگر بیش از یک نفر به دسترسی نیاز دارد، از یک گاوصندوق تیمی با ردیابی ممیزی استفاده کنید، و ثبت کنید چه کسی آن راز را دیده است.
برای حساب، احراز هویت دو مرحله‌ای را روشن کنید. یک کلید امنیتی سخت‌افزاری قوی‌ترین عامل دوم رایج است، زیرا کدی به یک صفحه فیشینگ نمی‌دهد. یک برنامه احراز هویت گزینه بعدی است؛ کدی که با پیامک فرستاده می‌شود ضعیف‌ترین است. کدهای بازیابی را آفلاین، در دو جا نگه دارید، و بنویسید چه کسی به آن‌ها دسترسی دارد.
در Wardmint با شماره حساب و گذرواژه وارد می‌شوید، و می‌توانید احراز هویت دو مرحله‌ای را در ناحیه کاربری روشن کنید؛ پاسخ ایمیلی در کمتر از 12 ساعت، هفت روز هفته، از جمله کمک برای DNSSEC، رکوردهای CAA و گزارش‌های سوءاستفاده. از آنجا که برای خود ثبت فقط یک ایمیل تأییدشده برای هر دامنه لازم است، ایمیل حساب را روی صندوقی نگه دارید که کنترل می‌کنید، و آن صندوق را دقیقاً به همان اندازه حساب محافظت کنید.
چه کسی باید دسترسی داشته باشد، و با تماس پشتیبانی چگونه برخورد می‌کنید؟
یک مالک و یک پشتیبان نام ببرید، هر دو را مستند کنید، و قاعده‌ای بنویسید که هیچ تغییری بر اساس یک تماس انجام نشود. پرونده Avantis دلیلش را نشان می‌دهد. اگر پشتیبانی بتواند پس از یک مکالمه تلفنی حساب را تغییر دهد، آنگاه قدرت گذرواژه شما دیگر اهمیتی ندارد.
برای یک DAO یا بنیاد، پیش از وقت تعیین کنید چه کسی اعتبارنامه‌ها را دارد، خزانه چگونه موجودی را شارژ می‌کند، و دسترسی وقتی یک مشارکت‌کننده می‌رود چگونه تغییر می‌کند. رویه‌های نگهداری مشترک در چگونه یک DAO باید دامنه‌هایش را نگه دارد و پرداخت کند آمده‌اند. وقتی کسی تیم را ترک می‌کند، دسترسی‌اش را در همان روز بردارید، و گذرواژه مشترک را همان موقع عوض کنید.
برای مهم‌ترین دامنه‌ها، حفاظت از دامنه را به مبلغ +$ 29 در سال برای هر دامنه در نظر بگیرید: دامنه به نام DomaineGoat LLC ثبت می‌شود، شما ذی‌نفع می‌مانید با بازگرداندن رایگان به نام خودتان، قفل انتقال روشن است، و هر شکایت پیش از هر اقدامی را یک انسان می‌خواند. این گزینه در حفاظت از دامنه چیست شرح داده شده است. این گزینه آنچه حساب نگه می‌دارد را کم می‌کند، اما جایگزین ورود قوی نمی‌شود.
چگونه حساب ثبت‌کننده را در هفت مرحله محافظت کنیم
همه حساب‌ها و دامنه‌ها را فهرست کنید
هر حساب ثبت‌کننده، دامنه‌های داخل آن و افرادی را که می‌توانند وارد شوند فهرست کنید. حساب‌هایی را که از انتقال‌ها به ارث رسیده‌اند هم بیاورید.
حساب‌های منتقل‌شده را مطالبه کنید
اگر یک ثبت‌کننده حساب قدیمی شما را جذب کرده، وارد شوید و تأیید کنید که شما، نه یک غریبه، برای هر دامنه مالک حساب هستید.
گذرواژه را عوض کنید
یک گذرواژه تصادفی با 20 نویسه یا بیشتر در یک گاوصندوق تولید کنید و فقط برای همین حساب به کار ببرید.
احراز هویت دو مرحله‌ای را روشن کنید
کلید سخت‌افزاری را ترجیح دهید، سپس یک برنامه احراز هویت. کدهای بازیابی را آفلاین، در دو جا نگه دارید.
دسترسی را کاهش دهید و ثبت کنید
یک مالک و یک پشتیبان نام ببرید، بقیه را حذف کنید، و تاریخ و دلیل هر تغییر را یادداشت کنید.
قاعده تماس پشتیبانی را بنویسید
توافق کنید که هیچ کس DNS، مالک یا تماس‌ها را بر اساس یک تماس یا گفتگو تغییر ندهد، و این را به تیمتان بگویید.
ورود را نشانک کنید و مراقب فیشینگ باشید
ثبت‌کننده را فقط از نشانکتان باز کنید. هر ایمیلی که از شما می‌خواهد به ثبت‌کننده وارد شوید را یک تلاش احتمالی فیشینگ بدانید.
چگونه یک صفحه فیشینگ را که ثبت‌کننده شما را کپی می‌کند تشخیص می‌دهید؟
پیش از تایپ هر چیزی نشانی را بررسی کنید، و هرگز یک لینک ورود را از یک ایمیل دنبال نکنید. فیشینگ ثبت‌کننده بر فوریت تکیه دارد: پیامی می‌گوید دامنه به‌زودی منقضی می‌شود یا شکایتی دارد. ثبت‌کننده را از نشانکتان باز کنید و همان اعلان را در حساب جستجو کنید.
از یک مدیر گذرواژه استفاده کنید که اعتبارنامه‌ها را فقط روی نشانی دقیق ذخیره‌شده پر می‌کند، تا یک صفحه ورود شبیه هیچ چیزی دریافت نکند. کلیدهای سخت‌افزاری همان محافظت را برای عامل دوم فراهم می‌کنند. اگر هرگاه گذرواژه‌ای را در یک صفحه مشکوک وارد کردید، فوراً آن را عوض کنید، همه نشست‌ها را پایان دهید، و رکوردهای DNS و ایمیل تماس را بررسی کنید.
لایه دوم انقضاست. دامنه‌ای که منقضی شود را هر کسی می‌تواند بگیرد، و وظیفه تمدید در چگونه جلوی منقضی شدن دامنه‌هایتان را بگیرید پوشش داده شده است. برنامه سخت‌سازی گسترده‌تر در چگونه دامنه خود را در برابر ربودن DNS ایمن کنیم است.
پرسش‌ها درباره امنیت حساب ثبت‌کننده
آیا احراز هویت دو مرحله‌ای کافی است؟
لازم است، اما به‌تنهایی کافی نیست. پرونده Avantis از طریق یک تماس پشتیبانی گذشت. یک قاعده «بدون تغییر با تماس» و کاربران کم اضافه کنید.
آیا قفل انتقال از حساب محافظت می‌کند؟
خیر. جلوی انتقال به ثبت‌کننده دیگر را می‌گیرد. اینکه کسی با ورود سرورهای نام یا رکوردها را تغییر دهد را متوقف نمی‌کند.
آیا حساب باید از یک ایمیل مشترک تیمی استفاده کند؟
از یک صندوق ایمیل که تیم کنترل می‌کند و با احراز هویت دو مرحله‌ای محافظت شده استفاده کنید، نه یک نشانی شخصی یکی از اعضا. هر دامنه همچنین برای ثبتش به یک ایمیل تأییدشده نیاز دارد.
اگر یک مشارکت‌کننده دارای دسترسی برود چه؟
گذرواژه را عوض کنید، دسترسی‌اش را بردارید، کدهای بازیابی را بچرخانید و رکوردهای DNS را بررسی کنید، همه در همان روز.
آیا حفاظت از دامنه می‌تواند جایگزین ورود قوی شود؟
خیر. دامنه را به نام شرکت قرار می‌دهد و بررسی انسانی شکایت‌ها را اضافه می‌کند، اما حساب همچنان به ورود قوی نیاز دارد.
خلاصه
- حساب ثبت‌کننده می‌تواند سرورهای نام، رکوردهای DS و مالک را تغییر دهد.
- ربودن‌های عمومی 2024 و 2026 از طریق ضعف ورود یا یک تماس پشتیبانی رخ دادند.
- یک گذرواژه تصادفی با 20 نویسه یا بیشتر، در یک گاوصندوق، که هیچ‌جای دیگر استفاده نشود.
- احراز هویت دو مرحله‌ای را روشن کنید، ترجیحاً با کلید سخت‌افزاری.
- یک مالک و یک پشتیبان نام ببرید؛ افراد خارج‌شده را در همان روز حذف کنید.
- قاعده‌ای بنویسید که هیچ تغییری فقط بر اساس یک تماس انجام نشود.
- حفاظت از دامنه +$ 29 در سال هزینه دارد و جایگزین یک ورود قوی نمی‌شود.
منابع (3)
- پژوهشگران: پیش‌فرض‌های امنیتی ضعیف، ربوده شدن دامنه‌های Squarespace را ممکن کرد — Krebs on Security (خوانده‌شده 2026-11-12)
- ربودن رابط کاربری و سطح حمله Web2 که پروتکل‌های Web3 را تهدید می‌کند — Blockaid (خوانده‌شده 2026-11-12)
- هکرها دوازده وب‌سایت DeFi را که نزد Name.com ثبت شده بودند می‌ربایند — The Block (خوانده‌شده 2026-11-12)