بهین ارتباط هوشمند تیلا
021-91002727

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

 

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

1) Logoff Script

در خصوص ارتباطات شبکه با اینترنت توسط کریو کنترل، یک سناریو ساده روزمره را در یک شرکت یا سازمان نظر بگیرید :
کاربری با نام User1 پشت یک سیستم قرار می گیرد و از پشت آن کامپیوتر وارد اینترنت می شود.
در نتیجه در کنسول کریو کنترل، در بخش Active Hosts مشابه تصویر زیر مشاهده می شود که کاربری با نام User1 از پشت کامپیوتری با نام PC1 ( و یا ip آن سیستم مثلاً 172.20.1.11 )  به اینترنت متصل شده است.

کاربرد Logon Script و Logoff Script در کریو کنترل

حال فرض کنید که پس از گذشت چند دقیقه، کاربر User1 کارش با سیستم و اینترنت تمام شده و از سیستم خود Log off می نماید و یا سیستم خود را خاموش می نماید.
مشکلی که در این مرحله وجود دارد این است که هنگام Log off نمودن کاربر از ویندوز، به صورت پیشفرض در محیط تنظیمات کریو کنترل هیچ اتفاقی رخ نمی دهد و و اصولا Log off نمودن کاربر از ویندوز، ارتباطی هم با کریو کنترل ندارد. لذا طبیعتاً به صورت پیشفرض کریو متوجه نمی شود که این کاربر ازویندوز Log off نموده است و ارتباط خود را با اینترنت قطع نموده است،
بنابراین در کنسول کریو در همان بخش Active Hosts همچنان مشاهده می شود که در سیستم PC1 ، کاربری به نام User1 همچنان به اینترنت متصل است!

حال یکی دیگر از کارمندان سازمان با نام User2 می آید و پشت همان سیستم قرار می گیرد و مرورگر را باز می نماید تا به اینترنت متصل شود، در این حالت کریو از این کاربر اطلاعات لاگین به کریو (Username & password اینترنت) درخواست نمی کند و لذا این کاربر جدید با استفاده از همان کانکشن کاربر قبلی و با اکانت همان کاربر قبلی به استفاده از اینترنت می پردازد !

ایراد این مطلب این است که تمام فعالیت هایی که این کاربر جدید (User2) انجام می دهد (تمام سایت هایی که باز میکند، کانکشن هایی که به محل های مختلف میزند و… ) همچنان به نام کاربر قبلی ثبت می شود!  همچنین از حجم و سهمیه (Quota) اینترنت کاربر قبلی استفاده و مصرف می شود که همه اینها مشکلاتی را برای کاربر قبلی (User1) ایجاد خواهد نمود.

برای رفع این مشکل می توانیم اسکریپت خاصی به نام Logoff Script ایجاد و در محلی صحیح در Group Policy دامین قرار دهیم و راه اندازی نمایم.

Logoff Script در واقع  یک اسکریپت یا batch file است که باعث می شود هنگامی که هر کاربر دامین، کارش با سیستم و با اینترنت تمام شده و از سیستم خود Logoff می نمایند، از داخل کریو کنترل نیز Logoff شود و کانکشن او با کریو قطع شود. لذا هنگامی که کاربر بعدی پشت همان کامپیوتر قرار می گیرد و می خواهد به اینترنت متصل شود، کریو اطلاعات لاگین و دسترسی به اینترنت را به صورت جداگانه از این کاربر جدید درخواست می نماید و وی می بایست اطلاعات ورود مجزای مربوط به خود را وارد نموده و جداگانه توسط کریو کنترل احراز هویت شود (بسیار عالی ! )
همچنین از این به بعد تمام فعالیت های اینترنتی که این کاربر جدید انجام می دهد، در لاگ ها و گزارشات به نام همین کاربر جدید ثبت می شوند و بدین شکل مسولیتی متوجه کاربر قبلی نخواهد بود و مشکل فوق رفع می شود.

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

نحوه ایجاد و استفاده از Logoff Script

در یک سیستم که تمامی کاربران شبکه از طریق شبکه با آن ارتباط داشته باشند ( مثلاً در file server و یا در خود دامین کنترلر ) ترجیحاً در ریشه یکی از درایوها یک فولدر ایجاد نموده و آنرا Share نمایید. ما جهت پیشگیری از پیچیدگی های غیر ضروری، در خود دامین کنترلر در ریشه درایو C فولدری با نام KerioScripts را ایجاد و share می نماییم و درون این فولدر دو عدد فایل text ایجاد نموده و طبق تصویر زیر اسم و پسوند آنها را Logoff.bat و Logoff.vbs تغییر می دهیم :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

طبق تصاویر زیر داخل هر یک از این دو فایل کدهای زیر را وارد می نماییم ( توجه داشته باشید که شما در شبکه خود می بایست آدرس ip اینترفیس LAN کریو خود و همچنین آدرس ip دامین کنترلر شبکه خود را وارد نمایید ) :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

 

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

 

 

همانطور که در تصویر زیر مشاهده می نمایید در ساختار شبکه تست ما، کاربر User1 و User2 درون OU به نام Staff (کارمندان) قرار دارند :

اما با توجه به اینکه راه اندازی Logoff Script مفید می باشد، پیشنهاد می کنیم آنرا در Policy که بر روی کل کاربران شبکه اعمال میشود تعریف نمایید، لذا تصمیم داریم این Policy را بر روی OU با نام All-People که حاوی اکانت تمام کاربران موجود در دامین (کارمندان معمولی ، مدیران، ادمین ها ، … ) است اعمال نماییم. لذا در کنسول Group Policy Management به مسیر زیر می رویم :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل
آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

مطابق تصویر زیر در سربرگ Scripts ، دکمه Add را میزنیم و در کادر باز شده ، آدرس دقیق فایل Logoff.bat را با فرمت UNC path وارد می نماییم ( شما می بایست به جای srv-2019 اسم و یا آدرس ip سیستمی که فولدر مربوطه را درون آن Share نموده اید وارد نمایید ) :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

نتیجه :

حال هنگامی که هر یک از کاربران دامین از سیستم خود Logoff می کنند، اسکریپت فوق (فایل Logoff.bat )  اجرا شده و طبق کد درون آن فایل Logoff.vbs و کدهای درون آن اجرا می شوند و باعث میشوند کاربر از کریو کنترل نیز Logoout شود.

2)  Logon Script

قبل از اینکه به معرفی Logon Script بپردازیم ذکر این نکته الزامی است که Logon Script بر خلاف Logoff Script کاربرد چندانی ندارد و اصولاً استفاده از آن به دلایل امنیتی که توضیح خواهیم داد توصیه نمی شود.

Logon Script نوعی اسکریپت یا bath file است که توسط آن میتوان تنظیم نمود تا زمانی که کاربران در پشت سیستم خود به دامین لاگین می کنند، به صورت اتوماتیک و در پس زمینه، نام کاربری و پسورد آنها به کریو کنترل نیز ارسال شود و در نتیجه به کریو نیز لاگین شوند و دسترسی اینترنت آنها از همان لحظه برقرار گردد. این کار با استفاده از مکانیسم NTLM Authentication  صورت می پذیرد.

سناریو :

فرض کنید در شبکه ای از ما درخواست می شود که برای برخی از کاربران (مثلاً مدیران ) تنظیمی انجام دهیم تا هنگامی که آن ها به سیستم خود لاگین می نماید، اطلاعات کاربری شان (Username & password)  در پس زمینه و بدون دخالت کاربر به صورت اتوماتیک به کریو کنترل ارسال شود و آن کاربر به صورت اتوماتیک در کریو کنترل نیز احراز هویت شود و به این ترتیب کاربر از همان ابتدای ورود به ویندوز، به کریو کنترل هم لاگین نموده است. لذا هنگامی که این کاربر مروروگر خود را باز می نماید تا به اینترنت متصل شود، کریو کنترل هیچ پیام و درخواستی مبنی بر درج username و password به او نمایش نمی دهد و کاربر به راحتی و به صورت پیشفرض به اینترنت متصل می باشد.

بنابراین کاربرد اصلی این نوع اسکریپت را می توان برای کاربرانی محسوب کرد که نیاز دارند به محض لاگین به سیستم، به صورت اتوماتیک به اینترنت نیز متصل شوند و نیاز به وارد کردن مجدد اطلاعات ورود به اینترنت نداشته باشند.

نحوه ایجاد و استفاده از Logon Script

همانند سناریو قبل درون همان فولدر KerioScripts دو عدد فایل text دیگر ایجاد نموده و طبق تصویر زیر اسم و پسوند آنها اینبار را Logoon.bat و Logon.vbs تغییر می دهیم :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

طبق تصاویر زیر داخل هر یک از این دو فایل کدهای زیر را وارد می نماییم ( توجه داشته باشید که شما در شبکه خود می بایست در فایل Logon.bat آدرس ip دامین کنترلر شبکه خود را وارد نمایید ) :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

توضیح : کدهای اسکریپت فوق باعث می شوند که هر بار که این کابران در پشت سیستم لاگین می کنند، مرورگر پیشفرض سیستم کاربر در بک گراند یک کانکشن http به وب سایت دلخواهی که شما URL آنرا در این فایل درج نموده اید ایجاد کند و در در نتیجه کریو username و password درخواست نماید و با تنظیماتی که در ادامه مقاله خواهید دید تنطیمی می کنیم که username و passwordی که کاربر با آن لاگین نموده است به طور اتوماتیک در بک گراند به کریو ارسال شود و کاربر در پس زمینه Authenticate شده و به اینترنت متصل شود !

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

به این دلیل که می خواهیم این Policy فقط بر روی افراد خاصی (مثلاً مدیران ) اعمال شود، آنرا در GPO که بر روی OU مدیران اعمال می شود تعریف می نماییم :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

این بار به قسمت Logon می رویم :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

سپس طبق تصویر زیر در سربرگ Scripts  دکمه Add را میزنیم و در کادر باز شده ، آدرس دقیق فایل Logon.bat را با فرمت UNC path وارد می نماییم ( شما می بایست به جای srv-2019 اسم و یا آدرس ip سیستمی که فولدر مربوطه را درون آن Share نموده اید وارد نمایید ) :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

توجه : انجام دو مرحله اضافه دیگر نیز الزامی است

جهت راه اندازی Logon Script  دو مرحله تنظیمات دیگر را نیاز می بایست به شرح زیر و در محل های دیگری انجام دهید، در غیر اینصورت Logon Script شما تاثیری نخواهد داشت.

1) انجام تنظیمات internet Explorer در GPO که بر روی کامپیوترهای مدیران اعمال می شود :

به این منظور در کنسول Group Policy Management  به GPO-Managers-Computers را باز و ویرایش می نماییم :

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

به مسیر دقیق زیر مراجعه می نماییم :

Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer >
Internet Control Panel > Security Page > Internet Zone

بر روی گزینه Logon options دو بار کلیک نموده و گزینه Automatic Logon using current username and password را انتخاب می نماییم.

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

2) غیرفعال کردن Force SSL Secured Connection در تنظیمات کریو کنترل

در صفحه  وب کریو کنترل نیز مطابق تصویر زیر در بخش Advanced Options، گزینه Force SSL secured connection (recommended) را غیرفعال نمایید:

آشنایی با کاربرد Logon Script  و Logon script در فایروال کریو کنترل

توجه : غیرفعال کردن این گزینه باعث می شود که مرورگر این کاربران هنگام متصل شدن به کریو کنترل، هشدار website’s security certificate contains invalid information را نادیده بگیرد و در وافع مکانیسم NTLM Authentication حتی در شرایطی که سرتیفیکیت کریو برای سیستم کاربر شناخته شده و trusted نباشد ( به عنوانمثال سرتیفیکیت های Self-Signed ) انجام شود.

ضمناً نقطعه ضعف امنیتی دیگری که در این حالت وجود دارد این است که نام کاربری و پسورد کاربران به صورت plain-text و رمز نشده به کریو کنترل ارسال می شود . باید اطمینان داشته باشیم که در شبکه مان میان کاربران و کریو کنترل، ارتباط ایمن و کنترل شده باشد.

چگونگی متصل شدن kerio Control به Active Directory

برای کنترل بهتر کاربران و تمرکز کاری، بهترین راه حل این است Kerio Control را به Active Directory شبکه خود متصل کنید تا مدیریت کاربران آسان تر خواهد شد.

برای اتصال Kerio Control به دومین کافیست از پنل سمت چپ وارد قسمت Domain and user Login شوید.سپس از سربرگ Directory Services شوید و بر روی گزینه Join Domain کلیک کنید.

connect to AD

در پنجره باز شده در قسمت Domain name نام دومین شبکه را وارد کنید.
در قسمت Kerio Control server name می توانید یک نام به دلخواه برای سرور Kerio Control در نظر بگیرید.
در قسمت Username و Password نام کاربری و رمز عبور دومین را وارد کنید.

connect to AD

در صورتی که Kerio Control نتواند دومین شبکه را پیدا کند از شما در خواست می کند که IP آدرس دومین شبکه را وارد کنید.
سپس بر روی Next کلیک کنید.

connect to AD

زمانی که Kerio Control بتواند با موفقیت به دومین شبکه متصل شود پیغام Successfully را نمایش می دهد.

connect to AD

حالا توانستید Kerio Control را به دومین متصل کنید.
برای اینکه مطمئن شوید Kerio Control کامل به دومین شبکه متصل شده است در همین صفحه در بالای صفحه چراغ سبزی را مشاهده می کنید که به منظور عضو بودن کریو به دومین شبکه می باشد.
یا اینکه می توانید در پایین صفحه در بر روی Test Connection کلیک کنید و وضعیت اتصال کریو را چک کنید.

connect to AD

هر زمانی هم که بخواهید اتصال Kerio Control را از دومین شبکه قطع کنید کافیست بر روی Leave Domain کلیک کنید.

connect to AD

سپس از شما درخواست نام کاربری و پسوردی که در هنگام اتصال کریو به دومین وارد کرده بودید را درخواست دارد.
در آخر بر روی Next کلیک کنید تا کریو از دومین شبکه خارج شود.

connect to AD

نحوه ی کانفیگ قابلیت  Intrusion Prevention در Kerio Control

در این مقاله می خواهیم به نحوه ی کانفیگ قابلیت  Intrusion Prevention در Kerio Control بپردازیم.با ما همراه باشید:

IPS) Intrusion Prevention System) سیستمی است که ترافیک را مورد تحلیل و بررسی قرار می دهد و ترافیک مخرب رو شناسایی می کند.IPS ای که در کریو کنترل مورد استفاده قرار میگیرید، Snort نام دارد.
در این قسمت می توانید مشخص کنید که بر روی ترافیک های مخرب چه عکس عملی را نشان دهد.IPS بر روی تمام Interface هایی که در گروه Internet Interface قرار دارد اعمال می شود و اینکه IPS قبل از Traffic Rule ها ترافیک ها را بررسی می کند.

نحوه ی کانفیگ قابلیت  Intrusion Prevention در Kerio Control

برای مشاهده Intrusion Prevention وارد پنل تحت وب Kerio Control شوید و از منو سمت چپ بر روی  Intrusion Prevention کلیک کنید.

نحوه ی کانفیگ قابلیت  Intrusion Prevention در Kerio Control

به صورت پیش فرض IPS فعال می باشد و بر روی وضعیت Enable قرار دارد.
برای غیر فعال سازی IPs می توانید تیک گزینه Enable Intrusion Prevention را غیر فعال کنید.
IPS داری ۳ سطح حساسیت میباشد و برای هر سطح می توانید مشخص کنید که در هر سطح چه عکس عملی را نشان دهد.

High Severity ترافیک های مخرب مانند تروجان را کریو کنترل Drop و لاگ برداری می کند.

Medium Severity ترافیک هایی که سطح حساسیت آن زیاد نباشد فقط لاگ برداری می کند.

Low Severity پایین ترین سطح ترافیک می باشد که بر روی وضعیت Do nothing قرار دارد.

نحوه ی کانفیگ قابلیت  Intrusion Prevention در Kerio Control

 در قسمت IP blacklist می توانید برای لیست IP هایی در Blocklist قرار گرفته اند مشخص کنید چه عکس عملی را نشان دهد. به این نکته توجه داشته باشید که شما نمی توانید لیست IP ها را مشاهده و یا تغییری دهید.
بر روی هرکدام دوبار کلیک کنید می توانید عکس عمل را مشخص کنید.
به صورت پیبش فرض هر ۲۴ ساعت یکبار این لیست آپدیت می شود، اگر می خواهید آپدیت را دستی انجام دهد کافیه بر روی Update now  کلیک کنید.
در قسمت Last Update Check هم میتوانید آخرین وضعیت آپدیت را مشاهده کنید.
فقط توجه داشته باشید به علت تحریم ها به صورت معمولی نمی توانید IPS, AtiVirus موجو در کریو را آپدیت کنید .

نحوه ی راه اندازی اولیه Kerio Control

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

Software Appliance

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

Virtual Appliance

نسخه از پیش نصب شده ای بر روی Hypervisor های عمومی مانند vMware و Hyper-V می باشد که در دسترس عموم قرار گرفته است.

Kerio Control Box

یک دستگاه سخت افزاری که بر روی آن نرم افزار kerio بطور پیش فرض بر روی آن نصب شده است.

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

سخت افزار مورد نیاز برای نصب:

CPU: 500 MHz

Memory: 1.5 GB RAM

Hard Drive: 8 GB HDD space for OS, product, logs and static data

برای اطلاع در مورد پیش نیاز های نصب در حالت Virtual Appliance به لینک زیر مراجعه نمایید.

Http://kerio.com/support/kerio-control#techspecs

فایل ISO کریو را نیز می توانید از این لینک دانلود کنید.

Http://kerio.com/support/kerio-control

نصب و راه اندازی اولیه

برای نصب کریو فایل دانلود شده در مرحله قبل را ر روی CD یا DVD رایت کنید و Boot سیستم را در حالت Automtic و یا  Boot from CD/DVD قرار داده و Wizard نصب را در حالت پیش فرض دنبال کنید. (نیاز به تغییر گزینه ای نیست.)

نکته: در طول مسیر نصب از شما یک IP آدرس خواسته می شود که این IP باید در رنج شبکه داخلی شما باشد تا از طریق آن بتوانید به پنل کریو دسترسی پیدا کنید. همچنین این IP در آینده به عنوان Default Gateway تمامی PC های موجود در شبکه شما استفاده خواهد شد.

برای راه اندازی اولیه کریو، پس از نصب آدرس زیر را در مرورگر خود وارد کنید:

Https://kerio-control-IP-address:4081/admin

حال پ از دنبال کردن Wizard به شکل زیر به پنل کاربری کریو دسترسی خواهید داشت.

1

3

              

نحوه ی بهبود امنیت Cisco Firewall

در این مقاله شما را با نحوه ی بهبود امنیت فایروال سیسکو (Cisco Firewall) آشنا می کنیم. با ما همراه باشید:

سری فایروال های 2100 شرکت سیسکو برای سازمان هایی که حجم بالایی از داده های حساس دارند طراحی شده است. شرکت سیسکو اخیرا خانواده فایروال های Cisco Firepower 2100 Next-Generation Firewall  که کارایی و امنیت بالایی دارند را معرفی کرد. در این سری از فایروال ها سعی شده تا یک تعادل نسبی میان عملکرد (Performance) و میزان حفاظت (Protection) ایجاد شود.

همچنین این خانواده از فایروال ها می توانند Throughput را به میزان 200% بیشتر نسبت به فایروال های پیشین ارائه دهند که این مزیت آنها را به گزینه ی مناسب برای قرار دادن میان Internet Edge و دیتاسنتر سازمان تبدیل می کند. همچنین سیسکو از نسخه های جدید ابزارهای مدیریتی  با کاربری آسان مربوط به فایروال از جمله Cisco Firepower Device Manager، Cisco Firepower Management Center و Cisco Defense Orchestrator  خبر داده است.

امروزه سازمان ها به سمت الگو های تجاری دیجیتال در حال حرکت هستند، و لذت راهکار های امنیت سایبری می بایست متناسب با نیاز سازمان ها و بدون تاثیر گذاری منفی بر روی عملکرد شبکه و برنامه های کاربردی باشند. این در حالیست که تاکنون اغلب فایروال ها Throughput شبکه را تا 50% کاهش می دهند. شایان ذکر است برای مواردی همچون بانکداری الکترونیک و تجارت الکترونیک که در آنها سازمان نیاز به کارایی و امنیت بالای شبکه دارد، فایروال های Cisco Firepower 2100 NGFW می توانند گزینه مناسبی تلقی شوند.

فایروال های جدید سری 2100  به سازمان ها این امکان را می دهند تا بدون نگرانی الگو های تجاری دیجیتالی نوین را دنبال کنند. این فایروال های جدید سیسکو (Cisco) می توانند تا 200% میزان Throughput بیشتری (حتی در زمانیکه  Inspection در حالت On قرار دارد) نسبت به محصولات مشابه رقبا ارائه دهند. تمامی فایروال های سری 2100 دارای Port Density برابر با 10GbE Connectivity و ابعاد جمع و جور 1RU می باشند.

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

Firepower Device Manager: ابزاری با محیط کاربری تحت وب که به کمک Set-Up Wizard خود می تواند دستگاه های NGFW را در عرض چند دقیقه پیکر بندی کند.
Firepower Management Center: ابزاری ساده برای مدیریت چندین Appliance بصورت همزمان.
Cloud Defense Orchestrator: این ابزار برای مدیریت Policy های امنیتی مختلف تحت بستر Cloud طراحی شده است. در حال حاضر CDO به خوبی از Web Security Appliance v.11 پشتیبانی می کند.

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

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

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

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

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

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

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

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

 

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

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

 

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

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

 

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

 

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

 

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

آموزش اضافه کردن (Join) یک سرور ESXi به دامین کنترلر (DC)

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

معرفی و آشنایی با Role های Exchange Server 2010

Exchange  دارایRole  مختلفی می باشد، که هر کدام وظیفه مشخصی را به عهده دارند، در این مقاله به تفکیک به بررسی هر کدام از اینRoleها در Exchange 2010 خواهیم پرداخت.

در Exchange 2010  پنج Role  با نام های زیر وجود دارد.

  • Mailbox Server Role

از این Role  برای نگهداری و مدیریت Mailbox  کاربران استفاده می شود.

  • Client Access Server Role

وظیفه این Role برقراری ارتباط کلاینت ها با Mailbox  خودشان از طریق پروتکل ها و دستگاه های مختلف می باشد، که شامل بخش های زیر می شود:

  • Outlook Web Application: وظیفه برقراری ارتباط با Mailbox از طریق وب
  • Exchange Active Sync: وظیفه برقراری ارتباط موبایل دیوایس ها به Mailbox
  • Outlook AnyWhere(RPC OVER HTTP): وظیفه برقراری اتصال برنامه Outlook به Mailbox  حتی بیرون از سازمان
  • POP3 Or IMAP: وظیفه برقراری ارتباط به Mailbox از طریق پروتکل های POP3 و IMAP
  • :Auto Discover وظیفه برقراری ارتباط کاربران شبکه داخلی با میل سرور به صورت خودکار

 

Client-Access-Role
  • Hub Transport Server Role

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

 

  • Edge Transport Server Role

وظیفه این Role  بسیار شبیه  Hub Transport  می باشد یا این تفاوت که این رول در محیط DMZ  شبکه برای افزایش امنیت قرار می گیرد و به صورت پیش فرض ماژول Anti-Spam بر روی آن فعال می باشد، که وظیفه تایید اعتبار ایمیل ها و بررسی فایل های ضمیمه شده در ایمیل ها به منظور ویروس یابی می باشد.

این Role  همیشه به صورت مستقیم باHub Transport   در ارتباط می باشد.

 

 

  • Unified Messaging Server Role

از این Role برای ترکیب ساختار VOIP و Exchange استفاده می گردد، با استفاده از Unified Messaging می توان تمامی ایمیل ها و Voice Mail های مربوط به کاربر را در یک Mailbox قرار داد و کاربر پس از راه اندازی این Role می توان از طریق Outlook Voice Access و با استفاده از تلفن ، موبایل و یا از طریق کامپیوتر به Mailbox خود دسترسی داشته باشد.

 

در نظر داشته باشید رول های MailBox,Client Access,Hub Transport, Unified Messaging  روی سرورهای Join  شده به دامین نصب می شود و می توان هر کدام از این Role  ها را روی  یک سرور و به صورت متمرکز یا به صورت تفکیک شده روی 4 سرور مجزا نصب کرد.

Edge Transport Rule  فقط روی سروری های Standalone  نصب می شود و نمی توان در کنار آن هیچ Role  دیگری نصب کرد.

 

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

(DomainKeys Identified Mail (DKIM پیچیده ترین پروتکل تصدیق ایمیل می باشد، این مقاله به صورت اختصاصی به معرفی پروتکل DKIM خواهیم پرداخت. با ما همراه باشید:

(DomainKeys Identified Mail (DKIM یک پروتکل است که به سازمان ها اجازه می دهد تا انتقال پیام را به گونه ای که توسط ارائه دهندگان ایمیل قابل تایید باشد، انجام دهند. این تاییدیه توسط احراز هویت رمزنگاری شده (Cryptographic authentication) و از طریق کلید های Public  و Private  انجام می پذیرد.

DKIM  کمی پیچیده می باشد، در ادامه سعی می کنیم، به زبانی ساده آن را برای شما شرح دهیم.

 

گام اول: شناسایی عناصر یک پیغام برای Sign در DKIM

یک فرستنده ایمیل ابتدا باید تصمیم بگیرد که کدام Elements های یک ایمیل را می خواهد در فرایند Sign  قرار دهد، آن ها باید تصمیم بگیرند که کل پیام (Header,Body) یا فقط یک یا چند فیلد خاص در هدر ایمیل در جریان این فرایند رمزنگاری قرار بگیرد.، Element هایی که قرار است در Sign DKIM  قرار بگیرند نباید در حین انتقال پیام تغییر کنند، در غیر اینصورت احراز هویت DKIM رد یا Fail  می شود.

برای مثال، اگر یک ایمیل از Yahoo  به Gmail   forward شود، یاهو یک متن در بالای ایمیل مانند (forward By yahoo mail)  اضافه می کند و Body  ایمیل دچار تغییر می شود، اگر Body  جز Element  های امضا شده در فرایند DKIM  باشد، احراز هویت در ایمیل Forward  شده Fail  خواهد شد.

با این حال، اگر تنها یک Element از Header مانند فیلد From در فرایند امضای DKIM قرار گرفته باشد، و ایمیل از Yahoo به Gmail  forward شود، احراز هویت DKIM  تایید می شود، زیرا آن بخشی از ایمیل که تغییر کرده است در فرایند امضای DKIM  قرار نگرفته بوده است.

گام دوم: فرایند رمزنگاری

فرستنده باید یک سری تنظمیات بر روی Platform ایمیل خود انجام دهد، که به صورت خودکار یک Hash از Element هایی که قرار است در فرایند Sign قرار بگیرند ساخته شود. فرایند Hash، متن را تبدیل به یک رشته متنی منحصر بفرد می کند.

<From: Ehsan Ataei <IT@PardisMail.com

Subject: Testing

:Maps to the following unique hash string

3303baf8986f910720abcfa607d81f53

قبل از ارسال ایمیل، رشته متنی Hash  شده با استفاده از Private Key  رمزنگاری می شود، کلید خصوصی از ترکیب نام دامنه و Selector (هر اسمی امکان پذیر می باشد، بیشتر بر اساس نوع کاربری ایمیل انتخاب می شود) ساخته می شود، که به شما این قابلیت را می دهد که چندین کلید خصوصی قانونی برای یک دامنه داشته باشید( که برای مدیریت ایمیل و اهداف امنیتی مهم می باشد)، و فقط فرستنده به کلید خصوصی دسترسی دارد. بعد از کامل شدن فرایند رمزنگاری ایمیل ارسال می شود.

 

گام سوم: تایید DKIM Signature با کلید عمومی:

Mail سرور گیرنده بعد از دریافت ایمیل، متوجه می شود که ایمیل دارای امضای DKIM  می باشد، که نشان دهنده نام دامین و Selector  است که فرایند رمزنگاری را امضا کرده اند، دریافت کننده ایمیل یک پرس و جو Query DNS برای پیدا کردن کلید عمومی براسا Domain\Selector  برای تایید امضا انجام می دهد.

کلید عمومی دارای خصوصیات منحصربفردی است که تنها با کلید خصوصی که ایمیل را امضا کرده است، مطابقت دارد،که به عنوان keypair match هم شناخته می شود، که ارائه دهندگان ایمیل را قادر به رمزگشایی امضای DKIM   و بدست آوردن رشته اصلی Hash میسازد.

ارائه دهندگان ایمیل  سپس با استفاده از Element های شرکت کننده در امضای DKIM دوباره یک Hash از این عناصر میسازد، سپس هش را با هش بدست امده از DKIM Hash مقایسه می کند، اگر دو Hash  با هم مطابقت داشته باشند، ما می دانیم که:

  • دامنه با امضای DKIM مالک ایمیل می باشد، در غیر اینصورت فرایند رمزگشایی در وهله اول کار نخواهد کرد.
  • عناصر ایمیل که توسط DKIM امضا شده بودند در هنگام ارسال تغییری نکرده اند (زیرا اگر تغییر کرده بودند، Hash ها با یکدیگر مطابقت نداشتند).

 

ارائه دهندگان ایمیل که امضای DKIM را تایید می کنند، می توانند از اطلاعات مربوط به امضاکننده به عنوان بخشی از یک برنامه برای کاهش حملات Spam,Spoofing و Phishing  استفاده کنند، هر چند که DKIM به دریافت کنندگان ایمیل برای انجام، اقدامی خاص کمک نمی کند، بستگی به پیاده سازی DKIM می توان اطمینان حاصل کرد که پیام در نقل و انتقالات دستخوش تغییرات بوده است یا خیر

 

مشکل DKIM این است که به دلیل اجرای سخت پیاده سازی، فرستنده های کمتری آن را قبول کرده اند، این نقطه ضعف بدان معنی است که عدم وجود امضای DKIM لزوما نشان دهنده جعلی بودن ایمیل نیست، بنابراین DKIM یک راه قابل اعتماد برای تایید هویت فرستنده نیست، علاوه بر این DKIM برای کاربر نهایی غیر فنی قابل مشاهده نیست، و هیچ کاری برای جلوگیری از جعل هویت Header From  دامین نمی کند.

DMARC، آخرین و پیشرفته ترین پروتکل در احراز هویت ایمیل می باشد و این مشکل را با تضمین اینکه دامنه قابل مشاهده برای کاربر نهایی همان دامنه ای است که توسط SPF و DKIM بررسی و تایید شده است حل می کند. علاوه بر این، ارائه دهندگان صندوق پستی را با دستورالعمل مشخصی در مورد اینکه کدام ایمیل ها باید توسط DKIM  احراز هویت شوند و کدامیک نه کمک رسانی می کند.

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

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

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

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

SPF(Sender Policy Framework)

،DKIM(Domain Keys Identified Mail)

DMARC(Domain-Based Message Authentication,Reporting & Conformance)

Two “From” Addresses:

پیغام های ایمیل شامل دو آدرس “from” هستند(Envelope from(return path or mfrom و (Header from(Friendly From.

Envelope from آدرس برگشتی است، و به میل سرورها مسیر بازگشت را می گوید، Enveloper from  در هدر پیام های ایمیل مخفی می باشد که شامل جزئیات فنی سرورها است، که برای فهمیدن اینکه چه کسی ایمیل را ارسال کرده و یا از چه نرم افزاری برای ساخت آن استفاده شده است.

آدرس Header from آدرس قرار گرفته در فیلد From می باشد که برای همه کاربران قابل مشاهده می باشد.

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

(SPF (Sender Policy Framework:

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

کمپانی های ارسال ایمیل رکوردهای SPF را در DNS منتشر می کنند، این رکوردها، لیست آدرس های IP مجاز برای ارسال ایمیل برروی دامنه ها را مشخص می کنند.

در طی بررسی SPF، ارائه دهندگان ایمیل،تایید رکورد SPF را با جستجو کردن نام دامنه ذکر شده درآدرس Envelope from را در DNS بررسی می کند، اگر آدرس IP ارسال ایمیل روی دامین در رکورد SPF نباشد، ایمیل دراحراز هویت SPF رد می شود.

یک دامین محافظت شده با SPF کمتر برای phishers جذاب می باشد، بنابراین کمتر به لیست های Spam اضافه می شود.

 

اما SPF دارای چند مشکل عمده می باشد.

  • فقط به این دلیل که یک پیام فاقد SPF است، به این معنا نیست که همیشه مسدود می شود، این یکی از چندین فاکتوری است که ارائه دهندگان ایمیل برای Spam در نظر می گیرند.
  • SPF هنگامی که یک پیام forward می شود، از بین می رود.
  • به روز نگه داشن رکوردSPF کمی زمانبر می باشد.
  • SPF نمی تواند هیچ کاری برای محافظت در برابر مجرمان اینترنتی که نام یا آدرس”Header from” را در پیغام خود جعل می کنند، انجام بدهد.

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

 در این مقاله به معرفی 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 می توانید این دیتاها را مرتب کنید تا سریعتر به دیتا مورد نظر برسید.

بررسی و درک Receive Connector های پیش فرض در Exchange Server 2016

وقتی که Exchange Server 2016 را نصب می کنید، پنج Receive Connector را مشاهده می کنید که به صورت پیش فرض ایجاد شده است. در این مرحله ممکن است برای شما سوال پیش بیاید که این کانکتورها چه هستند و کاربرد آنها چیست. دانستن این کانکتورهای پیش فرض برای درک کردن اینکه چگونه ایمیل به دست شما می‌رسد مفید است.

درک کانکتورهای دریافت پیش فرض در Exchange Server 2016
Exchange Server 2016 شامل دو Server Role به نامهای Mailbox Server Role و Edge Transport Server Role می باشد. Mailbox Server Role داری سه Transport Service (یا Sub Role) می باشد. این Transport Service ها Transport Pipeline نیز خوانده می شوند. ایمیل ها در بین این سه Pipeline حرکت می کند. سه Transport Service که به آن اشاره کردیم موارد زیر می باشند:
1- Front End Transport Service: این سرویس برای کلیه ایمیلهای ارسالی و دریافتی خارج از میل باکس های موجود در ایمیل سرور می باشد. این سرویس نقش صف دهی و بازرسی روی ایمیلها را ایفا نمی کند. وقتی ایمیلی از خارج سازمان می آید، اولین سرویسی که آن را دریافت می کند این سرویس می باشد. این سرویس ایمیل را به Transport Service منتقل می کند و به هیچ عنوان با Mailbox Transport به صورت مستقیم ارتباط برقرار نخواهد کرد.
2- (Transport Service (Hub Transport Service: این سرویس نقش گروه بندی و مدیریت صف ارسال و دریافت ایمیل را ایفا می کند. همچنین این سرویس بازرسی ایمیلها و بررسی آنها از لحاظ آنتی اسپم و anti-malware را انجام می دهد. این سرویس ایمیلها را از Front End Transport Service دریافت می کند و به Mailbox Transport Service منتقل می کند.
3- Mailbox Transport Service: این سرویس می باشد که در نهایت ایمیلها را دریافت و در میل باکس مرتبط قرار می دهد. این سرویس شامل دو زیر سرویس می باشد:
– Mailbox Transport Submission Service: این سرویس پیامها را از Mailbox Database دریافت می کند و آنها را به Transport Service منتقل می کند تا به مخاطب مورد نظر ارسال شود.
Mailbox Transport Delivery Service: این سرویس ایمیل را از Transport Service دریافت می کند و از طریق (RPC (Remote Procedure Call به میل باکس مورد نظر منتقل و در آن ذخیره می کند.
برای دیدن لیست Receive Connector به کنسول (Exchange Admin Center (EAC لاگین کنید و از منوی mail flow وارد receive connector شوید:

 

بررسی و درک Receive Connector های پیش فرض در Exchange Server 2016

همانطوری که در تصویر فوق مشاهده می کنید پنج Receive Connector در این لیست وجود دارد. تعداد سه کانکتور Frontend Transport Service و دو کانکتور Hub Transport Service وجود دارد. خب حال ببینیم که هر کدام از این کانکتورها چه کاری انجام می دهند.
1- Client Frontend HQ-MS1: این کانکتورها ایمیلهایی که به صورت امن شده از طریق TLS را دریافت می کند. پذیرش از طریق پورت 587 انجام می شود. این کانکتور توسط POP و IMAP استفاده می شود. این کانکتور کانکشنهای نرم افزاری IMAP و POP را به کانکتور Hub Transport Receive Connector بنام Client Proxy HQ-MS1 پروکسی می کند.
2- Default Frontend HQ-MS1: ایمیلهای ارسالی از طریق اینترنت توسط این کانکتور در پورت 25 پذیرفته می شوند. سپس این کانکتور ایمیلها را به Transport Service روی Hub Transport Service Receive Connector بنام Default HQ-MS1 روی پورت 2525 منتقل می کند.
3- Outbound Proxy Frontend HQ-MS1: اگر شما در Send Connector تیک مربوط به proxy through client access server option را زده باشید، سپس کلیه ایمیلهای خروجی توسط این کانکتور دریافت می شود. به زبان دیگر این کانکتور کلیه ایمیلهایی که توسط Transport Service ای که تیک proxy through client access server خورده باشد را دریافت می کند. اکنون ایمیلها توسط این کانکتور به اینترنت ارسال می شود. این کانکتور از طریق پورت 717 ایمیلها را دریافت می کند.

 

بررسی و درک Receive Connector های پیش فرض در Exchange Server 2016
4- Client Proxy HQ-MS1: این یک سرویس Hub Transport می باشد. ایمیلها را از Frontend Service دریافت می کند وبه Mailbox Transport Service منتقل می کند. این کانکتور از پورت 465 دریافت می کند. این Receive Connector کانکشن های POP و IMAP پراکسی شده را که از Frontend Transport Service بنام Client Frontend HQ-MS1 ارسال شده دریافت می کند.
5- Default HQ-MS1: این یک Hub Transport Service می باشد. این کانکتورهای ایمیلهای دریافتی را از Frontend Transport Service دریافت می کند و به Mailbox Transport Service منتقل می کند. مشابه همین، ایمیلهای ارسالی را از Mailbox Service دریافت می کند و به Send Connector جهت ارسال ایمیل به اینترنت یا دریافت از طریق کانکتور Outbound Proxy Frontend HQ-MS1 (در صورتی که تیک proxy through client access server در Send Connector خورده باشد) منتقل می کند. این کانکتور ایمیلها را از طریق پورت 2525 دریافت می کند.