جدار الحماية المستند إلى المضيف والسماح بالتطبيقات
اضبطوا جدران الحماية المستندة إلى المضيف (Windows Defender Firewall وiptables) وقوائم التطبيقات المسموح بها لمنع تشغيل البرامج غير المصرّح بها.
جدار الحماية المستند إلى المضيف والسماح بالتطبيقات درس مجاني في Security+ Academy على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Security+ Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Security+ Academy 4 دروس في المجموع.
جدران الحماية المستندة إلى المضيف مقابل جدران حماية الشبكة
يوجد جدار حماية الشبكة على المحيط، ويعمل على تصفية حركة المرور بين مقاطع الشبكة. أما جدار الحماية المستند إلى المضيف فيعمل على نقطة النهاية الفردية، ويصفي حركة المرور من الجهاز المحدد وإليه. توفر جدران الحماية المستندة إلى المضيف دفاعًا متعدد الطبقات؛ فحتى إذا تجاوز مهاجم جدار حماية الشبكة (عبر VPN أو موظف داخلي مخترق أو حركة جانبية من مضيف آخر مصاب)، يظل جدار حماية المضيف يفرض قواعد حركة المرور المحلية. وتكتسب هذه الجدران أهمية خاصة للحواسيب المحمولة التي تنتقل خارج محيط المؤسسة وتتصل بشبكات غير موثوقة.
Windows Defender Firewall
يمثل Windows Defender Firewall (WDF) جدار الحماية المدمج للمضيف في جميع إصدارات Windows الحديثة. وهو يدعم ثلاثة ملفات تعريف: Domain (متصل بنطاق المؤسسة — ويكون عادةً أكثر تساهلًا)، وPrivate (شبكة منزلية موثوقة)، وPublic (شبكات غير موثوقة — الأكثر تقييدًا). ويمكن لقواعد WDF تصفية حركة المرور حسب المنفذ والبروتوكول ومسار التطبيق وعنوان IP البعيد وهوية المستخدم. وتتيح الأداة الإضافية Windows Defender Firewall with Advanced Security (WFAS) ضمن MMC وGroup Policy إدارة قواعد جدار الحماية مركزيًا على مستوى المؤسسة عبر جميع الأجهزة المنضمة إلى النطاق.
# Windows: create inbound firewall rule
netsh advfirewall firewall add rule \
name='Block Telnet' \
dir=in \
action=block \
protocol=TCP \
localport=23
# PowerShell equivalent
New-NetFirewallRule \
-DisplayName 'Block Telnet Inbound' \
-Direction Inbound \
-Protocol TCP \
-LocalPort 23 \
-Action Blockiptables وnftables في Linux
تستخدم جدران الحماية للمضيف في Linux إطار عمل النواة Netfilter، ويمكن إعدادها من خلال iptables (الإصدار القديم، ولا يزال مستخدمًا على نطاق واسع) أو nftables الحديث. تُنظَّم القواعد في سلاسل (INPUT وOUTPUT وFORWARD) ضمن جداول (filter وnat وmangle). وينبغي أن تكون السياسة الافتراضية هي DROP، مع وضع قواعد ACCEPT صريحة لحركة المرور المطلوبة — وهو نهج الرفض افتراضيًا. وتوفر الأدوات ذات المستوى الأعلى، مثل ufw (في Ubuntu) وfirewalld (في RHEL/CentOS)، واجهات أسهل استخدامًا، مع استمرار استخدامها لـ Netfilter في الخلفية.
# iptables: deny-by-default with selective allow
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH from specific subnet only
iptables -A INPUT -s 10.10.0.0/24 -p tcp --dport 22 -j ACCEPT
# Allow HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Save rules
iptables-save > /etc/iptables/rules.v4قواعد جدار الحماية على مستوى التطبيق
يمكن لجدران الحماية المستندة إلى المضيف فرض قواعد على طبقة التطبيق — فتُصفي حركة المرور حسب التطبيق الذي أنشأها، وليس حسب المنفذ فقط. ويدعم Windows Defender Firewall القواعد المستندة إلى التطبيقات: إذ يمكن السماح لـ C:\Program Files\MyApp\app.exe بإنشاء اتصالات صادرة مع حظر كل شيء آخر على المنفذ نفسه. ويمنع ذلك البرمجيات الخبيثة من الاستيلاء على المنافذ المسموح بها عبر انتحال صفة تطبيق موثوق. وتكون القواعد على مستوى التطبيق أكثر فعالية بكثير من القواعد المعتمدة على المنافذ فقط، إذ يمكن تجاوز الأخيرة بربط البرمجيات الخبيثة بمنافذ شائعة مثل 443.
# Windows: firewall rule scoped to a specific app
New-NetFirewallRule \
-DisplayName 'Allow Chrome HTTPS' \
-Direction Outbound \
-Program 'C:\Program Files\Google\Chrome\Application\chrome.exe' \
-Protocol TCP \
-RemotePort 443 \
-Action Allow
# Blocks any OTHER process trying to use port 443
# unless that process also has an explicit ALLOW ruleما المقصود بقائمة السماح بالتطبيقات؟
قائمة السماح بالتطبيقات (التي كانت تُسمى سابقًا القائمة البيضاء) هي عنصر تحكم أمني لا يسمح بالتنفيذ على نقطة النهاية إلا للتطبيقات المعتمدة صراحةً. ويُحظر أي ملف قابل للتنفيذ غير موجود في قائمة السماح، سواء أكان برنامجًا خبيثًا أم برنامجًا غير معتمد فحسب. ويمثل ذلك دفاعًا قويًا ضد البرمجيات الخبيثة، إذ تُحظر حتى البرمجيات الخبيثة الجديدة أو غير المعروفة سابقًا إذا لم تكن مدرجة في القائمة المعتمدة. ويتمثل التحدي في الجانب التشغيلي؛ فإدارة قائمة السماح في البيئات الكبيرة والديناميكية تتطلب عملية ناضجة لإدارة التغييرات، كما تؤدي إلى عدد كبير من تذاكر الدعم إذا لم تُضبط بدقة.
Windows AppLocker
يُعد AppLocker ميزة Windows المدمجة للتحكم في التطبيقات، وهي متاحة في إصداري Enterprise وEducation. ويصفي عمليات التنفيذ حسب: المسار (حظر الملفات القابلة للتنفيذ من %TEMP% أو الأدلة التي يمكن للمستخدم الكتابة فيها)، أو تجزئة الملف (السماح بالتجزئات المعروفة والموثوقة فقط)، أو الناشر (السماح بالبرامج الموقعة من Microsoft أو Adobe). وتُنشر سياسات AppLocker عبر Group Policy، وتُسجل في Windows Event Log (معرّف الحدث 8003 = محظور). ويسمح تشغيل AppLocker أولًا في وضع التدقيق — لتسجيل عمليات الحظر دون فرضها — للفرق بضبط قائمة السماح قبل بدء التنفيذ.
# AppLocker rule examples (Group Policy)
# Block executables in user-writable locations
Path Rule: C:\Users\*\AppData\*.exe -> DENY
Path Rule: C:\Windows\Temp\*.exe -> DENY
# Allow by publisher (certificate)
Publisher Rule: O=Microsoft, CN=* -> ALLOW
Publisher Rule: O=Adobe, CN=Adobe Acrobat -> ALLOW
# Hash rule for specific approved version
Hash Rule: SHA256:a1b2c3d4... -> ALLOW
# Check AppLocker events:
Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL'Windows Defender Application Control (WDAC)
يُعد WDAC الخلف الأقوى لـ AppLocker، إذ يُفرض على مستوى النواة بدلًا من مساحة المستخدم. وعلى خلاف AppLocker، لا يستطيع المهاجمون الذين يملكون حقوق المسؤول المحلي تجاوزه، مما يجعله عنصر التحكم المفضل في البيئات عالية الأمان. وتُكتب سياسات WDAC بصيغة XML، ثم تُحوَّل إلى ملفات سياسات ثنائية تُنشر عبر MDM (Intune) أو Group Policy. كما يتيح WDAC التكامل مع Intelligent Security Graph (ISG)، الذي يستخدم خدمة السمعة السحابية من Microsoft للسماح تلقائيًا بالبرامج ذات السمعة الموثوقة، مما يقلل العبء التشغيلي الناتج عن تنسيق قائمة السماح يدويًا.
تحديات قوائم السماح
تتميز قوائم السماح بفاعليتها، لكنها تتطلب جهدًا تشغيليًا كبيرًا. ومن التحديات الشائعة: LOLBins (الثنائيات المستغلة الموجودة في النظام) — إذ يستخدم المهاجمون أدوات نظام Windows مثل PowerShell وwscript.exe وmshta.exe، وهي مدرجة عادةً في كل قائمة سماح؛ لذلك يجب أن تقيّد قائمة السماح طريقة استدعاء هذه الأدوات، لا مجرد السماح بتشغيلها أو منعه. كما أن لغات البرمجة النصية (PowerShell وPython) تكون غالبًا مدرجة في قوائم السماح، لكنها قد تنفذ تعليمات برمجية خبيثة. وتؤدي الإيجابيات الكاذبة — أي حظر البرامج المشروعة بواسطة قائمة السماح — إلى إنشاء تذاكر لدى مكتب الدعم، وإلى ضغط لإضعاف عناصر التحكم. وتعالج برامج قوائم السماح الناضجة LOLBins من خلال سياسات إضافية لوضع اللغة المقيّدة.
# Restricting PowerShell with Constrained Language Mode
# Applied via WDAC when non-WDAC code runs
$ExecutionContext.SessionState.LanguageMode
# Full Language mode -> normal PowerShell
# Constrained Language -> no .NET, no COM objects
# Blocks many attack techniques
# Via Group Policy: force PowerShell logging
# Computer Config > Admin Templates > Windows Components
# > Windows PowerShell
# Enable: Module Logging, Script Block Logging, Transcriptionقائمة السماح مقابل قائمة الحظر
تسمح قائمة السماح بالعناصر المعتمدة صراحةً فقط، وتحظر كل ما عداها — مما يوفر وضعًا أمنيًا أقوى. أما قائمة الحظر (القائمة السوداء)، فتحظر العناصر المعروفة صراحةً بأنها ضارة، وتسمح بكل ما عداها — وهو نموذج برامج مكافحة الفيروسات التقليدي. تفشل قائمة الحظر في مواجهة التهديدات غير المعروفة، بينما تفشل قائمة السماح في مواجهة LOLBins وإدخالات السماح الواسعة أكثر من اللازم. وتستخدم معظم برامج الأمان الناضجة قائمة السماح كعنصر التحكم الأساسي للأنظمة الحساسة، مع استخدام الاكتشاف السلوكي (EDR) لرصد إساءة استخدام التطبيقات المسموح بها. أما في الأنظمة الأقل حساسية، فقد تكون قائمة الحظر المضبوطة جيدًا مع المراقبة السلوكية مقبولة.
دمج جدار الحماية مع قائمة السماح
تمثل جدران الحماية المستندة إلى المضيف وقوائم السماح بالتطبيقات عنصري تحكم متكاملين ومتعددَي الطبقات. فقائمة السماح تمنع تنفيذ التعليمات البرمجية غير المصرح بها، بينما يمنع جدار الحماية الاتصالات الشبكية غير المصرح بها من التعليمات البرمجية المصرح بها ولكن المخترقة. ويطبّق العنصران معًا مبادئ الحد الأدنى من الامتيازات على مستويي التطبيق والشبكة في نقطة النهاية. وتؤدي إضافة EDR كطبقة ثالثة إلى إنشاء منظومة دفاع متعدد الطبقات، يلتقط فيها كل عنصر ما قد تفوّته العناصر الأخرى، مما يرفع بدرجة كبيرة تكلفة الهجمات الناجحة على نقاط النهاية وتعقيدها.
# Endpoint defense-in-depth stack
Layer 1: Application Allowlisting (WDAC)
-> Blocks unauthorized executables from running
Layer 2: Host-Based Firewall (WDF)
-> Blocks unauthorized network connections
-> Even from allowlisted apps on non-standard ports
Layer 3: EDR (CrowdStrike/Defender for Endpoint)
-> Detects behavioral anomalies in allowed processes
-> Catches LOLBin misuse, process injection
-> Provides forensic telemetry for investigationتسجيل جدار الحماية ومراقبته
لا تساوي جدران الحماية المستندة إلى المضيف إلا قيمة السجلات التي تنشئها. فعّلوا تسجيل الاتصالات المحظورة لالتقاط محاولات الهجوم وانتهاكات السياسات. وفعّلوا تسجيل الاتصالات المسموح بها في القواعد الحساسة (مثل القواعد التي تسمح بالأدوات الإدارية) للحفاظ على سجل تدقيق. وأرسلوا سجلات جدار الحماية إلى SIEM لربط الأحداث؛ فقد يشير نمط من الاتصالات الصادرة المحظورة من مضيف واحد إلى برمجية خبيثة تحاول إجراء اتصالات استدعاء وتحكم (C2). في Windows، تُكتب سجلات جدار الحماية افتراضيًا إلى %systemroot%\System32\LogFiles\Firewall\pfirewall.log، وينبغي إعادة توجيهها عبر Windows Event Forwarding (WEF) أو وكيل سجلات.
# Enable Windows Firewall logging via PowerShell
Set-NetFirewallProfile -All \
-LogBlocked True \
-LogAllowed True \
-LogMaxSizeKilobytes 16384 \
-LogFileName '%systemroot%\System32\LogFiles\Firewall\pfirewall.log'
# Linux: log dropped packets with iptables
iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 5/min -j LOG \
--log-prefix 'IPtables-Dropped: ' --log-level 4
iptables -A LOGGING -j DROPتحقق سريع
اختبروا مدى فهمكم لمفاهيم CompTIA Security+ (SY0-701) الواردة في هذا الدرس.
مراجعة الدرس
تعلمتم في هذا الدرس أن جدران الحماية المستندة إلى المضيف (Windows Defender Firewall وiptables) تصفي حركة المرور لكل نقطة نهاية، مع اتباع نهج الرفض افتراضيًا وقواعد محددة النطاق للتطبيقات، وأن قوائم السماح بالتطبيقات (AppLocker وWDAC) تحظر تشغيل الملفات التنفيذية غير المصرح بها، بما فيها البرمجيات الخبيثة، وأن دمج جدار الحماية وقائمة السماح وEDR ينشئ دفاعًا متعدد الطبقات يرفع تكلفة الهجوم بدرجة كبيرة. بعد ذلك، سنستكشف مصادقة البريد الإلكتروني: SPF وDKIM وDMARC.
الأسئلة الشائعة
هل درس «جدار الحماية المستند إلى المضيف والسماح بالتطبيقات» مجاني؟
نعم — نص درس «جدار الحماية المستند إلى المضيف والسماح بالتطبيقات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Security+ Academy، انتقل إلى CoddyKit PRO. تتضمن دورة Security+ Academy 4 دروس في المجموع.
ماذا ستتعلم في «جدار الحماية المستند إلى المضيف والسماح بالتطبيقات»؟
اضبطوا جدران الحماية المستندة إلى المضيف (Windows Defender Firewall وiptables) وقوائم التطبيقات المسموح بها لمنع تشغيل البرامج غير المصرّح بها. تتمرن على Security+ Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Security+ Academy؟
لا تُشترط خبرة سابقة. Security+ Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «جدار الحماية المستند إلى المضيف والسماح بالتطبيقات»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Security+ Academy هذا؟
نعم. كل درس في Security+ Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- منصات مكافحة الفيروسات وEDR وXDR
- تقوية أنظمة التشغيل: التصحيحات والإعداد الأساسي ومعايير CIS
- إدارة الأجهزة المحمولة (MDM) وسياسات BYOD
- جدار الحماية المستند إلى المضيف والسماح بالتطبيقات