فروش روتر ميکروتيک – برگه 2 – پشتیبانی VoIP|پشتیبانی شبکه|ویپ |تجهیزات شبکه

معرفی CDN و مزایای استفاده از آن

Posted on نوامبر 27, 2021 by tilatel

در این مقاله قصد داریم تا شما را با شبکه تحویل محتوا یا CDN آشنا کنیم با ما همراه باشید:

. Content Delivery Network یا شبکه تحویل محتوا که مخفف آن CDN می باشد، شبکه ای عظیم از سرور هایی می باشد که در نقاط مختلف دنیا برپا شده و به صورت جغرافیایی پخش شده اند. CDN چیزی است که علاوه بر هاست از آن استفاده می کنید؛ چون کمک زیادی به افزایش سرعت سایت می کند. CDN جایگزین هاست نیست! با وجود داشتن CDN باز هم شما به یک هاست نیاز خواهید داشت.

محتوای وبسایت ها با بکارگیری از شبکه تحویل محتوا و با توجه به موقعیت جغرافیایی کاربران از طریق نزدیک ترین شبکه به کاربران ارائه داده می شود. این شبکه ها در سرعت بخشیدن به تحویل محتوا و پهنای باند در وبسایت های بزرگ و جهانی تاثیر به سزایی دارند. یک شبکه ی توزیع محتوا یا CDN در اصل یک مجموعه از سرور ها در کشور های مختلف جهان می باشد که نسخه ای از وبسایت شما (شامل تمامی عکس ها و متن ها و کد های css و html و…) روی این شبکه وجود دارد و اگر از این شبکه استفاده کنید، زمانی که کاربران قصد وارد شدن به وبسایت شما را دارند درخواست شان به نزدیکترین سرور از نظر جغرافیایی ارسال می شود و صفحه ی وب سایت شما در سریع ترین زمان ممکن برای کاربر نمایش داده می شود.

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

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

سایت شما باعث می شود بار زیادی به سرور تحمیل شود که در نتیجه سرعت لود شدن سایت کند می شود و حتی سرور کرش می کند (از کار می افتد). اینجاست که اهمیت وجود CDN به چشم می آید.

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

شاید بپرسید محتوای استاتیک سایت شامل چه چیزهاییست؟

تصاویر، فایل های CSS که مربوط به قالب سایت هستند، جاوا اسکریپت ها، فلش و غیره. حالا اگر یک بازدید کننده به سایت شما بیاید (سرور اصلی) فن آوری AnyCast CDN او را به نزدیکترین سرور موقعیت مکانیش هدایت می کند.

در صورتی که CDN داشته باشید این شخص بجای انتقال به تهران، به POP موجود در تبریز منتقل می شود.

مثال برای مقایسه میزبانی بدون CDN در سمت راست تصور و با استفاده از CDN در سمت چپ تصویر:

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

مزایا استفاده از CDN

سرعت بارگذاری وب سایت و نمایش صفحات وبسایت با استفاده از شبکه ی توزیع محتوا به طور چشمگیری افزایش می یابد که باعث بالا بردن سئوی سایت و افزایش رتبه ی سایت در موتورهای جستجو مانند گوگل و یاهو می شود. این کار به این دلیل اتفاق می افتد که فشار ترافیک داده های وبسایت بر روی تنها یک سرور نمی باشد و چندین سرور یا شبکه همزمان با همکاری هم این کار را انجام می دهند.
بهبود SEO : گوگل به وضوح اعلام کرده که سایت های سریعتر رنک بالاتری در موتور های جستجو دارند.
امنیت وبسایت نیز با استفاده از شبکه ی توزیع محتوا یا CDN افزایش می یابد. شبکه های توزیع محتوا از Firewall بسیار قدرتمندی بهره مند می باشند که در کمترین زمان حمله هایی که به سایت شما می شود را تشخیص داده و آنها را نابود کرده و اجازه نمی دهند به وبسایت شما هیچ گونه آسیبی برسد.
نصب آسان و سریع
کاهش هزینه ها و افزایش پهنای باند : با استفاده از شبکه ی توزیع محتوا یا CDN می توانید تا حد بسیار زیادی در هزینه ها صرفه جویی کنید. زیرا این سرور ها و شبکه ها به صورت اشتراکی هستند و کاربران زیادی از آن به طور همزمان استفاده می کنند و شما دیگر لازم نیست که هزینه های زیادی برای خرید سرور های اختصاصی و هاست های جداگانه صرف کنید. در ضمن با استفاده از این شبکه از پهنای باند بیشتری هم بهره مند خواهید شد.

در حال حاضر شرکت های سرویس دهنده بزرگی این سرویس را به 2 شکل رایگان و تجاری عرضه کرده اند که می توان از سرویس های رایگان به CloudFlare و Coral CDN و در سیستم های تجاری به Amazon Cloudfront , Cach Fly , MaxCDN و ویندوز Azure اشاره نمود که سرویس های رایگان ذکرشده برای استفاده از تمامی امکانات آن ها باید از پلن های غیر رایگان آن ها استفاده کنید.

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

Posted on نوامبر 24, 2021مارس 27, 2022 by tilatel

در این مقاله قصد داریم شما را با نحوه ی افزایش امنیت وردپرس در مقابل نفوذ هکرها آشنا کنیم با ما همراه باشید:

هر سایتی که راه اندازی می کنید می تواند در معرض حملات توسط هکرها قرار داشته باشد و امنیت وب سایت شما به صورت 100 درصد نیست. در این مقاله به آموزش هایی برای افزایش امنیت سایت هایی که با سیستم مدیریت محتوا وردپرس پیاده سازی شده اند خواهیم پرداخت.

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

برای داشتن یک وب سایت با امنیت خوب چه کارهایی را باید انجام دهیم ؟

هر گونه پلاگین اضافه ، فایل و یا اسکریپت های اضافی در هاست خود را پاک کنید.
اگر سایت شما قبلا مورد نفوذ هکر ها قرار گرفته است ، راه نفذی قبلی آن ها را شناسایی و برطرف کنید.
تجربه های رایج سایر کاربران وردپرس در زمینه هک را در انجمن های مختلف جستجو کنید و آن ها را در سایت خود برسی کنید.
از تمام پلاگین ها و پوسته های موجود در وردپرس خود اطمینان حاصل کنید که غیر قابل نفوذ باشند. ( قبل از نصب پلاگین به امتیازآن در بین سایر کاربران توجه کنید )
پلاگین های خود را به روز رسانی کنید تا باگ ها و مشکلات آن بر طرف شود.
از امنیت کلمه عبور خود اطمینان حاصل کنید و اگر آن را قبلا به شخص دیگری داده اید آن را عوض کنید و ترجیحا از Password Generator استفاده کنید.

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

اولین مرحله ( سایت خود را اسکن کنید )

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

دومین مرحله (حذف کد های مخرب )

قبل از شروع این مرحله یک بک آپ کامل از سایت خود با استفاده از پلاگینی مانند Backup Buddy بگیرید که این پلاگین خود دارای یک اسکنر آسیب پذیر نیز می باشد . شایع ترین کدهای مخرب معمولا در پلاگین ها و یا پوسته ها یافت می شود ، اگر چه هسته اصلی وردپرس نیز گاهی اوقات تحت تاثییر این کدهای مخرب قرار می گیرند. هنگامی که تمام فایل های خود را بک آپ گرفتید و بر روی سیستم خود آن ها را داشتید ، فایل هایی مخربی که اسکنر به شما نشان داده است را باز کنید و بعد کدهای مخرب را پیدا کنید. پس از پیدا کردن کدهای مخرب آن قطعه کد را در اینترنت جستجو کنید و کد صحیح آن را پیدا کنید و آن را با کد فعلی خود جایگزین کنید و اگر نتیجه ای پیدا نکردید آن قطعه کد را پاک کنید. چنانچه قطعه کد های مخرب مورد نظر مربوط به پلاگین خاصی می باشد بهترین کار حذف آن پلاگین می باشد.

سومین مرحله ( آپلود فایل ها بر روی هاست )

پس از این که کد های مخرب را از بین بردید ، فایل های مورد نظر را با استفاده از یک FTP ( مانند FileZilla ) بر روی هاست خود بارگذاری کنید ، سپس مجددا سایت خود را توسط اسکنر مورد نظر خود اسکن کنید و برسی کنید که تعداد خطاها و کدهای مخرب از بین رفته است و یا کمتر شده است یا نه ! اگر تعداد خطاها ، کدها و یا فایل های مخرب کمتر شده بود شما چند مرحله پیشرفت کرده اید و می توانید دوباره سایر فایل هایی که توسط اسکنر به شما نشان داده شده است را برسی کنید. اگر مجددا همان تعداد خطا را مشاهده کردید نا امید نشوید و این بار با دقت بیشتری این کار را انجام دهید و در برسی خود در بین کدها بیشتر جستجو کنید و خطای کدهای خود را پیدا کنید.

چهارمین مرحله ( کلمه عبور های خود را عوض کنید )

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

کلمه عبور های زیر را عوض کنید :

DataBase
Wp Admin (مدیریت وردپرس )

برای امنیت بیشتر کلمه عبور هاست خود را نیز عوض کنید و همچنین بر روی مسیر مدیریت وردپرس خود نیز یک کلمه عبور تعریف کنید ( www.yoursite.com/wp-admin )

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

آیا این مراحل برای داشتن یک وب سایت با امنیت کامل کافی است ؟ خیر کامل شدن امنیت وب سایت شما شامل مراحل بسیار زیادی است که بسیاری از آن ها در تجربه های مختلف در این زمینه و همچنین شناسایی اولین راه نفوذ هکر ها می باشد ولی برای کاربری که اطلاعات زیادی در زمینه امنیت ندارد این چهار مرحله کمک بسیار زیادی می کند تا سایتی تقریبا مطمئن داشته باشند.

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

نحوه ی Join کردن یک سرور ESXi به دامین کنترلر (DC)

Posted on نوامبر 24, 2021 by tilatel

در این مقاله می خخواهیم نحوه ی اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC) را برای شما بازگو کنیم با ما همراه باشید:

برای اینکه بتوانید مدیریت آسان تر و امنیت بیشتری برای سرور ESXi فراهم کنیم بهتر است که سرور ESXi را به سرویس دامین کنترلر (Domain Controller) خود مثل دامین کنترلر مایکروسافت اضافه کنید :

اما قبل از شروع آموزش چه پیش نیازهایی باید از قبل رعایت شده باشه:

در ابتدا اینکه سرور ESXi شما باید توانایی Resolve کردن نام DNS و نام دامین رو داشته باشه.
نام سرور ESXi شما باید بطور کامل تنظیم شده باشه ، مثل esxi1.contoso.local.
ساعت هر دو سرور شما یعنی سرور ESXi و سرور DC باید یکسان باشه.

برای اضافه کردن و در واقع Join کردن یک سرور ESXi به دامین کنترلر ابتدا vSphere Web Client را باز کنید و Hosts and Clusters را از قسمت منوی Home انتخاب کنید.

سرور ESXi خودتون رو انتخاب کنید.

بر روی Join Domain کلیک کنید. مطابق شکل زیر مسیر را پیدا کنید.

نام کاربری و کلمه عبور مدیریت دامین خود را وارد کنید.

پس از اتمام عملیات، بررسی کنید که همه چیز درست انجام شده است.

در سرور اکتیو دایرکتوری خود به قسمت Users and Computers رفته و بررسی کنید که سرور ESXi شما اضافه شده است.

همانطور که در تصویر بالا مشاهده می کنید، یک سرور ESXi با نام ESXTEST1 به DC اضافه شد.

نحوه ی پاک و حذف کردن فایل های لاگ در Exchange 2013

Posted on نوامبر 23, 2021 by tilatel

در محیط Exchange 2013 شاید تعجب کرده باشید، که چرا Drive C یا پارتیشنی که Exchange را نصب کرده اید به سرعت پر می شود.

این ناشی از میزان لاگ های Exchange 2013 به صورت پیش فرض است.

از نسخه Exchange 2013 CU6 ، فایل هایی با پسوند .elt ساخته می شود، دراین نسخه فایل هایی با حجم 50MB با حداکثر تعداد 100 فایل ایجاد خواهد شد، که برای کسب و کار های کوچک ایده آل نیست.

از دیگر Feature ها که فایل های log هفتگی و روزانه ایجاد می کند Diagnostic logs (Health explorer) است، که می تواند فایل هایی بیش از 5 گیگ در هفته یا ماه ایجاد کند، که با توجه به محدودیت سخت افزاری ممکن است به این حجم از فضا نیاز داشته باشید.

از دیگر عوامل می توان به لاگ های IIS اشاره نمود ، این سرویس می تواند فایل هایی با اندازه 1 بیت تا بیش از 500MB ایجاد نماید.

در پایان، لاگ فایل هایی که می توانند مقداری از فضای شما را پر نمایند لاگ های HTTP Proxy هستند، این سرویس لاگ فایل هایی به صورت ساعتی از 4MB به بالا ایجاد می کند.

در این مقاله توضیح خواهیم داد این Logها را چگونه مدیریت نمایید، و در پایان یک اسکریپت PowerShell را معرفی خواهیم نمود که به صورت خودکار لاگ فایل ها را حذف خواهد کرد.

Diagnostic Logs (Health Manager)
ETL Files
IIS Logs
HTTP Proxy Logs

Diagnostic Logs:

Health Manager اطلاعاتی در مورد سلامتی سیستم جمع آوری می کند، که اطلاعت خوبی هم به شما ارائه می کند ولی اگر با محدودیت فضا مواجه هستید یا مثلا درایور شما دارای محدودیت 80GB می باشد و در چند روز آینده پر می شود، شما می توانید این ویژگی را غیرفعال نمایید.

Service.msc را باز نمایید.

سرویس Microsoft Exchange Health Manager Service را پیدا نمایید، سپس دابل کلیک و از بخش startup گزینه disabled را انتخاب نمایید، اگر سرویس در حالت Running است آن را Stop نمایید.

سرویس Microsoft Exchange Diagnostics Service را مانند مرحله بالا disable و stop نمایید.

در مرحله بعد Task Scheduler را باز کنید.

مسیر زیر را دنبال نمایید.

Microsoft -> Windows -> PLA

دو task ، همانند تصویر بالا مشاهده خواهید کرد، اول آنها رو Stop کنید و سپس disable نمایید، در مرحله بعد باید لاگ فایل های که توسط Diagnostics ساخته شده اند را پاک نمایید.

به مسیر زیر بروید:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostic

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

:ETL Files

این فایل ها معمولا هر ساعت با حجم تقریبی 50MB ساخته می شوند، به صورت پیش فرض در رجیستری 100 فایل ایجاد می کند، بعدا چگونگی تغییر این مقدار را آموزش خواهیم داد.

به مسیر زیر بروید:

C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces

مطابق شکل بالا، log فایل های زیادی وجود دارند، شما می توانید همه را انتخاب و بدون مشکل حذف نمایید، با این کار حدود چند گیگ از فضای شما خالی می شود.

در فولدرDiagnostics یکسری فولدر دیگر برای لاگ ها وجود دارد، مسیر زیر را دنبال نمایید.

C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs

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

تغییر در :Registry

شما می توانید مقدار پیش فرض 100 فایل لاگ را به مقدار دلخواهتان در رجیستری تغییر بدید.

Key: MaxTraceFileCount
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\16.0\Search\Diagnostics\Tracing

IIS Log Files:

لاگ فایل های IIS به صورت پیش فرض در مسیر C:\inetpub نوشته می شوند، شما همچنین می توانید این فولدر را به یک درایو دیگر انتقال دهید.

این فایل ها می تواند بالای 200MB از فضای شما را اشغال نماید، برای پاک کردن آنها به مسیر زیر بروید:

C:\inetpub\logs\LogFiles

در این فولدر شما دو فولدر دیگر با نام W3SVC1 و W3SVC2 مشاهده می کنید، فایل های log در این دو فولدر را هم می توانید پاک نمایید.

همچنین در مسیر زیر دو فولدر با نام های بالا نیز وجود دارند ، همانند بالا می توانید فایل های log در این دو فولدر را هم پاک نمایید.

C:\Program Files\Microsoft\Exchange Server\V15\Logging\RpcHttp

HTTP Proxy Logs

آخرین مسیری که شما می توانید لاگ فایل ها را مشاهده نمایید مسیر زیر می باشد:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy

در هر یک از فولدرهای مسیر بالا log فایل هایی تا سایز 10MB ساخته می شود که می توانید همه را پاک نمایید.

تبریک

شما اکنون توانستید چند گیگ از فضای هارد خود را آزاد نمایید.

PowerShell Script:

همچنین می توانید از اسکریپت زیر در Task Scheduler برای پاک کردن لاگ ها به صورت دوره ای استفاده نمایید.

آشنایی با پروتکل احراز هویت DMARC ایمیل

Posted on نوامبر 22, 2021 by tilatel

(DMARC (Domain-based Message Authentication, Reporting & Conformance آخرین و پیشرفته ترین پروتکل احراز هویت می باشد. اما مانند SPF و DKIM گاهی اوقات به درستی قابل درک نمی باشد.

DMARC تضمین می کند که ایمیل های قانونی به درستی در برابر استانداردهای DKIM و SPF تایید شده اند و فعالیت های جعلی از دامنه های تحت کنترل سازمان (دامنه های ارسال فعال، دامنه های ارسال نشده و دامنه های ثبت شده دفاع می کنند) مسدود شده است. دو مقوله اصلی DMARC، Alignment و Reporting هستند.

ویژگی DMARC Alignment از جعل کردن آدرس Header From جلوگیری می کند.

تطبیق نام دامنه در Header From با Envelope From در طی بررسی SPF
تطبیق نام دامنه در Header From با نام دامنه در امضای DKIM

نحوه کار DMARC:

برای پاس شدن DMARC، یک پیغام باید احراز هویت SPF و SPF Alignment و/یا احراز هویت DKIM و DKIM Alignment را پاس کند، یک پیغام در احراز هویت DMARC رد خواهد شد اگر در هر دو (1) SPF یا SPF Alignment و (2) DKIM یا DKIM Alignment رد شود.

DMARC به فرستنده ها اجازه می دهد تا به ارائه دهندگان ایمیل در مورد چگونگی برخورد با ایمیل های ناخواسته از طریق DMARC Policy کمک کند، تا هر گونه حدس و گمان در نحوه برخورد با ایمیل هایی که احراز هویت DKIM آنها Fail شده از بین برود، فرستنده ها می توانند:

نظارت بر همه ایمیل ها برای درک اکوسیستم احراز هویت ایمیل خود و اطمینان از اینکه ایمیل های قانونی به درستی تایید می شوند
قرنطینه پیغام هایی که در احراز هویت DMARC رد شده اند ( انتقال به فولدر Spam )
Reject کردن پیغام هایی که در احراز هویت DMARC رد شده اند.

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

DMARC اولین و تنها تکنولوژی است که می تواند از آدرسHeader From که کاربران در ایمیل خود می بیند محافظت نمایند، این کار نه تنها به محافظت مشتریان و سازمان کمک می کند بلکه مجرمان سایبری را دلسرد می کند چون کمتر به سراغ سازمانی که دارای رکورد DMARC است می روند.

نحوه ی ساخت و کانفیگ Relay Connector در Exchange Server 2016

Posted on نوامبر 21, 2021 by tilatel

در بسیاری از نرم افزارهای امروزی مانند Veeam Backup ، کنسول های آنتی ویروس، مانیتورینگ، نرم افزارهای CRM و … امکانی برای ارسال گزارشات به ایمیل گذاشته شده است، که نیاز به وارد کردن یک SMTP سرور دارد، امروز یاد می گیریم چطوری یک Relay Connector در Exchange ایجاد کنیم.

که این نرم افزار ها بتونن در شبکه داخلی بدون Authentication از SMTP سرور Exchange استفاده کنند.

روش اول از طریق PowerShell:

Exchange Managment Powershell را باز نمایید و مراحل زیر را دنبال کنید.

با دستور زیر ابتدا یک Receive Connector با نام Relay که فقط IP های 10.128.57.54 و 10.128.57.55 مجاز به استفاده از اون هستند می سازیم

New-ReceiveConnector -Name “Relay” -RemoteIPRanges (“10.128.57.54″,”10.128.57.55”) -TransportRole “FrontendTransport” -Bindings (“0.0.0.0:25”) -Usage “Custom” “-Server Servername.PardisMail.Com”

با دستور زیر در Receive Connector بالا که ساختیم اجازه استفاده از این Connector رو به همه یوزر ها می دهیم.

“Set-ReceiveConnector -Identity “Servername\Relay” -PermissionGroups “AnonymousUsers

با دستور زیر اجازه دریافت از هر گیرنده ای رو برای Receive Connector صادر می کنیم.

“Get-ReceiveConnector “Servername\Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient

روش دوم از طریق GUI

به قسمت Receive Connector در MailFlow بروید و روی + کلیک نمایید و مطابق شکل پیش برید:

رنج شبکه بالا رو پاک کنید و رنج IP هایی که قراره از Relay Connector استفاده کنند را وارد کنید.

بر روی Connector ساخته شده کلیک کنید و به قسمت Security رفته و تیک گزینه Anonymous users را بزنید.

حال باید Exchange Managment PowerShell را بازکنید و به Receive Connector اجازه دریافت از هر گیرنده ای رو صادر کنید.

“Get-ReceiveConnector “Servername\Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

کار تمامه فقط کافیه در Application های خودتون آدرسSMTP خودتون رو وارد کنید مانند شکل زیر در نرم افزار Veeam Backup & Replication

معرفی Protocol Logging در Exchange Server 2013

Posted on نوامبر 20, 2021نوامبر 20, 2021 by tilatel

در این مقاله به معرفی Protocol Logging در Exchange Server 2013 می پردازیم.با ما همراه باشید

پروتکل لاگینگ (Protocol Logging) کلیه رخدادهای SMTP بین ایمیل سرورها را ثبت می کند. این گفتگوهای SMTP بین Send Connector سرور ارسال کننده ایمیل و Receive Connector سرور دریافت کننده ایمیل در Front End Transport Services سرور Client Access، Transport Service روی Mailbox Server و Mailbox Transport Service روی سرورهای Mailbox رخ می دهد. از طریق پروتکل لاگینگ (Protocol Logging) می توانیم مشکلات مربوط به ارسال و دریافت ایمیل را مشخص کنیم.

به صورت پیش فرض پروتکل لاگینگ روی کلیه کانکتورهای مربوط به ارسال و دریافت غیرفعال می باشد. پروتکل لاگینگ به ازای هر کانکتورها قابل فعال یا غیرفعال شدن می باشد. سایر آپشن های مربوط به پروتکل لاگینگ روی کلیه کانکتورهای ارسال و کلیه کانکتورهای دریافت در Transport Service سرور تنظیم می شوند. فایلهای مربوط به پروتکل لاگها و پروتکل آپشن های همه Receive Connector ها یا همان کانکتورهای دریافت در یک Transport Service به صورت مشترک در یکجا ذخیره می شوند. این پروتکل لاگ ها و پروتکل آپشن ها با پروتکل لاگ ها و پروتکل آپشن های Send Connector های همان سرور متفاوت می باشد.
آپشن های ذیل برای پروتکل لاگ کلیه Send Connector ها یا Receive Connector های Transport Service روی Exchange Server قابل تنظیم می باشد:
– تعیین مسیر نگهداری فایلهای پروتکل لاگ مربوط به کانکتور ارسال و کانکتور دریافت.
– تعیین حداکثر سایز فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. حجم پیش فرض 10 مگابایت می باشد.
– تعیین حداکثر حجم فولدر مربوط به ذخیره سازی فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. حجم پیش فرض 250 مگابایت می باشد.
– تعیین حداکثر مدت نگهداری فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. مدت زمان پیش فرض 30 روز می باشد.
به صورت پیش فرض Exchange Server فایلهای لاگ را پس از حجم و زمان مجاز پاک می کند تا امکان مدیریت فضای هارددیسک فراهم شود.
یک Send Connector خاص به نام Intra-organization در هر سرور با رول Transport Service ایمیل سرورها و Client Access سرورها وجود دارد. این کانکتور به صورت پیش فرض ساخته می شود و نیازی به کانفیگ ندارد. کانکتور ارسال کننده intra-organization برای Transport Services های ذیل استفاده می شود:
– Transport Services روی Mailbox سرورها
o رله کردن ایمیل های ارسالی به Transport Service و Mailbox Transport Service روی سایر Exchange Server های 2013 در همان Organization
o رله کردن ایمیلهای ارسالی به سایر Exchange Server های 2007 یا 2010 در همان Organization
o رله کردن ایمیلهای ارسالی به Edge Transport سرور
– Front End Transport Services روی Client Access سرورها
o رله کردن ایمیل های ارسالی به Transport Service روی Mailbox Server Exchange 2013
Send Connector دیگری معادل همان Send Connector intra-organization به نام mailbox delivery send connector در Mailbox Transport Service سرورهای Mailbox وجود دارد. این کانکتور هم به صورت پیش فرض ساخته و کانفیگ می شود و به صورت مخفی می باشد. Mailbox delivery send connector برای رله کردن ایمیلهای ارسالی به Transport Service و Mailbox Transport Service در Organization استفاده می شود.
به صورت پیش فرض پروتکل لاگینگ برای این کانکتور نیز غیرفعال می باشد. شما می توانید از طریق کامند نسبت به فعال یا غیرفعال سازی پروتکل لاگینک اقدام نمایید.
ساختار فایلهای پروتکل لاگ
به صورت پیش فرض فایلهای پروتکل لاگ در مسیرهای زیر قرار دارد:
– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Mailbox Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Front End Transport Service روی Client Access

o servers %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ ارسال کننده برای Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

– فایلهای پروتکل لاگ ارسال کننده برای Mailbox Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend

– فایلهای پروتکل لاگ ارسال کننده برای Front End Transport Service روی Client Access

o servers %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend

فرمت نامگذاری برای لاگ فایلها در هر کدام از فولدرهای پروتکل لاگ به صورت prefixyyyymmdd-nnnn.log می باشد. متغیرها به صورت ذیل می باشند:
– متغیر Prefix برای کانکتور ارسال کننده SEND و برای کانکتور د ریافت کننده RECV می باشد.
– متغیر yyyymmdd نمایانگر زمان ایجاد فایل با فرمت UTC می باشد. متغیر yyyy برای سال، mm برای ماه و dd برای روز می باشد.
– متغیر nnnn برای ارزش تعداد فایلها در روز می باشد که از 1 شروع می شود.
اطلاعات در لاگ فایلها ذخیره می شوند تا جایی که حجم فایل به سقف مجاز خود برسد و سپس فایل جدیدی با شماره جدید ایجاد می شود. این پروسه در طول روز تکرار می شود. سیستم Circular Logging فایلهای تاریخ گذشته را حذف می کند وقتی که حجم فولدر از حد مجاز گذشته باشد.
پروتکل لاگ ها فایلهای TXT ای هستند که دیتاها را به صورت تقسیم بندی شده توسط Comma ایجاد نموده اند. هر پروتکل لاگ شامل Header ی می باشد که اطلاعات ذیل را در بر دارد:
– #Software نام نرم افزاری که فایل پروتکل لاگ را ایجاد نموده است. معمولا این اسم Microsoft Exchange Server می باشد.
– #Version ورژن نرم افزاری که فایل پروتکل لاگ را ایجاد نموده است. برای Exchange Server 2013 این مقدار 15.0.0.0 می باشد.
– #Log-Type مشخص می کند که فایل پروتکل لاگ مربوط به SMTP Receive Protocol Log می باشد یا SMTP Send Protocol Log
– #Date زمان ایجاد فایل را مشخص می کند.
– #Fields نام فیلد با کاما جداشده که برای فایل پروتکل لاگ استفاده می شود.
اطلاعاتی که در پروتکل فایل ذخیره می شود
پروتکل لاگ هر رخداد مربوط به SMTP را در یک خط جداگانه ذخیره می کند. اطلاعات ذخیره شده در هر خط توسط نام فیلد سازماندهی می شود. این فیلدها توسط کاما از هم جدا می شوند. در ذیل به بررسی فیلدهای مختلف می پردازیم.
– date-time زمان هر رخداد.
– connector-id نام Distinguished name (DN) کانکتور مربوط به آن رخداد
– session-id GUID که برای هر STMP Session یکتا می باشد اما برای کلیه رخدادهای مربوط به همان Session مشترک می باشد
– sequence-number شماره اندازی که از 0 شروع می شود و به ازای هر رخداد به مقدار آن افزوده می شود
– local-endpoint آیپی و پورت مربوط به مقصد لوکال که به صورت <ip address>:<port> می باشد
– remote-endpoint آیپی و پورت مربوط به مقصد اینترنتی
– event تک کاراکتری که رخداد پروتکل را معرفی می کند.

o + Connect

o – Disconnect

o > Send

o < Receive

o * Information

– Data توضیحات مربوط به رخداد SMTP
– Context اطلاعاتی متنی که احتمالا مرتبط به رخداد پیش آمده می باشد
یک گفتگوی ساده SMTP که برای ارسال یا دریافت می باشد، رخدادهای زیادی را در بر دارد در محل های مرتبط ذخیره می کند. این رخدادها در خطوط مختلف در لاگ فایلهای نوشته و ذخیره می شوند. مفدار زیادی گفتگوی SMTP برای ارسال یا دریافت ایمیل ممکن است به صورت همزمان انجام شود. که این باعث در هم آمیختگی متنهای داخل پروتکل لاگ می شود. شما از طریق session-id و sequence-number می توانید این دیتاها را مرتب کنید تا سریعتر به دیتا مورد نظر برسید.

آشنایی با Mail Flow و نحوه ی کانفیگ آن در Exchange Server 2016

Posted on نوامبر 17, 2021 by tilatel

در این مقاله قصد داریم تا شما را با Mail Flow آشنا کنیم با ما همراه باشید:

در این مقاله قصد آموزش نکات مهم در کانفیگ Mail Flow را داریم. همانطور که می دانید پس از نصب Exchange Server و بدون انجام هیچگونه تغییری در تنظیمات Mail Flow شما قادر به دریافت ایمیل از محیط اینترنت هستید. البته با فرض انجام صحیح تنظیمات مربوط به DNS External. اما امکان ارسال ایمیل به بیرون از سازمان خود را خود را ندارید که نیاز به ساخت یک Send Connector می باشد که در مقاله قبلی آموزش ساخت آن داده شد.
در این مقاله می خواهیم تنظیمات مهمی که می بایست در کانکتورها ارسال و دریافت انجام شود تا ارسال و دریافت ایمیل با موفقیت و دقت بیشتری صورت پذیرد را آموزش خواهیم داد.
در مورد Receive Connector های پیش فرض، در یک مقاله جداگانه به نام آشنایی با Receive Connector های پیش فرض در Exchange Server 2016 نوشته ایم که از طریق لینک مربوطه می توانید آن را مطالعه کنید. پس در این مقاله در مورد آن صحبت نمی کنیم.
هماهنطور که در مقاله قبلی ذکر شد پس از نصب Exchange Server 2016 در صورتی که تنظیمات مربوط به Port Forwarding و DNS External به درستی انجام شده باشد، دریافت ایمیل خواهید داشت. این اتفاق از طریق کانکتوری با نام Default Frontend SRV-EX2016 انجام می شود. بهتر است که امکان دریافت ایمیل از طریق این کانکتور غیرفعال شود و برای دریافت ایمیل از بیرون یک کانکتور جداگانه ایجاد شود.

همانطور که در تصویر فوق مشاهده می کنید ابتدا وارد منوی Mail Flow می شویم سپس از ساب منوی Receive Connector یک کانکتور جدید ایجاد می کنیم. یک نام برای Receive Connector انتخاب می کنیم. نقش آن را Frontend Transport انتخاب می کنیم و نوع آن را Internet انتخاب می کنیم.

در ادامه یک ایپی که در واقع آیپی سرور Exchange می باشد را مشخص می کنیم و ساخت Receive Connector را به اتمام می رسانیم.
پس از اتمام ساخت مجدد وارد Properties این کانکتور می شویم.

نکته مهمی که در تنظیمات Receive Connector باید رعایت کنید وارد کردن نام MX Record در قسمت FQDN می باشد. MX Record همان رکوردی ست که در DNS Server اکسترنال ساخته می شود و و مسئول مسیردهی ایمیل های ورودی به سرور ما می باشد.
همچنین در مقاله قبلی گفتیم که به صورت پیش فرض Send Connector ی برای ارسال ایمیل به اینترنت وجود ندارد. پس لازم است که Send Connector مربوطه ساخته شود که این مورد در مقاله قبلی با نام کانفیگ اولیه Exchange Server آموزش داده شد. در مورد Send Connector نیز مراحل بالا می بایست انجام شود. وارد کردن نام MX Record در Internet Send Connector نقش مهمی در اسپم نشدن ایمیل ها دارد.

Edge Transport چیست و چه مزایایی دارد

Posted on نوامبر 16, 2021 by tilatel

آیا در محیط خود به Exchange Edge Transport نیاز دارید؟

مایکروسافت نقش Edge Transport را ابتدا به عنوان یکی از پنج نقش اصلی در Exchange 2007 معرفی کرد و دوباره آن را در Exchange 2010 ارائه کرد. هدف از نقش Edge Server این است که ترافیک SMTP ورودی محدود به محیط DMZ شود، از آنجایی که بسیاری از اتصالات SMTP ورودی غیر قابل شناسایی هستند، برخی واحد های امنیتی اجازه ارتباط مستقیم این ترافیک ها را، به منابع شبکه داخلی شما نمی دهند(Exchange Server)، Edge Transport Server، به مشتریان این قابلیت را می دهد که بدون نیاز به خرید SMTP Gateway Appliance یک ایمیل سرور راه اندازی کنند.

برای امنیت بیشتر، سرورهایی که نقش Edge Servers را اجرا می کنند Join به دامین داخلی مربوط به Exchange Organization شما نمی شوند و همینطور قادر به نصب آن در کنار دیگر Role های Exchange نیستیم، این امکان وجود داردکه Edge Server را Join یک دامین در شبکه DMZ کنید که بتوانید از Group Policy و تنظیمات امنیتی مشترک استفاده کنید، اما اکثر مشتریان Active Dirctory را در محیط DMZ خود قرار نمی دهند.

سرورهای Edge می توانند به عنوان اولین خط دفاعی شما در برابر نرم افزارهای مخرب SMTP و انکار سرویس ها (DOS,DDOS) به عنوان نقطه ورود SMTP عمل نماید. Edge Transport Role با ایمیل سرور داخلی از طریق Edge Subscription کار می کند، Edge Subscription یک اتصال متقابل معتبر و رمزگذاری شده بین سرورهای Edge و سرورهای داخلی Exchange فراهم می کند، برخی از مزایای امنیتی دیگر Edge عبارتند از:

بیشتر تنظیمات Edge Transport بر روی سرورهای داخلی Exchange انجام می شود و این پیکربندی با استفاده از فرایندی به نام EdgeSync انجام می شود، اگر یک Edge Server به هر نحوی در معرض خطر و نفود قرار بگیرد، پیکربندی Edge Transport قابل تغییر نمی باشد.
قابلیت پیشرفته Anti-Malware با استفاده از Recipient Filtering، کمی جلوتر توضیح خواهم داد.
کاهش حملات Harvest با استفاده از Tarpit، Tarpitروشی است که Edge Transport برای پاسخ دادن به دستورات نامعتبر و Recipient ها به یک مدت مشخص(پیش فرض 5 ثانیه) پاسخ های خود را به تاخیر می اندازد، این رفتار به شدت اثرات انکار سرویس و حملات Harvest را کاهش می دهد.
تمام ارتباطات Edge Sync با استفاده از گواهینامه Self-Sign Exchange، احرازهویت و رمزنگاری می شود.
تمام ارتباطات بین Edge و سرورهای Exchange داخلی از TLS Encryption استفاده می کند.

مایکروسافت موقع ارائه Exchange 2013 RTM در تاریخ 11 اکتبر 2012، آن را بدون نقش Edge Transport منتشر کرد، مشتریانی که تمایل به کنترل SMTP ورودی داشتن می توانستن از Edge Transport 2007 یا 2010 به عنوان SMTP Front-end در Exchange استفاده کنند

در Exchange 2013 SP1 دوباره نقش Edge 2013 معرفی شد و مشتریان می توانستند تمامی سرویس های ایمیل خود را به 2013 ارتقا دهند،Edge Transport ساختار اصلیش مشابه ورژن های قدیمی است اما رابط کاربری ندارد، Edge 2013 با استفاده از Exchange Management Shell مدیریت می شود و دیگر نیازی به راه اندازی IIS نیست، در حقیقت، تنها نرم افزار پیش نیاز برای نصب .Net Framework 4.5 و نقش AD LDS است.

Exchange 2013/2016 Mailbox Servers دارای Anti-Malware Protection است اما سرورهای Edge Transport به شما Recipient Filtering را ارائه می دهند، Recipient Filter Agent تمامی پیام هایNon-Authentication از طریق اینترنت را پردازش می کند و با آنها مثل پیام های خارجی رفتار می کند، این کار به Edge سرور اجازه می دهد تا کارهای زیر را انجام بدهد:

Recipient Blocking به مدیران اجازه می دهد تا SMTP Senders یا Sender Domain خاصی را Block کنند.
Mailbox های مهم را می توان فیلتر کرد تا هرگز از اینترنت ایمیلی دریافت نکنند.
Edge Transport می تواند ایمیل های ورودی بهDistribution List ، که فقط برای دریافت ایمیل از کاربران داخلی پیکربندی شده است را مسدود کند.

توجه داشته باشید که Recipient Filtering در سرورهای Exchange Mailbox هم نصب می باشد، ولی نباید آن را پیکر بندی کنید، سرورهای Mailbox قادر به تشخیص پیام های خارجی نیستند واگر یک پیام مشکوک شناسایی شود، کل پیام را مسدود می کنند.

نحوه ی نصب و پیاده سازی Certificate در Exchange Server 2016

Posted on نوامبر 16, 2021 by tilatel

در این مقاله قصد داریم تا ابتدا به بررسی انواع Trust Certificate ها و سپس به کانفیگ و نصب Certificate بر روی ایمیل سرور بپردازیم.با ما همراه باشید:

انواع Trust Certificate:
• Standard
فقط برای یک آدرس مشخص خریداری می شود مانند https://mail.tilatel.com یا https://tilatel.com
• Wildcard
برای یک دامنه به همراه subdomain مانند https://mail.tilatel.com یا https://crm.tilatel.com
• SAN(Subject Alternative Names)
برای استفاده در چندین دامنه کاربرد دارد، فرض کنید شرکت یا سازمان شما دارای دامنه های pardismail.com،pardismail.ir و pardismail.org هست، بهترین راه برای خرید certificate استفاده از SAN Certificate هست که می تواند همه این دامنه ها را پوشش بدهد به جای اینکه اقدام به خرید چند دامنه کنیم.

مراحل نصب و کانفیگ certificate در exchange
• ساخت یک فولدر share در شبکه برای ذخیره اطلاعات
• ایجاد یک CSR در ایمیل سرور
• استخراج Certificate خروجی و خرید Certificate
• Import کردن Certificate و Assign کردن به سرویس های میل سرور
در مرحله اول یک فولدر در شبکه ایجاد نمایید و در تب sharing، قسمت Advanced sharing را انتخاب و به everyone مجوز full control بدهید و سپس در تب Security مجوز NTFS برای گروه Exchange Trusted Subsystem را بر روی Full Control قرار بدهید.
مرحله دوم ایجاد یک Requset Certificate:
مطابق شکل زیر بر روی + کلیک نمایید.

سپس در wizard باز شده گزینه create a request را انتخاب و بر روی Next کلیک نمایید.

در این صفحه در فیلد friendly یک نام برای این certificate انتخاب کنید(این نام فقط برای نمایش در کنسول است و بهتر است در صورتی که دارای چند certificate هستید نامی را انتخاب کنید که بعدا بتوانید certificate خود را به راحتی پیدا کنید) و بر روی next کلیک کنید.

در صفحه زیر در صورتی که قصد تهیه یک wildcard certificate را دارید انتخاب و اسم دامنه خود را وارد کنید، در غیر اینصورت بدون هیچ تغییری بر روی next کلیک کنید.

در صفحه بعد یکی از سرور های میل سرور را برای ذخیره سازی request انتخاب کنید(در صورتی که چندین سرور برای میل سرور خود راه اندازی کرده باشید).

در صورتی که wildcard را انتخاب کرده باشید این صفحه را مشاهده نخواهید کرد، در غیر اینصورت سرویس هایی را که قصد ایمن کردن آنها را دارید انتخاب کنید.

در صفحه بعد شما قادر به مرور مجدد نام های پیشنهادی در certificate request هستید، در صورت نیاز قادر به اضافه کردن و حذف کردن هستید، بر روی Next کلیک نمایید.

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

در صفحه بعد مسیر فولدری که برای ذخیره در مرحله اول ایجاد کردید را وارد نمایید.

در مرحله سوم باید به یکی از سایت های معتبر خرید SSL مراجعه کنید ، پس از خرید، فایل های خروجی را در مسیر share قرار دهید.
مطابق شکل زیر بر روی Certificate Request که در حالت Pending request کلیک و در پنل سمت چپ بر روی Complete کلیک نمایید.

در صفحه باز شده مسیر share فولدری را که فایل cer را قرار داده اید را وارد نمایید و بر روی OK کلیک نمایید، اکنون Certificate بر روی میل سرور نصب شده است.

در مرحله بعد Certificate را انتخاب و گزینه ویرایش را بزنید در صفحه باز شده از سمت چپ بر روی Services کلیک نمایید و سرویس های مورد نظر را انتخاب و بر روی save کلیک نمایید.

کار تمام است و اکنون قادر به استفاده از میل سرور به صورت امن بر روی پروتکل SSL هستید.

نحوه ی نصب و کانفیگ آنتی اسپم در Exchange Server 2016

Posted on نوامبر 14, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی نصب و کانفیگ آنتی اسپم در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

در exchange server 2010 موقع فعال سازی Anti Spam به راحتی قادر به مدیریت این ماژول در کنسول EMC بودید، ولی از نسخه 2013 به بعد این امکان حذف گردید و فقط طریق Powershell امکان مدیریت آن مهیا است.

به صورت پیش فرض Anti Spam در سروری که دارای رول Mailbox است، نصب نیست و شما باید در ابتدا از طریق پاورشل آن را نصب نمایید.

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1

دستور بالا موجب اجرا شدن یک اسکریپت برای نصب Anti Spam می شود، بعد از نصب شدن نیاز هست که یکبار سرویس Microsoft Exchange Transport Service را ریستارت کنید، پس دستور زیر را در پاورشل اجرا کنید.

Restart-Service MSExchangeTransport

حال که Anti Spam نصب شد باید شروع به کانفیگ کنیم پس Exchange Management Powershell را باز کنید.

در این مرحله ابتدا سرورهای Exchange را به Anti Spam Agent معرفی کنید:

Set-TransportConfig -InternalSMTPServers 192.168.1.1

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

Set-TransportConfig -InternalSMTPServers 192.168.1.1, 192.168.1.2

مرحله دوم تنظیم IP Blocklist Provider

IP Blocklist Provider نوعی خاص از ارائه دهندگان سرویس DNS هست که مدیران می‌توانند از آن برای کاهش Spam ها استفاده کنند، به زبانی ساده تر یک سری سایت ها هستند که شامل یک دیتابیس بروز از Spammer ها هستند و زمانی که exchange یک درخواست از بیرون دریافت میکند از طریق ارسال DNS Query به این Provider امکان شناسایی Spammer ها رو فراهم می کند.

یکی از معروف ترین سایت ها در این زمینه spamhaus.org هست، برای انجام تنظمیات دستور زیر را اجرا کنید.

“Add-IPBlockListProvider -Name “SpamHaus IP Block List Provider” -LookupDomain “zen.spamhaus.org

برای ارسال یک پیغام به فرستنده در صورتی که ارسال کننده به عنوان یک Spammer شناخته شده باشد از دستور زیر استفاده کنید.

Set-IPBlockListProvider “SpamHaus IP Block List Provider” -RejectionResponse “Your message was rejected because the IP address of the server sending your message is in the block list of pardismail.com IP Block List Provider service. No soup for you.”

برای track کردن کارهایی که Anti Spam Agent انجام می‌دهد دستور زیر را اجرا کنید.

set-TransportService Mailboxserver -AgentLogPath “D:\spamlogs” -AgentLogMaxFileSize 30MB -AgentLogMaxDirectorySize 250MB -AgentLogMaxAge 7.00:00:00

بسته به نیاز و چارچوب های سازمانتان مقادیر رو تغییر بدید.

برای فیلتر کردن ایمیل ها بر اساس محتوا:

Set-ContentFilterConfig -Enabled $true

در صورت بروز مشکل در Anti Spam Agent آن را غیر فعال کنید.

Set-ContentFilterConfig -Enabled $false

Anti Spam Agent ایمیل های دریافتی را بر اساس میزان سطح اعتماد تقسیم بندی و از 0 تا 9 به آنها مقداری می‌دهد که به SCL معروف است، که هرچه این میزان به 9 نزدیک تر باشد احتمال Spam بودن ایمیل بیشتر است.

Set-ContentFilterConfig -SCLDeleteEnabled $true -SCLDeleteThreshold 9 -SCLRejectEnabled $true -SCLRejectThreshold 7 -SCLQuarantineEnabled $true

با دستور بالا می توانید مشخص کنید بر اساس SCL چه رفتاری با ایمیل شود، و با دستور زیر هم می‌توانید یک پیغام سفارشی در صورتی که ایمیل Reject شد به فرستنده ارسال کنید.

Set-ContentFilterConfig -RejectionResponse “hey Mr that email was spammy!”

در صورتی که ایمیل های دریافتیتان از دامین یا آدرس خاصی بلاک و به عنوان اسپم شناخته می‌شود با دستورات زیر می توانید عمل Trust را انجام بدید.

Set-ContentFilterConfig -BypassedSenderDomains <SmtpDomainWithSubdomains>

Set-ContentFilterConfig -BypassedSenderDomains example.com

Set-ContentFilterConfig -BypassedSenderDomains *.example.com

Set-ContentFilterConfig -BypassedRecipients <SmtpAddress>

Set-ContentFilterConfig -BypassedSenders trust@sample.com

Set-ContentFilterConfig -BypassedSenders trust@sample.com, trust1@sample.com

نحوه ی کانفیگ کردن SPF Record در Exchange Server 2016

Posted on نوامبر 14, 2021نوامبر 14, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی کانفیگ کردن SPF Record در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

SPF مخفف Sender Policy Framework به معنی چارچوب سیاست فرستنده می باشد. پس از ارسال ایمیل از یک ایمیل سرور و قبل از دریافت ایمیل توسط ایمیل سرور مقصد، سروری در اینترنت با نام Sender ID Framework مسئول بررسی اعتبار سرور ارسال کننده ایمیل می باشد.

یک SPF (Sender Policy Framework) Record لیست Mail Server هایی می باشد که مجاز هستند از طرف و به اسم دامنه سازمان شما به بقیه میل سرورها میل ارسال کنند.
این رکورد باعث کاهش فعالیت Spamming از طرف اسم دامنه سازمان شما می شود. یعنی هر میل سروری مجاز به استفاده از دامنه ما برای ارسال ایمیل نمی باشد.

SPF Record یکی از انواع رکوردهای DNS Server می باشد که معمولاً با پسوند txt در DNS Server ساخته می شود. اما ساخت SPF Record دارای اصولی می باشد که ما برای اطمینان از صحت ساخت آن می توانیم از طریق سایتهای معتبر در اینترنت نسبت یه ایجاد آن اقدام کنیم. یکی از معروف ترین سایتهای SPF Generator سایت www.spfwizard.net می باشد.

– برای ساخت SPF Record نام دامین مورد نظرمان را در قسمت Your Domain وارد می کنیم.
– فیلد بعدی (Allow servers listed as MX to send email for this domain) برای مشخص سازی این مطلب می باشد که آیا MX Record های ثبت شده در DNS Server اجازه ارسال ایمیل دارند یا خیر. در اکثر مواقع MX Record ها مسئول ارسال ایمیل نیز می باشند، اما شاید در شبکه ای IP مربوط به MX Record صرفاً برای دریافت ایمیل باشد و IP دیگری مسئول ارسال ایمیل باشد، پس بر اساس سیاست داخلی شبکه این گزینه را انتخاب می کنیم.
– فیلد بعدی : (Allow current IP address of the domain to send email for this domain) جهت مشخص کردن این مطلب می باشد که آیا A Record های تعریف شده در DNS Server دامین، مجاز به ارسال ایمیل می باشند یا خیر. این مورد نیز کاملاً وابسته به نوع شبکه می باشد، ولی معمولاً A Record ها مربوط به هاستینگ وب سایت ما می باشد و در صورتی که ما ایمیل سرور داخلی داشته باشیم، A Record ها مجاز به ارسال ایمیل نمی باشند.
– فیلد بعد: (Allow any hostname ending in yourdomain.com to send email for this domain) جهت مشخص سازی این مطلب می باشد که آیا هر رکوردی با پسوند yourdomain.com برای مثال ftp.yourdomain.com مجاز به ارسال ایمیل از طریق این دامین می باشد یا خیر، که در اکثر مواقع جواب این فیلد خیر می باشد.
– در فیلد بعدی : (IP addresses in CIDR format that deliver or relay mail for this domain) می توانیم IP آدرس هایی که مجاز به ارسال ایمیل با دامین مورد نظر ما می باشند را تعیین کنیم. این آدرس IP میتواند یک تک IP و یا یک رنج IP باشد.
– در فیلد : (Add any other server hostname that may deliver or relay mail for this domain) می توانیم سایر سرورهایی که مجاز به ارسال ایمیل از طرف دامین اصلی ما می باشند را تعریف کنیم. این قسمت برای زمانی می باشد که شما بخواهید به یک دامین اجازه ارسال از چند سرور مختلف که برای شما می باشد را بدهید. برای مثال شما مالک چهار دامین مختلف می باشید که هر کدام به صورت مستقل امکان ارسال ایمیل را با MX Record های خودشان دارند اما می خواهید اگر با MX Record یکی دیگر از دامین هایتان نیز ارسال شد مشکلی پیش نیاید. این موضوع معمولاً به ندرت پیش می آید. در صورت نیاز می توانید NS های سایر دامین هایتان را در این قسمت وارد نمایید.
– فیلد : (Any domains that may deliver or relay mail for this domain) کاملاً مشابه با فیلد بالا می باشد با این تفاوت که در فیلد بالا NS های مجاز را تعریف می کنیم و در این فیلد Domain Name های مجاز را تعریف می کنیم.
– فیلد : (How strict should be the servers treating the emails?) میزان شدت سخت گیری SIDF را تعیین می کند. به این صورت که می توان میزان سخت گیری را به حداکثر رساند (Fail (Not (compliant will be rejected) که در این صورت اگر شرایط تعیین شده شما در SPF رکود Pass نشود ایمیل به مقصد نخواهد رسید و برگشت می خورد، یا میزان سخت گیری را در حال متوسط (SoftFail (Not compliant will be accpted but marked) قرار می دهیم که در این صورت ایمیل به مقصد می رسد اما به صورت اسپم به آدرس مقصد می رسد و یا سخت گیری را در حالت حداقل (Neutral (Mails will be probably accepted)) قرار می دهیم که در این صورت، در هر حالت ایمیل به مقصد می رسد. این مورد نیز به سیاست ایمیل سرور شما مربوط می شود اما از لحاظ منطقی بهتر است شرایط را در حداکثر سخت گیری قرار می دهیم.
همانطور که در طی ساخت SPF Record مشاهده نمودید، خروجی نهایی یک خط متن می باشد. متن نهایی را به صورت یک TXT Record در DNS Server ایجاد کنید.
نحوه ساخت SPF Record در DNS مایکروسافتی:
در کنسول DNS، Zone مورد نظر خود را انتخاب کنید و در قسمت رکورد ها کلیک راست و بر روی Create another Recordکلیک نمایید و text را انتخاب و Create Record بزنید.

در پنجره جدید در قسمت Text متن رکورد SPF خود را وارد نمایید و بر روی Ok کلیک نمایید.

و در انتها مشاهده خواهید کرد رکورد SPF شما ایجاد شده است.

بهین ارتباط هوشمند

برچسب: فروش روتر ميکروتيک