امنيت ارتباطات روي وب
سرويس هاي ارتباطي مبتني بر وب که شاخص ترين آنها نرم افزارهاي کاربردي پست الکترونيک، سرويس چت و صدا روي IP يا VoIP هستند اصولاً بواسطه ي طبيعت زيرساختاري يکسان خود، با روش هاي يکساني مورد حملات اينترنتي واقع مي گردند. چرا که عليرغم آسيب پذير بودن اين سيستم ها، اغلب تمهيدات امنيتي روي اين سيستم ها ناديده گرفته مي شود و سرپرستان شبکه در اغلب موارد تصور مي کنند که نرم افزار آنتي ويروس تمام چيزي است که براي دور نگهداشتن مشکلات به آن نياز دارند و در نتيجه، آسيب پذيري هاي امنيتي موجود را ناديده گرفته و يا به سادگي ايمن سازي اين سيستم ها را به کلي فراموش مي کنند.
مجموعه ي بزرگي از آسيب پذيري ها بطور ذاتي در سيستم هاي پيام رساني وجود دارند. عوامل زير مي توانند باعث ايجاد نقطه ضعفها شوند:
امنيت به ندرت در فرآيند توسعه ي نرم افزار ادغام مي شود.
راحتي و کاربردپذيري غالباً بر نياز به امنيت، ارجحيت پيدا مي کنند.
بسياري از پروتکل هاي پيام رساني با در لحاظ نمودن امنيت طراحي نشده اند (خصوصاً مواردي که چند دهه قبل توسعه يافته اند، يعني زماني که امنيت به اندازه ي امروز اهميت پيدا نکرده بود). موضوع مضحک اين است که حتي پروتکل هاي پيام رساني مدرن (يا حداقل پياده سازي پروتکل ها) مورد استفاده در IM و VoIP هنوز در معرض آسيب پذيري ها و حملات جدي قرار دارند.
بسياري از حملات بر عليه سيستم هاي پيام رساني، صرفاً مزاحمت هاي کوچکي به حساب مي آيند. اما گروهي از اين حملات مي توانند صدمات جدي را بر اطلاعات شما و اعتبار سازمان تان تحميل کنند. حملات بدخواهانه بر عليه سيستم هاي پيام رساني عبارتند از:
انتقال Malware
از کار انداختن سرورها
بدست آوردن کنترل ايستگاه هاي کاري از راه دور
ضبط و ويرايش اطلاعات محرمانه در هنگام جابه جائي آنها بر روي شبکه
مشاهده ي پست الکترونيکهاي ذخيره شده بر روي سرورها و ايستگاه هاي کاري
مشاهده ي فايل هاي گزارش IM بر روي درايورهاي ديسک سخت ايستگاه هاي کاري
جمع آوري اطلاعات حوزه ي پيام رساني از طريق فايل هاي Log يا يک تحليلگر شبکه که مي تواند مهاجم را از مکالمات ميان افراد و سازمان ها مطلع سازد.
ضبط و پخش مجدد مکالمات تلفني
جمع آوري اطلاعات پيکربندي شبکه ي داخلي نظير نام ميزبان ها و آدرس هاي IP
اين گونه حملات مي توانند مشکلاتي نظير زيان هاي تجاري جدي، افشاي غيرمجاز (و احتمالاً غيرقانوني) اطلاعات محرمانه و از دست رفتن کليه ي اطلاعات را در پي داشته باشند.
بعضي از اين حملات به شيوه هاي هک ابتدائي نياز دارند: جمع آوري اطلاعات عمومي، اسکن و سرشماري سيستم هاي شما و سپس حمله. گروه ديگري از آنها مي توانند با ارسال پست الکترونيک ها و يا ضبط ترافيک شبکه اجرا شوند.
1) ممکن است کل سرور پست الکترونيک بخاطر مشکلات زير هدف يک توقف سرويس دهي قرار گرفته باشد:
سربار ذخيره سازي: چندين پيام بزرگ که مي توانند به سرعت کل ظرفيت ذخيره سازي يک سرور پست الکترونيک را مصرف کنند. اگر پيام ها بطور خودکار توسط سرور و يا بطور دستي توسط حساب هاي کاربري شخصي حذف نشوند، سرور قادر به دريافت پيام هاي جديد نخواهد بود.
اين وضعيت مي تواند يک مشکل DoS جدي را براي سيستم پست الکترونيک شما بوجود آورد، چه با از کار انداختن آن و چه با ملزم نمودن شما به خارج نمودن سيستم از حالت سرويس دهي براي پاک سازي انبوه پيام هاي متراکم شده. يک فايل پيوست 100 مگابايتي که 10 بار براي 100 کاربر ارسال شده باشد، مي تواند 100 گيگابايت از فضاي ذخيره سازي را اشغال نمايد.
مسدود کردن پهناي باند: يک مهاجم مي تواند سرويس پست الکترونيک شما را از طريق پر کردن اتصال اينترنت ورودي با اطلاعات بي ارزش از کار انداخته و يا آن را به زانو درآورد. حتي اگر سيستم شما بطور خودکار حملات آشکار پيوست را تشخيص داده و از آنها صرفنظر نمايد، پيام هاي مزاحم مي توانند منابع موجود را هدر داده و پردازش پيام هاي معتبر را به تأخير بيندازند.
2) يک حمله بر روي يک آدرس پست الکترونيک واحد، در صورتيکه آدرس به شخص يا گروه واقعاً مهمي تعلق داشته باشد، مي تواند به عواقب جدي منتهي گردد.
1. اندازه ي پست الکترونيک ها و يا پيوست هاي آنها را محدود کنيد. اين گزينه را در تنظيمات پيکربندي سرور پست الکترونيک (نظير تنظيماتي که در Novell Group Wise يا Microsoft Exchange وجود دارند)، سيستم فيلتر گذاري مضمون پست الکترونيک و حتي در سطح کلاينت پست الکترونيک بررسي نمائيد. اين بهترين روش براي محافظت در برابر سربار پيوست به حساب مي آيد.
2. فضاي متعلق به هر کاربر را بر روي سرور محدود نمائيد. اين کار باعث مي شود که از نوشته شدن پيوست هاي بزرگ بر روي درايو ديسک سخت جلوگيري گردد. اندازه ي پيام هاي ورودي و حتي پيام هاي خروجي (در صورتيکه مي خواهيد از اجراي چنين حمله اي توسط يک کاربر در داخل شبکه ي خود جلوگيري نمائيد) را محدود کنيد. به نظر مي رسد که 500 مگابايت محدوديت مناسبي باشد، اما اين موضوع کاملاً به اندازه ي شبکه ي شما، ظرفيت ذخيره سازي قابل دسترسي، فرهنگ تجاري و مواردي از اين قبيل بستگي خواهد داشت. بنابراين، پيش از تصميم گيري در مورد هر نکته اي به تمام اين پارامترها توجه داشته باشيد.
استفاده از FTP يا HTTP را بجاي پست الکترونيک براي انتقال فايل هاي بزرگ را بجاي پست الکترونيک در نظر بگيريد و کاربران داخلي را تشويق کنيد تا از Share هاي عمومي يا اداري استفاده نمايند. با انجام اينکار، شما مي توانيد يک کپي از فايل را بر روي يک سرور ذخيره نموده و از گيرنده بخواهيد تا خودش آن را بارگذاري کند. برخلاف منطق و استفاده ي عمومي، سيستم پست الکترونيک نبايد مخزن اطلاعات در نظر گرفته شود. يک سرور پست الکترونيک که براي اينکار مورد استفاده قرار مي گيرد، مي تواند کاملاً غيرقابل مديريت شده و ريسک هاي قانوني و حقوقي غيرضروري را ايجاد نمايد.
حتي در شرکت هاي بزرگ، هيچ دليلي وجود ندارد که هزاران تحويل ايميل ورودي در يک محدوده ي زماني کوتاه ضرورت داشته باشند. بعضي از سرورهاي پست الکترونيک، خصوصاً سرورهاي مبتني بر يونيکس مي توانند براي تحويل ايميل ها به يک Daemon يا سرويس براي عملکردهاي خودکاري نظير "وقتي پيامي از اين شخص دريافت مي شود، اين دستورالعمل را ايجاد کن"، برنامه ريزي شوند. اگر محافظت DoS در سيستم شما پياده سازي نشده باشد، يک هکر مي تواند هر دو مؤلفه ي سرور و نرم افزار کاربردي دريافت کننده ي اين پيام ها را از کار انداخته و احتمالاً مسئوليت ها و خسارات e-Commerce را ايجاد نمايد.
جلوگيري از حملات پست الکترونيک را در بيشترين فاصله از محيط شبکه ي خود که مي توانيد، انجام دهيد. هر چه ترافيک يا رفتار بدخواهانه ي بيشتري را از سرورها و کلاينت هاي پست الکترونيک خود دور نگهداريد، وضعيت بهتري خوهيد داشت.
در اغلب موارد، کاملاً آشکار است که چه نوع نرم افزار پست الکترونيک و با چه نسخه اي بر روي سرور در حال اجرا مي باشد. اين اطلاعات مي تواند ايده اي راجع به حملات احتمالي را در اختيار هکرها قرار دهد، خصوصاً اگر آنها يک "بانک اطلاعاتي آسيب پذيري" را براي يافتن آسيب پذيري هاي شناخته شده ي آن نسخه از نرم افزار جستجو کرده باشند. شکل [3]، همان سرور پست الکترونيک را نشان مي دهد که SMTP Banner آن از وضعيت پيش فرض تغيير يافته تا اطلاعاتي نظير شماره ي نسخه ي سرور پست الکترونيک را استتار نمايد.
اگر SMTP Banner پيش فرض خود را تغيير داده ايد، نبايد تصور کنيد که هيچکس نمي تواند نسخه ي نرم افزار شما را تشخيص دهد. يک ابزار مبتني بر لينوکس با نام smtpscan، اطلاعات نسخه ي سرور پست الکترونيک را بر اساس نحوه ي پاسخ دهي سرور به درخواست هاي SMTP دستکاري شده تشخيص مي دهد. شکل [4]، نتايج بدست آمده از smtpscan بر روي همان سرور شکل [3] را نشان مي دهد. همانطور که مشاهده مي کنيد، اين ابزار توانسته محصول و شماره ي نسخه ي سرور پست الکترونيک را شناسايي نمايد.
Banner پيش فرض خود را براي پوشش اطلاعات آن تغيير دهيد.
مطمئن شويد که هميشه آخرين وصله هاي نرم افزاري را اجرا مي کنيد.
سرور خود را تا حد امکان با استفاده از بهترين شيوه هاي شناخته شده از منابعي نظير SANS، مرکز امنيت اينترنت، NIST وامثالهم مستحکم نمائيد.
ممکن است شما در هنگام انجام اين دو آزمايش اطلاعات جعلي را از سرور خود دريافت کنيد. بعضي از سرورهاي SMTP (نظير Microsoft Exchange) از فرامين VRFY و EXPN پشتيباني نمي کنند و بعضي از فايروال هاي پست الکترونيک نيز به سادگي آنها را مسدود کره يا اطلاعات غلطي را برمي گردانند.
VRFY و EXPN را غيرفعال کنيد، مگر آنکه نياز داشته باشيد سيستم هاي دور بتوانند اطلاعات کاربر و فهرست پستي را از سرور شما جمع آوري کنند.
اگر به عملکرد VRFY و EXPN نياز داريد، مستندات سرور يا فايروال پست الکترونيک خود را براي توانائي محدود نمودن اين فرامين به ميزبان هاي خاص بر روي شبکه ي شما يا اينترنت را بررسي کنيد.
نکات کليدي زير را در هنگام بررسي سيستم پست الکترونيک خود در رابطه با نقطه ضعف هاي رله ي SMTP در نظر داشته باشيد:
سرور پست الکترونيک خود را با بکارگيري بيش از يک ابزار يا شيوه ي آزمايش، بررسي نمائيد. آزمايش هاي متعدد، احتمال خطا يا ناديده گرفتن مشکلات را به حداقل مي رسانند.
آزمايش رله ي باز را از خارج شبکه ي خود انجام دهيد. اگر آزمايش را از داخل شبکه انجام دهيد، ممکن است يک پاسخ مثبت کاذب را دريافت کنيد زيرا ممکن است پست الکترونيک Relaying خروجي پيکربندي شده و براي کلاينتهاي پست الکترونيک داخلي شما جهت ارسال پيامها به دنياي خارج الزامي باشند.
ابزارهاي Online رايگان: يکي از ابزارهاي Online مورد علاقه ي ما، در www.abuse.net/relay.html قرار گرفته است. شما مي توانيد يک آزمايش بي نام (anonymous) را بدون وارد کردن آدرس پست الکترونيک خود انجام دهيد، مگر آنکه يکي از اعضاي abuse.net باشيد. اين ابزار بلافاصله نتايج را در مرورگر شما نمايش خواهد داد. يک ابزار بررسي کننده ي رله ي ديگر نيز در www.dnsstuff.com وجود دارد.
ساير ابزارهاي مبتني بر ويندوز نظير Sam Spade for Windows. شکل [7] نشان مي دهد که چگونه مي توانيد يک بررسي رله ي SMTP را با Sam Spade بر روي سرور پست الکترونيک خود اجرا کنيد. شکل [8]، نتايج اين آزمايش را بر روي سرور آزمايشي ما نمايش مي دهد که آشکار مي کند Realying فعال است.
بعضي از سرورهاي SMTP، ارتباطات رله ي ورودي را مي پذيرند که باعث مي شود به نظر برسد که Relaying کار مي کند. اين موضوع هميشه صادق نخواهد بود زيرا ممکن است ارتباط ابتدائي مجاز شناخته شود، اما فيلتر گذاري عملاً در پشت صحنه حضور دارد. با بررسي اکانتي که پيام رله ي آزمايشي را براي آن ارسال کرده ايد، مطمئن شويد که آيا پست الکترونيک عملاً عبور کرده است يا خير.
از نرم افزار کاربردي Telnet گرافيکي مورد علاقه ي خود نظير HyperTerminal (که به همراه ويندوز ارائه مي شود) يا SecureCRT استفاده کنيد.
فرمان telnet mailserver_address 25 را در يک اعلان فرمان ويندوز يا يونيکس وارد نمائيد.
ممکن است براي مشاهده ي آنچه که وارد کرده ايد مجبور شويد Echoing محلي کاراکترها را در برنامه ي Telnet خود فعال نمائيد.
1. يک فرمان را وارد کنيد تا به سرور بگوئيد که "من از اين دامنه ارتباط برقرار کرده ام".
پس از هر فرمان در اين مراحل، بايد يک پيام با شماره گذاري متفاوت نظير OK 999 را دريافت کنيد. شما مي توانيد اين پيام ها را ناديده بگيريد.
2. فرماني نظير mail from:yourname@yourdomain.com را وارد کنيد تا آدرس پست الکترونيک خود را به سرور اعلام نمائيد.
3. فرماني نظير rcpt to:yourname@yourdomain.com را وارد کنيد تا به سرور بگوئيد که پست الکترونيک بايد براي چه شخصي فرستاده شود.
4. فرماني نظير data را وارد کنيد تا به سرور بگوئيد که بدنه ي پيام در ادامه قرار گرفته است.
5. متن A Relay Test را بعنوان بدنه ي پيام وارد کنيد.
6. فرمان را خاتمه دهيد.
شما مي توانيد فرمان Help يا ؟ را براي مشاهده ي فهرستي از تمام فرامين پشتيباني شده در اولين اعلان Telnet وارد نموده و برحسب سرور، کمک مورد نياز براي استفاده از فرامين مورد نظر را دريافت کنيد.
7. Relaying را بر روي سرور خود بررسي نمائيد:
به دنبال پيامي نظير Relay not allowed باشيد که از طرف سرور برگردانده مي شود. اگر چنين پيامي را دريافت کرديد، SMTP Relaying بر روي سرور شما مجاز نبوده و يا فيلترگذاري شده است زيرا بسياري از سرورها پيام هايي که ظاهراً از خارج شبکه سرچشمه گرفته اند اما از داخل آن مي آيند را مسدود مي کنند. شما احتمالاً اين پيام را پس از وارد کردن پيام rcpt to: دريافت خواهيد نمود.
اگر پيامي را از سرور دريافت نکرديد، Inbox خود را براي يافتن پست الکترونيک رله شده بررسي نمائيد.
اگر پست الکترونيک آزمايشي را دريافت کرده بوديد، SMTP Relaying بر روي سرور شما فعال است و احتمالاً بايد غيرفعال گردد. آخرين چيزي که مي خواهيد اين است که به Spammerها يا ساير مهاجمين اجازه دهيد که تظاهر کنند شما در هر ارسال انبوهي از Spam هستيد و يا بدتر از آن، توسط يک يا چند تأمين کننده ي Blacklist در فهرست هاي سياه قرار بگيريد. اين وضعيت مي توانيد ارسال و دريافت پست الکترونيک را بطور کامل مختلف نمايد.
شما مي توانيد اقدامات متقابل زير را بر روي سرور پست الکترونيک خود پياده سازي نمائيد تا STMP Relaying را غيرفعال و يا حداقل کنترل کنيد:
رله ي SMTP را بر روي سرور پست الکترونيک خود غيرفعال نمائيد. اگر نمي دانيد که آيا به رله ي SMTP نياز داريد يا خير، به احتمال قوي به آن نياز نداريد. شما مي توانيد رله ي SMTP را در صورت نياز براي ميزبان هاي خاصي فعال کنيد.
اگر سرور پست الکترونيک شما اجازه مي دهد، Authentication را پياده سازي نمائيد. ممکن است بتوانيد شيوه هاي تأييد اعتبار نظير استفاده از کلمه عبور و يا يک آدرس پست الکترونيک که با دامنه ي سرور پست الکترونيک مطابقت دارد را الزامي کنيد. مستندات سرور و کلاينت پست الکترونيک خود را براي يافتن جزئيات مربوط به راه اندازي اين نوع تاييد اعتبار بررسي نمائيد.
منبع:ماهنامه ي کامپيوتري بزرگراه رايانه، شماره ي 134
نقاط ضعف
مجموعه ي بزرگي از آسيب پذيري ها بطور ذاتي در سيستم هاي پيام رساني وجود دارند. عوامل زير مي توانند باعث ايجاد نقطه ضعفها شوند:
امنيت به ندرت در فرآيند توسعه ي نرم افزار ادغام مي شود.
راحتي و کاربردپذيري غالباً بر نياز به امنيت، ارجحيت پيدا مي کنند.
بسياري از پروتکل هاي پيام رساني با در لحاظ نمودن امنيت طراحي نشده اند (خصوصاً مواردي که چند دهه قبل توسعه يافته اند، يعني زماني که امنيت به اندازه ي امروز اهميت پيدا نکرده بود). موضوع مضحک اين است که حتي پروتکل هاي پيام رساني مدرن (يا حداقل پياده سازي پروتکل ها) مورد استفاده در IM و VoIP هنوز در معرض آسيب پذيري ها و حملات جدي قرار دارند.
بسياري از حملات بر عليه سيستم هاي پيام رساني، صرفاً مزاحمت هاي کوچکي به حساب مي آيند. اما گروهي از اين حملات مي توانند صدمات جدي را بر اطلاعات شما و اعتبار سازمان تان تحميل کنند. حملات بدخواهانه بر عليه سيستم هاي پيام رساني عبارتند از:
انتقال Malware
از کار انداختن سرورها
بدست آوردن کنترل ايستگاه هاي کاري از راه دور
ضبط و ويرايش اطلاعات محرمانه در هنگام جابه جائي آنها بر روي شبکه
مشاهده ي پست الکترونيکهاي ذخيره شده بر روي سرورها و ايستگاه هاي کاري
مشاهده ي فايل هاي گزارش IM بر روي درايورهاي ديسک سخت ايستگاه هاي کاري
جمع آوري اطلاعات حوزه ي پيام رساني از طريق فايل هاي Log يا يک تحليلگر شبکه که مي تواند مهاجم را از مکالمات ميان افراد و سازمان ها مطلع سازد.
ضبط و پخش مجدد مکالمات تلفني
جمع آوري اطلاعات پيکربندي شبکه ي داخلي نظير نام ميزبان ها و آدرس هاي IP
اين گونه حملات مي توانند مشکلاتي نظير زيان هاي تجاري جدي، افشاي غيرمجاز (و احتمالاً غيرقانوني) اطلاعات محرمانه و از دست رفتن کليه ي اطلاعات را در پي داشته باشند.
شيوه هاي هک ابتدائي
بعضي از اين حملات به شيوه هاي هک ابتدائي نياز دارند: جمع آوري اطلاعات عمومي، اسکن و سرشماري سيستم هاي شما و سپس حمله. گروه ديگري از آنها مي توانند با ارسال پست الکترونيک ها و يا ضبط ترافيک شبکه اجرا شوند.
بمب هاي پست الکترونيک
فايل هاي الحاقي
هک از طريق فايل الحاقي
1) ممکن است کل سرور پست الکترونيک بخاطر مشکلات زير هدف يک توقف سرويس دهي قرار گرفته باشد:
سربار ذخيره سازي: چندين پيام بزرگ که مي توانند به سرعت کل ظرفيت ذخيره سازي يک سرور پست الکترونيک را مصرف کنند. اگر پيام ها بطور خودکار توسط سرور و يا بطور دستي توسط حساب هاي کاربري شخصي حذف نشوند، سرور قادر به دريافت پيام هاي جديد نخواهد بود.
اين وضعيت مي تواند يک مشکل DoS جدي را براي سيستم پست الکترونيک شما بوجود آورد، چه با از کار انداختن آن و چه با ملزم نمودن شما به خارج نمودن سيستم از حالت سرويس دهي براي پاک سازي انبوه پيام هاي متراکم شده. يک فايل پيوست 100 مگابايتي که 10 بار براي 100 کاربر ارسال شده باشد، مي تواند 100 گيگابايت از فضاي ذخيره سازي را اشغال نمايد.
مسدود کردن پهناي باند: يک مهاجم مي تواند سرويس پست الکترونيک شما را از طريق پر کردن اتصال اينترنت ورودي با اطلاعات بي ارزش از کار انداخته و يا آن را به زانو درآورد. حتي اگر سيستم شما بطور خودکار حملات آشکار پيوست را تشخيص داده و از آنها صرفنظر نمايد، پيام هاي مزاحم مي توانند منابع موجود را هدر داده و پردازش پيام هاي معتبر را به تأخير بيندازند.
2) يک حمله بر روي يک آدرس پست الکترونيک واحد، در صورتيکه آدرس به شخص يا گروه واقعاً مهمي تعلق داشته باشد، مي تواند به عواقب جدي منتهي گردد.
ضد هک
1. اندازه ي پست الکترونيک ها و يا پيوست هاي آنها را محدود کنيد. اين گزينه را در تنظيمات پيکربندي سرور پست الکترونيک (نظير تنظيماتي که در Novell Group Wise يا Microsoft Exchange وجود دارند)، سيستم فيلتر گذاري مضمون پست الکترونيک و حتي در سطح کلاينت پست الکترونيک بررسي نمائيد. اين بهترين روش براي محافظت در برابر سربار پيوست به حساب مي آيد.
2. فضاي متعلق به هر کاربر را بر روي سرور محدود نمائيد. اين کار باعث مي شود که از نوشته شدن پيوست هاي بزرگ بر روي درايو ديسک سخت جلوگيري گردد. اندازه ي پيام هاي ورودي و حتي پيام هاي خروجي (در صورتيکه مي خواهيد از اجراي چنين حمله اي توسط يک کاربر در داخل شبکه ي خود جلوگيري نمائيد) را محدود کنيد. به نظر مي رسد که 500 مگابايت محدوديت مناسبي باشد، اما اين موضوع کاملاً به اندازه ي شبکه ي شما، ظرفيت ذخيره سازي قابل دسترسي، فرهنگ تجاري و مواردي از اين قبيل بستگي خواهد داشت. بنابراين، پيش از تصميم گيري در مورد هر نکته اي به تمام اين پارامترها توجه داشته باشيد.
استفاده از FTP يا HTTP را بجاي پست الکترونيک براي انتقال فايل هاي بزرگ را بجاي پست الکترونيک در نظر بگيريد و کاربران داخلي را تشويق کنيد تا از Share هاي عمومي يا اداري استفاده نمايند. با انجام اينکار، شما مي توانيد يک کپي از فايل را بر روي يک سرور ذخيره نموده و از گيرنده بخواهيد تا خودش آن را بارگذاري کند. برخلاف منطق و استفاده ي عمومي، سيستم پست الکترونيک نبايد مخزن اطلاعات در نظر گرفته شود. يک سرور پست الکترونيک که براي اينکار مورد استفاده قرار مي گيرد، مي تواند کاملاً غيرقابل مديريت شده و ريسک هاي قانوني و حقوقي غيرضروري را ايجاد نمايد.
ارتباطات
حملات سيل آسا
اقدامات متقابل بر عليه حملات ارتباطي
حتي در شرکت هاي بزرگ، هيچ دليلي وجود ندارد که هزاران تحويل ايميل ورودي در يک محدوده ي زماني کوتاه ضرورت داشته باشند. بعضي از سرورهاي پست الکترونيک، خصوصاً سرورهاي مبتني بر يونيکس مي توانند براي تحويل ايميل ها به يک Daemon يا سرويس براي عملکردهاي خودکاري نظير "وقتي پيامي از اين شخص دريافت مي شود، اين دستورالعمل را ايجاد کن"، برنامه ريزي شوند. اگر محافظت DoS در سيستم شما پياده سازي نشده باشد، يک هکر مي تواند هر دو مؤلفه ي سرور و نرم افزار کاربردي دريافت کننده ي اين پيام ها را از کار انداخته و احتمالاً مسئوليت ها و خسارات e-Commerce را ايجاد نمايد.
جلوگيري از حملات پست الکترونيک را در بيشترين فاصله از محيط شبکه ي خود که مي توانيد، انجام دهيد. هر چه ترافيک يا رفتار بدخواهانه ي بيشتري را از سرورها و کلاينت هاي پست الکترونيک خود دور نگهداريد، وضعيت بهتري خوهيد داشت.
ايمن سازي خودکار
Tarpitting
نرم افزارهاي کاربردي فيلترگذاري
طرح مقابله
امکان شناسايي سرور
جمع آوري اطلاعات
در اغلب موارد، کاملاً آشکار است که چه نوع نرم افزار پست الکترونيک و با چه نسخه اي بر روي سرور در حال اجرا مي باشد. اين اطلاعات مي تواند ايده اي راجع به حملات احتمالي را در اختيار هکرها قرار دهد، خصوصاً اگر آنها يک "بانک اطلاعاتي آسيب پذيري" را براي يافتن آسيب پذيري هاي شناخته شده ي آن نسخه از نرم افزار جستجو کرده باشند. شکل [3]، همان سرور پست الکترونيک را نشان مي دهد که SMTP Banner آن از وضعيت پيش فرض تغيير يافته تا اطلاعاتي نظير شماره ي نسخه ي سرور پست الکترونيک را استتار نمايد.
اگر SMTP Banner پيش فرض خود را تغيير داده ايد، نبايد تصور کنيد که هيچکس نمي تواند نسخه ي نرم افزار شما را تشخيص دهد. يک ابزار مبتني بر لينوکس با نام smtpscan، اطلاعات نسخه ي سرور پست الکترونيک را بر اساس نحوه ي پاسخ دهي سرور به درخواست هاي SMTP دستکاري شده تشخيص مي دهد. شکل [4]، نتايج بدست آمده از smtpscan بر روي همان سرور شکل [3] را نشان مي دهد. همانطور که مشاهده مي کنيد، اين ابزار توانسته محصول و شماره ي نسخه ي سرور پست الکترونيک را شناسايي نمايد.
اقدامات پيشگيرانه
Banner پيش فرض خود را براي پوشش اطلاعات آن تغيير دهيد.
مطمئن شويد که هميشه آخرين وصله هاي نرم افزاري را اجرا مي کنيد.
سرور خود را تا حد امکان با استفاده از بهترين شيوه هاي شناخته شده از منابعي نظير SANS، مرکز امنيت اينترنت، NIST وامثالهم مستحکم نمائيد.
هک پروتکل پست الکترونيک
جمع آوري آدرس هاي ايميل
ممکن است شما در هنگام انجام اين دو آزمايش اطلاعات جعلي را از سرور خود دريافت کنيد. بعضي از سرورهاي SMTP (نظير Microsoft Exchange) از فرامين VRFY و EXPN پشتيباني نمي کنند و بعضي از فايروال هاي پست الکترونيک نيز به سادگي آنها را مسدود کره يا اطلاعات غلطي را برمي گردانند.
ضد هک
VRFY و EXPN را غيرفعال کنيد، مگر آنکه نياز داشته باشيد سيستم هاي دور بتوانند اطلاعات کاربر و فهرست پستي را از سرور شما جمع آوري کنند.
اگر به عملکرد VRFY و EXPN نياز داريد، مستندات سرور يا فايروال پست الکترونيک خود را براي توانائي محدود نمودن اين فرامين به ميزبان هاي خاص بر روي شبکه ي شما يا اينترنت را بررسي کنيد.
ارسال پيام از طريق سرورهاي خارجي
نکات کليدي زير را در هنگام بررسي سيستم پست الکترونيک خود در رابطه با نقطه ضعف هاي رله ي SMTP در نظر داشته باشيد:
سرور پست الکترونيک خود را با بکارگيري بيش از يک ابزار يا شيوه ي آزمايش، بررسي نمائيد. آزمايش هاي متعدد، احتمال خطا يا ناديده گرفتن مشکلات را به حداقل مي رسانند.
آزمايش رله ي باز را از خارج شبکه ي خود انجام دهيد. اگر آزمايش را از داخل شبکه انجام دهيد، ممکن است يک پاسخ مثبت کاذب را دريافت کنيد زيرا ممکن است پست الکترونيک Relaying خروجي پيکربندي شده و براي کلاينتهاي پست الکترونيک داخلي شما جهت ارسال پيامها به دنياي خارج الزامي باشند.
تست اتوماتيک
ابزارهاي Online رايگان: يکي از ابزارهاي Online مورد علاقه ي ما، در www.abuse.net/relay.html قرار گرفته است. شما مي توانيد يک آزمايش بي نام (anonymous) را بدون وارد کردن آدرس پست الکترونيک خود انجام دهيد، مگر آنکه يکي از اعضاي abuse.net باشيد. اين ابزار بلافاصله نتايج را در مرورگر شما نمايش خواهد داد. يک ابزار بررسي کننده ي رله ي ديگر نيز در www.dnsstuff.com وجود دارد.
ساير ابزارهاي مبتني بر ويندوز نظير Sam Spade for Windows. شکل [7] نشان مي دهد که چگونه مي توانيد يک بررسي رله ي SMTP را با Sam Spade بر روي سرور پست الکترونيک خود اجرا کنيد. شکل [8]، نتايج اين آزمايش را بر روي سرور آزمايشي ما نمايش مي دهد که آشکار مي کند Realying فعال است.
بعضي از سرورهاي SMTP، ارتباطات رله ي ورودي را مي پذيرند که باعث مي شود به نظر برسد که Relaying کار مي کند. اين موضوع هميشه صادق نخواهد بود زيرا ممکن است ارتباط ابتدائي مجاز شناخته شود، اما فيلتر گذاري عملاً در پشت صحنه حضور دارد. با بررسي اکانتي که پيام رله ي آزمايشي را براي آن ارسال کرده ايد، مطمئن شويد که آيا پست الکترونيک عملاً عبور کرده است يا خير.
تست دستي
از نرم افزار کاربردي Telnet گرافيکي مورد علاقه ي خود نظير HyperTerminal (که به همراه ويندوز ارائه مي شود) يا SecureCRT استفاده کنيد.
فرمان telnet mailserver_address 25 را در يک اعلان فرمان ويندوز يا يونيکس وارد نمائيد.
ممکن است براي مشاهده ي آنچه که وارد کرده ايد مجبور شويد Echoing محلي کاراکترها را در برنامه ي Telnet خود فعال نمائيد.
1. يک فرمان را وارد کنيد تا به سرور بگوئيد که "من از اين دامنه ارتباط برقرار کرده ام".
پس از هر فرمان در اين مراحل، بايد يک پيام با شماره گذاري متفاوت نظير OK 999 را دريافت کنيد. شما مي توانيد اين پيام ها را ناديده بگيريد.
2. فرماني نظير mail from:yourname@yourdomain.com را وارد کنيد تا آدرس پست الکترونيک خود را به سرور اعلام نمائيد.
3. فرماني نظير rcpt to:yourname@yourdomain.com را وارد کنيد تا به سرور بگوئيد که پست الکترونيک بايد براي چه شخصي فرستاده شود.
4. فرماني نظير data را وارد کنيد تا به سرور بگوئيد که بدنه ي پيام در ادامه قرار گرفته است.
5. متن A Relay Test را بعنوان بدنه ي پيام وارد کنيد.
6. فرمان را خاتمه دهيد.
شما مي توانيد فرمان Help يا ؟ را براي مشاهده ي فهرستي از تمام فرامين پشتيباني شده در اولين اعلان Telnet وارد نموده و برحسب سرور، کمک مورد نياز براي استفاده از فرامين مورد نظر را دريافت کنيد.
7. Relaying را بر روي سرور خود بررسي نمائيد:
به دنبال پيامي نظير Relay not allowed باشيد که از طرف سرور برگردانده مي شود. اگر چنين پيامي را دريافت کرديد، SMTP Relaying بر روي سرور شما مجاز نبوده و يا فيلترگذاري شده است زيرا بسياري از سرورها پيام هايي که ظاهراً از خارج شبکه سرچشمه گرفته اند اما از داخل آن مي آيند را مسدود مي کنند. شما احتمالاً اين پيام را پس از وارد کردن پيام rcpt to: دريافت خواهيد نمود.
اگر پيامي را از سرور دريافت نکرديد، Inbox خود را براي يافتن پست الکترونيک رله شده بررسي نمائيد.
اگر پست الکترونيک آزمايشي را دريافت کرده بوديد، SMTP Relaying بر روي سرور شما فعال است و احتمالاً بايد غيرفعال گردد. آخرين چيزي که مي خواهيد اين است که به Spammerها يا ساير مهاجمين اجازه دهيد که تظاهر کنند شما در هر ارسال انبوهي از Spam هستيد و يا بدتر از آن، توسط يک يا چند تأمين کننده ي Blacklist در فهرست هاي سياه قرار بگيريد. اين وضعيت مي توانيد ارسال و دريافت پست الکترونيک را بطور کامل مختلف نمايد.
شما مي توانيد اقدامات متقابل زير را بر روي سرور پست الکترونيک خود پياده سازي نمائيد تا STMP Relaying را غيرفعال و يا حداقل کنترل کنيد:
رله ي SMTP را بر روي سرور پست الکترونيک خود غيرفعال نمائيد. اگر نمي دانيد که آيا به رله ي SMTP نياز داريد يا خير، به احتمال قوي به آن نياز نداريد. شما مي توانيد رله ي SMTP را در صورت نياز براي ميزبان هاي خاصي فعال کنيد.
اگر سرور پست الکترونيک شما اجازه مي دهد، Authentication را پياده سازي نمائيد. ممکن است بتوانيد شيوه هاي تأييد اعتبار نظير استفاده از کلمه عبور و يا يک آدرس پست الکترونيک که با دامنه ي سرور پست الکترونيک مطابقت دارد را الزامي کنيد. مستندات سرور و کلاينت پست الکترونيک خود را براي يافتن جزئيات مربوط به راه اندازي اين نوع تاييد اعتبار بررسي نمائيد.
منبع:ماهنامه ي کامپيوتري بزرگراه رايانه، شماره ي 134
