<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های armprzd</title>
        <link>https://virgool.io/feed/@armprzd</link>
        <description>آرمین پورآزاد</description>
        <language>fa</language>
        <pubDate>2026-06-16 15:54:05</pubDate>
        <image>
            <url>https://static.virgool.io/images/default-avatar.jpg</url>
            <title>armprzd</title>
            <link>https://virgool.io/@armprzd</link>
        </image>

                    <item>
                <title>Active Directory Security Best-Practices</title>
                <link>https://virgool.io/@armprzd/active-directory-security-best-practices-bpzg4ihce2iv</link>
                <description>تقریبا دیگه شرکت یا سازمانی رو نمیشه پیدا کرد که از ساختار متمرکز اکتیو دایرکتوری به جهت پیاده سازی Identity Infrastructure استفاده نکرده باشه.فعلا تو این قسمت از نوشته خیلی مختصر و تیتر وار و بدون ذکر توضیحات اضافه میخوایم بدونیم که حداقل موارد مهم امنیتی که باید تو هر ساختار اکتیو دایرکتوری رعایت بشه تا از آسیب پذیری های مهم جلوگیری کنه چه مواردی هست.تو قسمت های بعدی قطعا موارد جدید رو اضافه میکنم و هر مورد رو با جزییات بیشتر شرح خواهم داد که چرا باید این تنظیم انجام بشه و چه خطراتی در صورت عدم رعایت هر مورد ما رو تهدید میکنه.نکات مهم اولیه که همین حالا باید تو محیط خودتون چک کنید:- برای نصب دامین کنترلر از Template های آماده و حتی Sysprep  شده استفاده نکنید،همواره نصب سیستم عامل را Clean و Fresh انجام دهید- همیشه آخرین آپدیت های منتشر شده را روی سیستم عامل های میزبان AD نصب کنید(به شدت حایز اهمیت و ساده!!!)- قابلیت مهم Recycle-Bin رو فعال کنید(مطمئن باشید نجاتتون میده!)- حذف گروه Authenticated Users از پالیسی گروه هایی که میتوانند سیستم ها را به دامنه Join کنند،ترجیحا فقط گروه های Domain-Admins و یک گروه مخصوص کاربران HelpDesk را در این پالیسی تعریف نمایید(در کل پالیسی پیش فرض Domain-Controllers اصلا امن نیست و نیاز به تغییرات زیادی داره)- ادمین های AD حتما برای استفاده از سیستم کلاینت و امور روتین مانند وب گردی و چک کردن ایمیل از یک کاربری Domain-User استفاده نمایند و از کاربری با سطوح دسترسی ادمین صرفا برای امور مدیریت سرویس ها استفاده کنند- به صورت دوره ای اعضای Security Group ها را بررسی نمایید،به خصوص در مورد Nested Groups(این مورد را با بررسی اعضای گروه های مهم و حیاتی آغاز کنید)- به هیچ عنوان با کاربری عضو Domain-Admins برای رفع مشکلات Help-Desk روی کلاینت ها ریموت نزنید- حتما کاربرانی که دسترسی های Admin دارند(حتی فقط روی کلاینت ها) را به عضویت گروه Protected Users در اکتیو دایرکتوری در آورید- کاربری Administrator اصلی دامین را Rename کنید و پسوردی با طول بیش از 15 کاراکتر برای آن تنظیم نمایید و از استفاده از آن بپرهیزید- کاربری Administrator لوکال روی کامپیوترها را حتی المقدور غیر فعال نمایید- کاربری هایی که ویژگی Null-Password برای آنها تنظیم شده را شناسایی و اصلاح نمایید(بسیار مهم)- برای کاربری که میخواهد فقط چند یوزر ایجاد و ریست پسورد کند دسترسی Domain-Admin واگذار نکنید!از Delegation و ACLs استفاده کنید.- پروتکل SMBv1 را حتما روی سیستم عامل غیرفعال نمایید،این پروتکل حدود 30 سال سن داره و مایکروسافت عاجزانه خواهش کرده که از استفاده ازش دست بکشید!!!(بررسی وابستگی به این پروتکل را قبلا انجام دهید)- سرویس Print Spooler را روی دامین کنترلرها متوقف و غیر فعال کنید- گروه Schema Admins همواره خالی از عضو باشد(در صورت نیاز عضویت را با قید زمانی اعطا کنید)- پالیسی تغییر پسورد کاربری ادمین لوکال کامپیوترها و سرورها،پسورد را به صورت ClearText ذخیره می نماید،اگر از قبل از این ویژگی استفاده کردید این پسوردها را نشت شده محسوب کرده و در قدم اول پالیسی را حذف نموده و از مکانیزمی مانند LAPS استفاده نمایید- کاربری متعلق به krbtgt می بایست حداکثر هر 90 روز یکبار 2 بار ریست پسورد شود(ملاحظات این مورد باید در نظر گرفته شود)- پالیسی های مربوط به Audit-Logs و Advanced Auditing Policy حتما تنظیم گردد- پالیسی های مرتبط با Powershell Auditing حتما تنظیم گردد و از اجرای اسکریپت های نا معتبر جلوگیری بعمل آید- کاربری های Inactive حتما Disable گردد و ویژگی Logon-to برای این کاربری ها به مقداری نامعتبر تغییر یابد- کامپیوتر اکانت های Inactive حتما Disable گردد- حتی المقدور برای هیچ کاربری ویژگی Password-Never-Expire تنظیم نگردد- برای کاربری ها تا حد امکان Logon-To و Logon-Hours تنظیم گردد- حتما پسورد پالیسی مناسب ایچاد کنید و برای گروه های کاربری ادمین از پسورد پالیسی ها متفاوت و سختگیرانه تر استفاده نمایید(Fine-Grained Password Policy)- قابلیت Account Lockout حتما در پسورد پالیسی لحاظ گردد- اگر از دامین کنترلرهای ورژن 2003 و 2008 به بالا آپگرید انجام دادید حتما چک کنید که Replication  از مکانیزم DFSR استفاده کند و اگر هنوز روی FRS هست حتما به DFSR آپگرید نمایید- کاربران ادمین و HelpDesk برای اتصال ریموت به سیستم ها حتما از ویژگی RestrictedAdmin استفاده نمایند- پالیسی مربوط به جلوگیری و غیرفعالسازی LLNMR را تنظیم نمایید- مدت زمان Session کاربران و صدور و تمدید تیکت های KDC کنترل و محدود گردند- با استفاده از متدهای مورد تایید مایکروسافت از دامین کنترلرها بکاپ بگیرید- روی سرورهای دامین کنترلر هیچ گونه نرم افزار و یا Role دیگری نصب نکنید- به هیچ عنوان دسترسی اینترنت روی سرورهای دامین کنترلر باز نباشد(برای NTP و DNS از سرورهای Upstream استفاده نمایید و مستقیم به اینترنت متصل نکنید)- به هیچ عنوان روی دامین کنترلر مرورگر نصب نکنید!یکی از آسیب پذیرترین نرم افزارها همین مرورگرها هستند- اگر روی دامین کنترلر DNS هم دارید حتما Logهای آن را فعال نموده و توسط Analyzer های موجود دامنه های مشکوک را بررسی نمایید- سرویس DHCP را بر روی دامین کنترلر نصب نکنید!و حتما برای این سرویس مکانیزم Logging را فعال و به صورت دوره ای بررسی نمایید- سیستم عامل های کلاینت و سرور به صورت پیش فرض و بعد از نصب اولیه به هیچ عنوان امن نیستند!!! از Security Baseline ها و ابزارهای مرتبط با این موضوع برای امن سازی بدیهیات اولیه سیستم عامل ها استفاده نمایید.- در حوزه ی مجازی سازی نسبت به نوشتن Rule های Affinity برای تفکیک محل قرارگیری ماشین های دامین کنترلر روی هاست های متفاوت اقدام نمایید.</description>
                <category>armprzd</category>
                <author>armprzd</author>
                <pubDate>Mon, 24 May 2021 10:46:43 +0430</pubDate>
            </item>
                    <item>
                <title>یکی دیگر از اثرات HAFNIUM Exploit بر روی MS-Exchange</title>
                <link>https://virgool.io/@armprzd/hafnium-preventing-cu-upgrade-frridt1isnrn</link>
                <description>اگه تو محیط کار و سازمانی که مشغول فعالیت هستید از سرویس ایمیل مایکروسافت Exchange استفاده میکنید احتمالا تو ماه های گذشته در مورد HAFNIUM Exploit و آسیب پذیری Proxy-Logon زیاد شنیدید و اینجا هم قرار نیست که با تکرار موارد مطلب رو طولانی کنیم و حوصله شما رو سر ببریم.اگه سیستم شما هدف حمله قرار گرفته و با استفاده از ابزارها و اسکریپت ها بررسی های لازم رو انجام دادید و حتی آپدیت های امنیتی رو هم نصب کردید،باید عرض کنم که کار اینجا تموم نشده!اخیرا تو اعمال بروزرسانی های CU19 و CU20 روی سرورهای چند مجموعه متوجه خطای زیر شدیم و عملا روند بروزرسانی ممکن نبود.Failed to install the product c:\temp\Exchange Cu20\exchangeserver.msi. Fatal error during installation. Error code: 1603. Last error issued by the MSI package: &#x27;The installer has insufficient privileges to access this directory: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.1.2242.8. The installation cannot continue. Log on as administrator or contact your system administrator. &#x27;.این خطا صرفا به این پوشه محدود نبوده و میتونه از پوشه HttpProxy به بعد تمامی Sub-Directory ها رو شامل بشه.با بررسی های انجام شده متوجه شدیم یکی از موارد مهمی که این حمله مورد تغییر قرار میده تغییر دسترسی ها و بعضا Ownerهای این فولدرها است و مهم ترین قسمت شناساییش هم اینه که مجوز Read رو به Everyone روی این پوشه ها تنظیم میکنه!برای رفع خطا و رسیدن به بروزرسانی موفقیت آمیز باید نسبت به  تصحیح دسترسی ها و همچنین حذف دسترسی Everyone از روی فولدر HttpProxy و  تغییر Owner این پوشه به گروه Domain-Admins اقدام کنید.همچنین ویژگی Inherit Permission برای Child-Object رو هم روی این پوشه فعال کنید تا ACL ها رو از فولدر Parent دریافت کنند.میتونید برای شناسایی پوشه هایی که دچار این تغییرات شدن از اسکریپ زیر هم استفاده کنید:$FolderRoot = &quot;C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy&quot;$Principal = &quot;Everyone&quot;$AllFolders = (Get-ChildItem $FolderRoot -Recurse -Directory | select fullname).Fullnameforeach ($Folder in $Allfolders) {Get-Acl $Folder | where {$_.access.IdentityReference -match $Principal -and $_.access.FileSystemRights -match &quot;Read&quot;}}با این اصلاح دسترسی مشکل عدم نصب CU های جدید مرتفع میشه اما حواستون به چندتا نکته باشه:1- مشخص شد که موفقیت آمیز بودن حمله صرفا با وجود یا عدم وجود وب شل و فایل های مشکوک aspx قابل اثبات نیست،به مرور تغییرات و آسیب های بعدی نمایان میشن.2- بروزرسانی و نصب وصله ی امنیتی صرفا شما رو در برابر نفوذهای بعدی واکسینه میکنه و هیچ ضمانتی برای ایمن شدن سرور و محیط عملیاتیتون در برابر حملات قبلی نداره،در واقع این بروزرسانی ها جهت پاکسازی سرور شما از اثرات حمله نیستند(این مهم ترین اشتباهی هست که در هفته های اخیر در پروژه ها باهاش مواجه بودیم)3- علیرغم اینکه مایکروسافت با ترکیب چند مکانیزم و ابزار اعلام کرده که نسبت به شناسایی و رفع تغییرات و تهدیدات به وجود آمده اقدام میکنه ولی در نهایت خود مایکروسافت ایمن ترین گزینه برای عبور از این تهدیدات رو نصب مجدد سرویس و انتقال میل باکس ها و دیتابیس ها به سرور جدید و حذف کردن کامل و اصولی نسخ فعلی میدونه.پس اگر شرایط این کار رو دارید یک دقیقه تردید نکنید.</description>
                <category>armprzd</category>
                <author>armprzd</author>
                <pubDate>Sat, 15 May 2021 19:23:00 +0430</pubDate>
            </item>
            </channel>
</rss>