سرور مجازی
دسته بندی:
RBL چیست؟
RBL که سرنام Real Time Black Hole List است، فهرستی بلادرنگ از آدرسهای IP است که به دلیل ارسال اسپم یا پیکربندی ناامن علامتگذاری شدهاند. سرور ایمیل گیرنده در همان لحظهای که یک اتصال SMTP برقرار میشود، IP فرستنده را با این فهرستها مقایسه میکند و اگر تطابقی پیدا شود، ایمیل را رد میکند یا به پوشه اسپم میفرستد.
در متون فنی امروز بیشتر عبارت DNSBL (سرنام DNS-based Blocklist) به کار میرود، چون این فهرستها روی بستر DNS منتشر میشوند. RBL نام نخستین سرویس از این خانواده بود و بهمرور به نام عمومی همه آنها تبدیل شد. کارکرد هر دو یکسان است: نگهداری فهرستی از منابع تاییدشده اسپم و open relayها، یعنی سرورهایی که بدون احراز هویت، ایمیل دیگران را بازارسال میکنند.
RBL دقیقا چگونه کار میکند؟
سازوکار آن چیزی جز یک پرسوجوی ساده DNS نیست. فرض کنید سروری با IP 203.0.113.25 به سرور ایمیل شما وصل میشود. سرور ایمیل ترتیب اوکتتها را معکوس میکند، نام دامنه فهرست را به انتهای آن میچسباند و یک رکورد A میپرسد:
بررسی RBL پیش از دیده شدن محتوای نامه انجام میشود؛ به همین دلیل تا وقتی آدرس IP از فهرست خارج نشود، هیچ تغییری در متن ایمیل وضعیت را عوض نمیکند.
dig +short 25.113.0.203.zen.spamhaus.orgاگر هیچ پاسخی برنگردد، آن IP در آن فهرست نیست. اگر آدرسی در محدوده 127.0.0.0/8 برگردد یعنی IP فهرست شده است و آخرین اوکتت نشان میدهد به کدام زیرفهرست تعلق دارد؛ هر سرویس جدول رمزگشایی این کدها را در مستندات خودش منتشر میکند و کدها بین سرویسها یکسان نیستند. توضیح دلیل فهرست شدن هم معمولا در رکورد TXT همان نام قرار دارد:
dig +short TXT 25.113.0.203.zen.spamhaus.orgچون کل این تبادل روی DNS انجام میشود، سرور گیرنده میتواند پیش از دریافت بدنه پیام تصمیم بگیرد و همین، بار پردازشی فیلترهای محتوایی را بهشدت کم میکند. ساختار کلی این پرسوجوها در RFC 5782 استاندارد شده است.
چرا IP یک سرور فهرست میشود؟
- اسکریپت آلوده روی سایت: یک افزونه قدیمی یا وبشل آپلودشده میتواند بدون اطلاع شما هزاران ایمیل در ساعت بفرستد. این شایعترین دلیل در سرورهای وب است؛ روش پیدا کردن چنین فایلهایی را در پاکسازی شل و صفحه جعلی روی هاست آوردهایم.
- open relay بودن سرور ایمیل: اگر سرور شما ایمیل کاربران ناشناس را بدون احراز هویت بازارسال کند، خیلی زود پیدا و فهرست میشود.
- حساب ایمیل لو رفته: یک رمز ضعیف روی وبمیل کافی است تا مهاجم از طریق SMTP معتبر شما اسپم بفرستد.
- دام اسپم و شکایت گیرنده: بعضی آدرسها فقط برای شکار اسپمر ساخته شدهاند و ارسال به فهرستهای خریداریشده برخورد با آنها را تقریبا قطعی میکند. نرخ بالای علامتگذاری «این اسپم است» هم همین اثر را دارد.
- فهرستهای مبتنی بر سیاست: بخشی از سرویسها کل محدودههای IP خانگی و پویا را از پیش علامت میزنند؛ اینجا تخلفی رخ نداده و نوع IP مسئله است.
- سابقه همسایه: روی هاست اشتراکی، IP خروجی بین چندین سایت مشترک است و رفتار یکی بقیه را هم درگیر میکند.
اگر ارسال ایمیل برای کسبوکارتان حیاتی است، جدا کردن آن از IP مشترک منطقی است. روی یک سرور مجازی با دسترسی روت کامل اعتبار IP خروجی فقط به رفتار خود شما بستگی دارد.
چطور وضعیت IP را بررسی کنیم؟
سادهترین راه همان دستور dig بالا برای هر فهرست موردنظر است. یک نکته مهم: بسیاری از سرویسهای بزرگ، پرسوجوهای رسیده از resolverهای عمومی مانند 8.8.8.8 یا 1.1.1.1 را رد میکنند و بهجای پاسخ واقعی، کدی در محدوده 127.255.255.0/24 برمیگردانند. چنین پاسخی را «فهرستشده» تفسیر نکنید؛ پرسوجو را از resolver خود سرور تکرار کنید.
سرویسهای وبمحور هم چند فهرست را یکجا بررسی میکنند و برای مرور سریع مناسباند، اما مرجع نهایی همیشه صفحه lookup خود آن فهرست است. در کنار وضعیت IP، سلامت سمت دامنه را هم ببینید؛ ابزار رایگان بررسی سلامت سایت رکورد SPF، نیمسرورها و IP سرور میزبان را یکجا نشان میدهد.
اول ریشه را رفع کنید، بعد درخواست حذف بدهید
درخواست delist پیش از رفع علت، فقط به فهرست شدن دوباره ختم میشود. ابتدا صف ارسال را ببینید: در Postfix با postqueue -p و در Exim با exim -bp. سپس با خواندن هدر و ردیابی ایمیل و بررسی لاگها در /var/log/maillog یا /var/log/mail.log بررسی کنید تا بفهمید کدام حساب یا اسکریپت بیشترین ارسال را داشته است.
اگر منبع یک اسکریپت PHP است، هدر X-PHP-Originating-Script در پیامهای صف مسیر دقیق فایل را نشان میدهد؛ برای فعال بودنش باید mail.add_x_header = On در php.ini تنظیم شده باشد. هشدار: دستوری مانند postsuper -d ALL تمام صف را برای همیشه پاک میکند و ایمیلهای سالم کاربران را هم از بین میبرد؛ فقط پس از شناسایی منبع و ترجیحا با حذف انتخابی سراغ آن بروید.
پس از پاکسازی، رمز حسابهای آلوده را عوض کنید، هسته و افزونههای سیستم مدیریت محتوا را بهروز کنید و فایلهای ناشناس را بردارید. حالا به صفحه delist همان فهرست بروید؛ هر سرویس فرم و شرایط مخصوص خودش را دارد. برخی پس از قطع ترافیک مخرب بهصورت خودکار IP را آزاد میکنند و برخی درخواست دستی میخواهند. درخواستهای پیاپی و بینتیجه را تکرار نکنید؛ در بعضی سرویسها روند را کندتر میکند.
پیشگیری: SPF، DKIM و DMARC
این سه رکورد جلوی جعل دامنه شما را میگیرند و احتمال فهرست شدن را کم میکنند. SPF یک رکورد TXT است که مشخص میکند چه سرورهایی حق ارسال با دامنه شما را دارند، مثلا v=spf1 mx ip4:203.0.113.25 -all. مقدار -all سختگیرانه است و ~all ملایمتر؛ اگر مطمئن نیستید همه فرستندهها را فهرست کردهاید، با ~all شروع کنید.
DKIM هر پیام خروجی را امضای رمزنگاریشده میزند و کلید عمومی آن در رکورد TXT روی نام selector._domainkey.example.com منتشر میشود. DMARC هم در _dmarc.example.com تعریف میشود و به گیرنده میگوید با پیامهای ناموفق چه کند؛ مسیر امن این است که با p=none شروع کنید، گزارشها را بخوانید و بعد به p=quarantine و در نهایت p=reject برسید. نگهداری این رکوردها روی یک سرویس میزبانی DNS که رکوردهای MX و TXT را پشتیبانی میکند و زون را روی چند نیمسرور مستقل منتشر میکند، هم مدیریت را سادهتر میکند و هم جلوی از دسترس خارج شدن رکوردها را میگیرد.
یک مورد را جدا در نظر بگیرید: رکورد PTR یا همان reverse DNS در زون دامنه شما تنظیم نمیشود، بلکه باید از طریق صاحب بلوک IP، یعنی دیتاسنتر یا ارائهدهنده سرور، ثبت شود. بسیاری از گیرندههای بزرگ، ایمیلی را که PTR ندارد یا PTR آن با نام اعلامشده در HELO همخوان نیست با سختگیری بیشتری بررسی میکنند.
بستن راههای سوءاستفاده روی سرور
- ارسال را فقط با احراز هویت روی پورت
587مجاز کنید و در Postfix مقدارmynetworksرا به شبکههای واقعا مورد اعتماد محدود کنید. سپس باز نبودن relay را از یک شبکه بیرونی آزمایش کنید. - روی فایروال، ترافیک خروجی پورت
25را برای همه پردازهها جز سرویس ایمیل ببندید. این یک اقدام ساده است که جلوی اسکریپتهای آلوده را میگیرد. - برای هر حساب سقف ارسال در ساعت بگذارید و روی وبمیل و پنل مدیریت، رمز قوی و در صورت امکان ورود دومرحلهای فعال کنید.
- حجم صف ارسال را پایش کنید و برای رشد ناگهانی آن هشدار تعریف کنید؛ معمولا این نخستین نشانه آلودگی است.
- روی دامنهها آدرس catch-all را خاموش کنید؛ پذیرفتن نامه برای هر آدرس تعریفنشده هم صندوق را پر از اسپم میکند و هم سرور شما را به تولید نامههای برگشتی به نشانیهای جعلی وامیدارد.
پیادهسازی و نگهداری این موارد کار پیوستهای است. اگر تیم فنی داخلی ندارید، میتوانید هاردنینگ، فایروال و رسیدگی به حادثه را به خدمات پشتیبانی و مدیریت سرور بسپارید تا پیکربندی امن یک بار درست انجام شود و پایش آن ادامه پیدا کند.
جمعبندی
RBL مکانیزمی سبک و مبتنی بر DNS است که پیش از دریافت محتوای پیام، اعتبار IP فرستنده را میسنجد. فهرست شدن معمولا نشانه مشکلی واقعی روی سرور است، نه خطای فهرست؛ پس ترتیب درست کار این است: علت را پیدا کنید، آن را ببندید، سپس درخواست حذف بدهید. با SPF و DKIM و DMARC درست، PTR هماهنگ، relay بسته و پایش صف، احتمال تکرار ماجرا بهشدت کم میشود.
