النون

1-    نصب ابزاها با پلاگین های موجود در اینترنت برای OSSIM برای تعدادی از سرویس ها که امکان اتصال انها وجود دارد.

2-    تولید پلاگین ها برای ابزارهایی که log استاندارد تولید می کنند.

3-    تولید پلاگین های تحلیل log برای سیستم هایی که خاص سرویس ایمیل النون است.

3. کمبود مراکز داده پایدار، ایمن و پاسخگو

در پروژه ایمیل از مرکز داده های مختلفی استفاده شد است از جمله این مراکز می توان به تبیان، سروش رسانه، پارس انلاین، افرانت و زیر ساخت اشاره کرد.

متاسفانه مراکز داده معمولا SLA که مناسب سرویس ایمیل باشد ارائه نمی دهند. بدیهی است SLA سرویس ما پایین تر از مراکز داده خواهد بود اگر بخواهیم از یک مرکز داده استفاده کنیم. مشکلاتی از قبیل دیده نشده از برخی رنج های IP ، قطعی سرویس مشکلات برق و سخت افزاری امری اجتناب ناپذیر در مراکز داده است. پشتیبانی و پاسخ گویی تیم مرکز داده، تاثیر مستقیم در کیفیت سرویس ایمیل دارد. در استفاده از ایمیل در بسیاری از مواقع مشکلات ناشی از ضعف پشتیبانی مراکز داده باعث از دسترس خارج شدن سرویس های ما شده است.

3.1.3 مشکلات پشتیبانی

1. توسعه سیستم های دقیق پشتیبان گیری در معماری با مقیاس بالا

نگهداری حجم بالای پشتیبان ها در مراکز داده مختلف نیازمند فعالیت های زیادی است. بسیاری از مشکلات کنترل ریسک و هزینه است به گونه ای که با هزینه معقول بتوانیم در شرایط بحرانی اطلاعات کاربران را درکمترین زمان ممکن بازیابی نماییم.

2. کمبود نیروی انسانی متخصص جهت پشتیبانی و پاسخگویی به صورت 7*24

3. کاهش incident ها از طریق root cause کردن مشکلات

4. افزایش رضایت مشتریان و کاربران با توجه به متدولوژی مدیریت خدمات اخذ شده

4.1.3 مشکلات امنیت

1. امنیت و جلوگیری از حمله شدن به ایمیل و spamer ها

سرویس های ایمیل یکی از اهداف بات ها و حمله هکر ها است. بسیاری از شبکه های بات ها سعی می کنند با دسترسی به سرویس ایمیل اقدام به ارسال ایمیل با تعداد بالا نمایند. در سیستم ایمیل النون ما مواجه با حجم عظیمی که حملات به سرور های ایمیل گیتوی هستیم. این حملات در طی زمان به روز می شوند و سعی می کنند اسیب پذیری های جدیدی را در سیستم ها برای حملات پیدا کنند؛ لذا پویش مستمر امنیت و به روز رسانی سرویس های انتی spam و انتی ویروس و سیستم امنیتی یکی از مشکلات ایمیل است. بسیاری از اوقات این سیستم ها به دلیل سخت گیری هایی که انجام می دهند ممکن است باعث ایجاد false positive شوند و باعث نارضایتی کاربران گردند.

• برخی از سرو های ایمیل توسط ویروس ها و bot ها الوده می شود و به عنوان سرور های ارسال spam استفاده می شود. این روش بسیار معمول است و متاسفانه بررسی mailq به کشف این حمله کمک نمی کند زیرا مورد غیر عادی مشاهده نمی شود. بررسی ترافیک شبکه می تواند به یافتن این حملات کمک نماید. برای مقابله با این نوع حمله موارد زیر پیشنهاد می شود:
• استفاده از انتی ویروس قوی بر روی سرور ها
• به روز رسانی امنیتی و نصب وصله های امنیتی بر روی سرور ها
• بستن پورت 25 به بیرون برای سرور هایی که نیاز به این پرت ندارد.
• رعایت اصل حداقل دسترسی در مورد شبکه و دسترسی کاربران.
• نصب مجدد و پاک کردن کامل سیستم عامل هایی که الوده شده اند.
• جدا کردن شبکه سیستم هایی که ریسک بالایی دارند.
• حمله کننده کلمه عبور و نام کاربری یکی از کاربران سیستم را در می اورد و از ان ها برای ارسال spam استفاده می کند.(در مورد سیستم gateway که برای اتصال با استفاده از imap و smtp دارد، استفاده می کند):
• استفاده از کلمات عبور قوی برای کاربران
• در مورادی که کاربر sla پر نکرده یا اینکه کلمه عبور ضعیف است نتواند وارد سیستم شود.
• نام کاربری های عمومی مانند info و admin کلمات عبور سخت داشته باشند و به کاربران واگذار نشوند.
• کلمات عبور به صورت دوره های شش ماهه این تغییر نماید.
• تعداد ایمیل های دریافتی و ارسالی کنترل شود و در صورت مشاهده رشد غیر عادی گزارش گردد.
• تعداد ایمیل های ارسالی و دریافتی برای کاربران محدود شود.
• سیستم های کاربران از جهت الودگی به ویروس و تروجان بررسی گردد.
• در صورت بروز این مشکل بلافاصله نام کاربری که حمله کننده اطلاعات ان را سرقت کرده شناسایی و کلمه عبور تغییر نماید.
• اشتباه در تنظیمات شبکه
• در موارد بسیار فراموش کردن در مورد نحوه تنظیمات ممکن است باعث شود حمله کننده بتواند حملاتی را انجام دهد؛ برای حل این مشکل بایستی بعد از تغییر و یا انجام تغییرات شبکه این موارد بازبینی گردد.

2. پشتیبانی و امن سازی imap , pop3

یکی از سرویس های که معمولا هدف حملات قرار می گیرند imap و pop3 است. در این سرویس ها سعی می گردد با به روز رسانی این سرویس ها و فعال سازی رمزنگاری، بر این مشکلات غلبه شود؛ ولی از انجایی که برای دسترسی در این سیستم ها از درگاه های مختلف استفاده می شود و کنترل انها مشکل است (زیرا انعطاف و تغییر این پرتکل ها بسیار دشوار است و معمولا کلاینت هایی که از سیستم ها استفاده می کنند)، نمی توانند محدودیت های زیادی را بپذیرند.

3. جلوگیری از مشکلات مربوط به brutreforce نام کاربری و کلمه عبور

یکی از حملاتی که به سیستم ایمیل انجام می شود حدس زدن نام کاربری و کلمه عبور با امتحان کردن تعداد زیادی از حالات ممکن است. برای جلوگیری از این حملات سیاست های مختلفی از جمله captcha  و یا بستن ip در نظر گرفته شده است. همچنین سعی شده در انتخاب کلمات عبور موارد زیر رعایت شود.

قوانین زیر در نگهداری و تغییر کلمات عبور در کل سیستم ایمیل بومی رعایت می شود:

1)     کلیه کلمات عبور پشتیبانی بایستی بیشتر از 12 حرف شامل حرف و کارکتر خاص باشد.

2)     بایستی به هیچ وجه کلمات عبور email بر روی اینترنت منتقل نشود.

3)     به صورت کلامی با صدای بلند گفته نشود.

4)     برای هر کاربر یک user مجزا و با حداقل دسترسی در نظر گرفته می شود.

5)     کاربر root تغییر نام داده می شود و nologin می شود و کلمه عبور تنها در اختیار admin ها است.

6)      برای نرم افزارها نیز در صورت نیاز کلمه عبور تعریف می شود.

7)     کلمه عبور ادمین های سرور هر ماه تغییر می کند.

8)     کلمه عبور root در سه ماه یک بار تغییر می کند.

9)     کلمه عبور مربوط به نرم افزارها (شامل کلمه عبور پایگاه داده) هر شش ماه یک بار تغییر می نماید.

ولی این اقدامات کافی نبوده و معمولا حمله کننده ها با استفاده از ضعف انتخاب نام کاربری برای کاربران و استفاده از imap برای brute force استفاده می کنند. استفاده از تعداد زیادی از کاربران از یک vpn مشکلاتی از قبیل false positive به وجود می اورد و سختی این سیاست ها یکی از مشکلات کنترل کلمات عبور است. به نظر می رسد استفاده از OTP و کلمات عبور دوعامله می تواند تا حد زیادی این مشکلات را بهبود ببخشد.

4. جلوگیری از حملات در سطح شبکه و سیستم عامل

در سطح شبکه و سیستم عامل سعی شده است سرویس ها به صورت مداوم بررسی شود و سیاست ها و چک لیست هایی برای به روز رسانی امنیتی و محدودیت استفاده از انها انجام شود.

سیاست محیط تست و توسعه

قوانین و سیاست های زیر در مورد ماشین های تست و محیط تست وجود دارد.

1)     تا جای ممکن محیط تست بر روی سرورهای داخلی ایجاد می شود و در صورت کمبود منابع و ممکن نبود تست کارا، این امر بر روی سرور های عملیاتی انجام می شود.

2)     ماشین های تست در vlan و شبکه جدا بر روی ESx و pfsense قرار می گیرند و به صورت شبکه ای تا جای ممکن دسترسی از سایر سرور ها قطع می شود.

3)     پهنای باند اینترنت اختصاص داده شده برای ماشین تست به صورت shape  شده محدود می شود.

4)     تنها دسترسی از طریق تونل به ماشین های تست امکان پذیر است و تا جای ممکن دسترسی های شبکه ای محدود می شود.

وضعیت شبکه سرور های عملیاتی

قوانین زیر در مورد سرور عملیاتی رعایت می گردد.

1)     سرور ها به تدریج در چهار شبکه مجزا قرار می گیرند (سرور های داده (ldap و mysql) سرور های وب، سرور های infra (zcp ،spam)، ایمیل gateway (postfix،gateway،()

2)     سرور های وب در پشت waf قرار می گیرد. مخصوصا سرور های مربوط به wordpress

3)     سرور ها به صورت هفتگی به روز رسانی می گردد (patch های امنیتی بر روی انها نصب می گردد).

4)     ماژول مربوط به IDP فعال می گردد.

سیاست بررسی log ها و SOC

چک کردن دوره ای log های مربوطه و history مربوط به دستورات توسط SOC

 5. جلوگیری از حملات در سطح نرم افزار و سرویس‌های اختصاصی

برای تست نرم افزار به صورت دوره ای هر یک سال یکبار سیستم ها مطابق استاندارد های بین المللی تست می شود. برای تست نرم افزارها از استاندارد owasp، SANS و infosec استفاده می شود و برای تست شبکه از استاندارد OSSTM استفاده می گردد. هدف از تست های امنیتی یافتن و گزارش اسیب پذیری ها در تعامل با توسعه دهندگان سیستم است.

تمامی اطلاعات سیستم شامل کد نرم افزار در اختیار تست کننده قرار خواهد گرفت تا بیشترین اسیب پذیری های ممکن از سیستم یافت شود.

هدف اصلی رفع اسیب پذیری های امنیتی سیستم است و صرف یافتن اسیب پذیری اگرچه با ارزش است ولی هدف اصلی رفع اسیب پذیری ها است. لذا مجری تست موظف است راه حل های رفع اسیب پذیری را با جزئیات کامل ارائه دهد. همچنین تمامی فرایند تست یایستی در قالب سناریو همراه با عکس و فیلم مستند شود.

در مواردی که نیاز به توضیحات بیشتر در مورد سیستم است بایستی با برگزاری جلسات با توسعه دهنده موارد تست توضیح داده شود. توسعه دهنده با کمک مجری تست مسئول رفع اسیب پذیری ها است.

ورودی های تست

برای تست ابتدا جلسه شناخت سیستم شامل افراد شبکه، توسعه دهنده ها و تست کننده سیستم برگزار می شود و در این جلسه تمامی مستندات سیستم به مجری تست تحویل داده می شود. هدف از این جلسه اشنایی مجری تست با معماری و نحوه عملکرد سیستم است.

در طی فرایند تست نیز تست کننده با توسعه دهنده در ارتباط است و موارد تست را با توسعه دهنده هماهنگ و توضیحات لازم در اختیار توسعه دهنده قرار می گیرد.

خروجی تست

مجری تست موظف است خروجی های تست را در قالب OWASP گزارش نماید. هم سناریو های موفق و اسیب پذیر و هم نا موفق در گزارش خواهد امد. در طی انجام پروژه خروجی هر سناریو که تست می شود شامل عکس و فیلم و خلاصه از فعالیت ها به صورت گزارش مقدماتی ایمیل می شود. در پایان پروژه گزارش مفصل از وضعیت سیستم ارائه می گردد.

فرمت گزارش مفصل

گزارش مفصل مطابق ورژن چهارم استاندارد OWASP ارائه می شود و شامل موارد زیر است.

1. خلاصه مدیریتی: شامل خلاصه موارد تست شده و وضعیت هر مورد و تاثیری که اسیب پذیری ها می تواند بر روی سیستم داشته باشد.

2. پارامتر های تست: در این بخش موارد که در تست موثر بودند بیان می شود و شامل موارد زیر است:

2.1 هدف پروژه

2.2: دامنه پروژه: محدوده پروژه که در قرارداد امده است.

2.3: زمان بندی پروژه: زمان شروع و پایان پروژه.

2.4: اهداف: سیستم هایی که هدف تست بودند.

2.5: محدودیت ها: در این بخش محدودیت های دسترسی و امکانات تست بیان می شود.

2.6: جدول اسیب پذیری ها: شامل جدولی از خلاصه اسیب پذیری که در سیستم یافت شده است.

2.7: توصیه ها برای رفع: در این بخش توصیه هایی برای رفع اسیب پذیری های سیستم بیان می شود این توصیه های به صورت خلاصه است.

2.8: لیست ابزارهایی که در طی تست از انها استفاده شده است به همراه نسخه.

3. یافته ها: در این بخش TESTLOG ها و تست های انجام شده چه موفق و ناموفق به همراه عکس و ارجاع به فیلم ها بیان می شود. کلیه TEST CASE های استاندارد OWASP بایستی توسط سناریوهای این بخش پوشش داده شود و مشخص شود سناریو برای اجرای کدام TEST CASE بوده است. در اخر هر سناریو بایستی راه حل هایی جهت رفع انها با جزئیات کامل بیان شود. هدف هر سناریو بایستی در ابتدا بیان شود و در انتها مشخص شود که تا چه حدی این هدف محقق شده است.

در ادامه برخی از این TEST CASE ها امده است.

فرمت گزارش موقت

این گزارش شامل یک سناریو و یا بخشی از یک سناریو است که خلاصه ان در قالب یک ایمیل یک صفحه ای به انضمام عکس ها و فیلم ها ارائه می گردد.

در پایان هر روز از تست یکی از این گزارشات اعلام می شود.

بخش های مورد تست

سیستم النون از بخش های زیر تشکیل شده است. برای هر قسمت اسیب پذیری هایی که تا کنون یافت شده  اشاره شده است و همچنین راه حل برای هر قسمت نیز بیان گردیده است.

6. جلوگیری از شنود ترافیک های مبادله شده

ایجاد تعادل ببین امنیت و سهولت استفاده یکی از مشکلاتی است که در زمینه ایمیل با ان مواجه هستیم.

5.1.3 چالش‌های کسب و کاری

• سلب اعتماد، علاقه و توجه مردم به خدمات دولتی و حاکمیتی
• بروکراسی شدید، کند و پیچیده برای حمایت دولت از خدمات بومی و عدم اتخاذ سیاست‌ها و روش‌های چابک‌تر، درست‌تر و با احتمال موفقیت بالاتر
• ضعف دانشی و تجربی عمده نیروهای انسانی در کشور برای حل مسائل پیچیده و زمان‌بر موجود در فرآیند حساس خدمت‌دهی رایانامه
• کمبود شدید و هزینه بالای نیروهای انسانی متخصص و با تجربه در زمینه‌های فنی (برنامه نویسی، شبکه، سخت افزار، معماری، پایگاه داده، امنیت و...)، مدیریتی (سطوح کلان و میانی) و بازاریابی (سطوح راهبردی و اجرایی)
• مشکلات یافتن نیروهای مدیریتی در سطوح کلان و میانی و نیز طراحان و مجریان راهبردهای بازاریابی مجرب و قوی
• هزینه‌های انبوه بخش‌های نرم‌افزاری، سخت افزاری، مرکز داده، مدیریتی، بازاریابی و پشتیبانی که به صورت جاری وجود دارند و به سرعت افزایش می‌یابند
• چالش پیدا کردن بهترین مرکز داده در کشور که پایداری، امنیت و پشتیبانی خوب و مناسبی در حد خدمت رایانامه داشته باشد (برای این منظور، باید بسیاری از کارهای زیرساختی شبکه را خودتان متحمل شوید تا درگیر مسائل مراکز داده داخلی نشوید؛ مثلاً برای جلوگیری از هرزنامه شدن و از بین رفتن اعتبار IPهای خدمت، باید شماره AS خود را از ابتدا تهیه کرد و...)
• لزوم صرف هزینه و زمان زیاد برای تحقیق و توسعه خدمات شبکه محتوارسان (CDN)، خدمات ابری و... (به دلیل اینکه به شکل مطلوبی در کشور وجود ندارد)
• باید ویژگی‌هایی در محصول وجود داشته باشد که اولاً حداقل‌های مورد نیاز و انتظار عامه کاربران را در مقایسه با خدمات رقیب داشته باشد (توسعه فناوری در حد نصاب قابل عرضه به مخاطبان)، و ثانیاً ویژگی‌ها و امکانات نوآورانه خاصی داشته باشد که کاربران را تشویق به استفاده از این خدمت کند و به خاطر این خدمات ارزش افزوده، کاربران جدید را جذب کرده و کاربران قدیمی‌تر را متمایل به تحمل سختی مهاجرت به خدمت موجود کرد.
• وجود انتظارات و اولویت‌های متفاوت میان به دو دسته مشتریان سازمانی و عمومی محصول رایانامه:
• سازمان­ها و شرکت­های داخلی: سهولت استفاده از رایانامه، امنیت سرویس، صیانت از اطلاعات کسب و کاری، پشتیبانی خوب و با کیفیت مطلوب
• کاربران (عموم مردم): سهولت استفاده از رایانامه، قابل اعتماد بودن رایانامه در خصوص صیانت از اطلاعات شخصی افراد، قدرت و دقت بیشتر در ارائه خدمات مرتبط با زبان فارسی، قدرت و دقت بیشتر در ارائه خدمات مرتبط با اطلاعات کشوری و محلی، ارایه امکانات متنوع در خدمت و جذابیت هرچه بیشتر آن، پشتیبانی خوب و با کیفیت مطلوب
• چنین تفاوت‌هایی، باعث می‌شود که بعضاً در نوع معماری فنی و طراحی و پیاده سازی امکانات و ویژگی‌های مورد نظر و اولویت‌دهی به هرکدام، تضادها و پیچیدگی‌هایی به وجود بیاید که ناچار باید مسیرهای متفاوتی را با توجه به شرایط موجود انتخاب کرد و میان کاربران عمومی و خوسته‌های آنها و کاربران سازمانی و شرکتی و دغدغه‌های ایشان، نهایتاً به یک سمت جهت‌گیری کرد.
• راه‌کارهای توسعه بازار، بازاریابی و درآمدزایی برای این دو دسته نیز نیاز به فعالیت‌ها، اقدامات و تلاش‌های گوناگونی دارد که شرکت را در مسیرهای جداگانه‌ای به حرکت وادار می‌کند؛ بنابراین، نیاز به دو یا چند برابر کردن نیروی انسانی، هزینه و غیره در این راه‌هاست (مثلاً مسأله شایع جا نیافتادن خدمت‌گیری به صورت ابری از خدمات دهنده است که به‌ویژه در سازمان‌های دولتی، سنتی و بزرگ به شکل گسترده‌ای دیده می‌شود).
• لزوم صرف وقت و هزینه فراوانی باید برای تغییر عقاید غلط به جای مانده از چارچوب‌های گذشته (گرچه متأسفانه در بسیاری از موارد این محافظه‌کاری نهادینه شده به راحتی زدوده نمی‌شود که هزینه‌ها و دردسرهای فراوانی در ارائه و پشتیبانی خدمت را به دنبال می‌آورد)
• ضرورت باز بودن بستر و تعامل داشتن با همه دیگر خدمات دهندگان کوچک و بزرگ (علاوه بر ادامه توسعه مداوم فناورانه و افزودن ویژگی‌ها و قابلیت‌های جدید)، چراکه بار ارائه خدمات جانبی و ارزش افزوده متنوع را از روی فراهم کننده بستر بر می‌دارد و می‌تواند پاسخگوی انواع نیازهای جدید کاربران گوناگون باشد.
• هیچ‌گاه نباید خطر ورود فناوری‌های دگرگون‌کننده جدید را فراموش کرد و این رقبا را دست کم گرفت (برای نمونه، اکنون پیام‌رسان‌ها نحوه تولید، توزیع و مصرف اطلاعات را به‌ویژه برای کاربران عمومی متحول کرده‌اند و دیگر رایانامه آن جایگاه سابق را برای دریافت و ارسال اطلاعات ندارد).
• باید همواره خود را با شرایط و فناوری‌های روز تطبیق داده و به‌موقع به تحقیق و توسعه و روزآمد کردن خدمات پرداخت، تا از این گردونه رقابت شدید و روزافزون خارجی و داخلی، به ناگاه بیرون انداخته نشویم.

همچنین در بخش ۴.۴ با عنوان «ملاحظات کسب و کاری لازم برای پیاده سازی یک خدمت رایانامه عمومی (با کاربران بالا)» به طور مفصل‌تری به این مسائل و نکات دیگری (به‌ویژه برای شرکت‌های نوپا) پرداخته شده است.

[1] https://www.nuodb.com/techblog/google-cloud-spanner-nuodb-comparison-distributed-acid-compliant-databases

[2] Open Source SIEM & Open Threat Exchange Projects