Amazon GuardDuty وAmazon Inspector

عند الساعة 03:00 يفتح instance في حساب الإنتاج اتصالاً بعنوان IP في بلد لا تشغّل فيه شيئاً. ولم ينشر أحد شيئاً. وفي الوقت نفسه، يشغّل ذلك الـ instance منذ 5 أسابيع نسخة من مكتبة نظام لها CVE منشور.

حقيقتان عن instance واحد، وسؤالان مختلفان. الأول: هل يحدث شيء سيّئ الآن؟ والثاني: ما الذي يستطيع مهاجم استغلاله إن دخل؟ تجيب AWS عنهما بخدمتين منفصلتين، ويصرف الاختبار معظم أسئلة الاكتشاف على معرفة أي خدمة تجيب عن أي سؤال. تطلب منك المهارة 4.2.5 ضبط التقارير ومعالجة النتائج من Security Hub وGuardDuty وAWS Config وInspector وAWS Security Agent. وهذا الدرس يأخذ أول كاشفَين في القائمة.

السلوك مقابل الحالة

أنظف طريقة للفصل بينهما: GuardDuty يقرأ النشاط، وInspector يقرأ المخزون.

الصفّ الأخير هو الفرق العملي. نتيجة GuardDuty تقرير عن الماضي لا يصلح نفسه أبداً، ونتيجة Inspector وصف للحاضر يختفي حين ترقّع. احتفظ بذلك حين يصف سؤال نتيجة «أُغلقت وحدها» أو أخرى «بقيت مفتوحة بعد إنهاء الـ instance».

GuardDuty يقرأ سجلات لم تُفعّلها أصلاً

فعّل GuardDuty في منطقة فيبدأ فوراً باستهلاك 3 مصادر بيانات أساسية:

• أحداث إدارة AWS CloudTrail، أي نداءات مستوى التحكّم مثل AttachRolePolicy وCreateSubnet وCreateTrail.
• VPC Flow Logs من instances في EC2 داخل الحساب.
• سجلات استعلامات Route 53 Resolver DNS، أي عمليات البحث عن الأسماء التي تجريها الـ instances.

وهنا يبدأ سوء فهم متوقّع. من المغري افتراض أنك يجب أن تنشئ trail في CloudTrail وتفعّل VPC Flow Logs أولاً، كما تفعل مع أغلب الخدمات التي تستهلك السجلات. وهذا خطأ. يستهلك GuardDuty كلاً من هذه المصادر عبر تدفّق مستقلّ ومكرَّر. فإعدادك لـ CloudTrail لا يؤثّر فيما يراه GuardDuty، وGuardDuty لا يؤثّر في إعدادك لـ CloudTrail. وتعطيل flow logs على VPC لا يُعمي GuardDuty. ولا رسم إضافي على الوصول إلى السجلات نفسها؛ أنت تدفع تسعيرة GuardDuty بعد تجربة الـ 30 يوماً المجانية.

ومصدر DNS يحمل التبعية الحقيقية الوحيدة، وهو تفصيل مفضَّل في الاختبار. يقرأ GuardDuty استعلامات DNS عبر محلّلات AWS الداخلية. فإن كانت الـ instances تستخدم المحلّل الذي توفّره AWS، وهو الافتراضي، رأى GuardDuty الاستعلامات. وإن وجّهتها إلى OpenDNS أو Google DNS أو محلّل تشغّله بنفسك، فإن GuardDuty لا يستطيع الوصول إلى تلك البيانات إطلاقاً، ويصمت كل نوع نتيجة يعتمد على DNS. وتفعيل تسجيل استعلامات Route 53 Resolver لا يصلح الأمر، لأن GuardDuty يستخدم تدفّقاً منفصلاً لا تلك الميزة.

وسلوك آخر يستحقّ معرفته قبل أن تقرّر أي المناطق تفعّل. أحداث الخدمات العالمية، من IAM وAWS STS وS3 وCloudFront وRoute 53، يسجّلها CloudTrail في منطقة واحدة لكنها تهمّ في كل مكان. ويكرّر GuardDuty تلك الأحداث ويعالجها في كل منطقة فعّلته فيها، وهكذا يحافظ على ملف تعريف للمستخدمين والأدوار في كل منطقة. وهذه هي حجّة تشغيل GuardDuty حتى في مناطق لا تنشر فيها شيئاً: المهاجم الذي ينشئ موارد في منطقة مهجورة هو الحالة التي تمسكها هذه الملفات بالضبط.

خطط الحماية توسّع مساحة الرصد

المصادر الأساسية الثلاثة هي الخطّ القاعدي. وكل ما عداها مما يستطيع GuardDuty مراقبته يأتي من خطة حماية اختيارية، وتسمّيها الواجهة البرمجية feature. وكل خطة تضيف مصدر سجلات أو أحداث:

وتفصيلان عن كيفية تشغيل هذه الخطط. حين تفعّل GuardDuty لأول مرة، تُفعَّل كل خطط الحماية تلقائياً باستثناء Runtime Monitoring، وتدخل ضمن تجربة الـ 30 يوماً المجانية. أما إن كنت عميلاً لـ GuardDuty قبل إطلاق خطة ما، فتلك الخطة لا تُفعَّل تلقائياً وعليك الاشتراك بها يدوياً، ولهذا تجد في الحسابات القديمة فجوات تغطية لا توجد في الحسابات الجديدة.

وMalware Protection for S3 هو الاستثناء الوحيد في النموذج كله: تستطيع استخدامه وحده دون تفعيل خدمة GuardDuty أصلاً. وكل خطة حماية أخرى تتطلّب GuardDuty.

ويأتي Malware Protection for EC2 بنكهتين تحبّ أسئلة السيناريو الفصل بينهما. الفحص الذي يبدأه GuardDuty ينطلق تلقائياً حين تشير نتيجة إلى برمجية خبيثة على instance، ويعمل مرة واحدة كل 24 ساعة على الأكثر لكل مورد، وله تجربة مجانية مدتها 30 يوماً. والفحص عند الطلب تبدأه أنت بعنوان ARN لـ instance، ولا يحتاج ضبطاً على مستوى الميزة سوى أن يكون GuardDuty مفعّلاً، ويمكن تكراره على المورد نفسه بعد ساعة من بدء الفحص السابق، وبلا تجربة مجانية. وكلاهما يحترم وسم GuardDutyExcluded العام. ولا تُحفَظ لقطات الوحدات المفحوصة إلا حين تُكتشَف برمجية خبيثة، وبشرط أن تكون قد ضبطت الحفظ.

ويجلس فوق هذا كله Extended Threat Detection. وهو يربط الأحداث عبر مصادر البيانات وأنواع الموارد والزمن داخل الحساب الواحد ليكتشف الهجمات متعدّدة المراحل، ثم يكتب نتيجة سلسلة هجوم. ولا يكلّف شيئاً إضافياً، ولا يحتاج خطة حماية، ويُفعَّل تلقائياً مع GuardDuty. وهو أيضاً سبب هبوط نتائج سلاسل الهجوم في النطاق الحرج بينما تجلس الإشارات المفردة أدنى: كل حدث بمفرده بدا محتمَلاً، والسلسلة لم تكن كذلك.

قراءة نوع النتيجة دون فتحها

يسمّي GuardDuty كل نوع نتيجة بالقواعد نفسها:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

مرّر نوعاً حقيقياً واحداً عبر هذه الصيغة. يقول CryptoCurrency:EC2/BitcoinTool.B!DNS إن غرض المهاجم نشاط عملة رقمية، ونوع المورد المتأثّر instance في EC2، وعائلة النشاط أداة Bitcoin معروفة، و.B هي النسخة المكتشَفة، و!DNS يسمّي الأثر، أي أن الـ instance كان يتحدّث إلى نطاق معروف بارتباطه بـ Bitcoin.

وقيمتان في موضع آلية الاكتشاف تحملان معنى إضافياً:

• .Custom تعني أن المطابقة جاءت من قائمة تهديدات رفعتها أنت، لا من استخبارات AWS.
• .Reputation تعني أن نموذج تقييم سمعة النطاقات أنتج المطابقة.

وقيم ThreatPurpose تستحقّ تصفّحاً واحداً لأن عدداً منها يطابق تكتيكات MITRE ATT&CK مباشرة: Backdoor وBehavior وCredentialAccess وCryptocurrency وDefenseEvasion وDiscovery وExecution وExfiltration وImpact وInitialAccess وPentest وPersistence وPolicy وPrivilegeEscalation وRecon وStealth وTrojan وUnauthorizedAccess. ولست مطالباً بحفظ القائمة، لكن يجب أن تعرف أن Policy تعني مخالفة لأفضل الممارسات لا هجوماً، وأن Pentest تعني نشاطاً يشبه أدوات اختبار الاختراق المعروفة، وهو ما لا يستطيع GuardDuty تمييزه عن مهاجم حقيقي يستخدم الأدوات المتاحة نفسها.

والخطورة رقم من 1.0 إلى 10.0، مقسَّم على 4 نطاقات:

وأسئلة السيناريو تعطيك الرقم عادة لا التسمية، فقيم الحدود هي ما تحفظه.

التجميع والأرشفة والتأخير الذي يفاجئ الفرق

لا ينشئ GuardDuty نتيجة جديدة لكل حزمة. فحين يرصد نشاطاً جديداً مرتبطاً بالمشكلة الأمنية نفسها، يحدّث النتيجة الأصلية ويزيد الحقل Count، ويستبدل التفاصيل بأحدث ظهور. فمحاولات SSH brute force المتكرّرة على instance واحد تبقى نتيجة واحدة، والهجوم نفسه على instance ثانٍ ينشئ نتيجة ثانية بمعرّفها الخاص، لأنها مشكلة أمنية متميّزة بمورد متميّز.

ولذلك التجميع أثر في التسليم. تصل النتائج النشطة الجديدة إلى EventBridge خلال نحو 5 دقائق. أما تحديثات النتائج القائمة فتتبع إعداداً منفصلاً هو وتيرة النتائج المحدَّثة، وافتراضيه كل 6 ساعات ويمكن ضبطه على 15 دقيقة أو ساعة واحدة. فالهجوم المستمرّ، وهو يصل تحديثات لا نتائج جديدة، قد يجلس ساعات قبل أن تسمع به دالة المعالجة لديك. وحين يصف سؤال أتمتة «تأخّرت» على حادثة مستمرّة، فهذا الإعداد هو الجواب.

وقواعد الكبت هي وسيلتك لتقليل الضجيج. القاعدة معايير ترشيح مع قيمة، والنتائج الجديدة المطابقة تُؤرشَف تلقائياً. وثلاث خصائص تهمّ:

1. النتائج المكبوتة لا تُرسَل إلى Security Hub CSPM ولا Amazon S3 ولا Amazon Detective ولا EventBridge، ولا تُطلق فحوص Malware Protection for EC2. وهذا هو المقصود: إسكات SIEM لا وحدة التحكّم وحدها.
2. تبقى النتائج مولَّدة ومخزَّنة في GuardDuty لـ 90 يوماً، وتُرى بالترشيح على Archived.
3. في الإعداد متعدّد الحسابات، مسؤول GuardDuty وحده يستطيع إنشاء قواعد الكبت.

وللكبت الواسع كلفة يسهل إغفالها. النتائج المؤرشفة لا تُستخدَم إشارات حين يربط Extended Threat Detection الأحداث في سلاسل هجوم. اكبت كل نتائج عناقيد EKS فتكون قد أزلت أيضاً قدرة GuardDuty على ملاحظة سلسلة يستغلّ فيها مهاجم حاوية، ثم يلتقط رمزاً مميّزاً عالي الصلاحية، ثم يصل إلى موارد حسّاسة. وتوجيه AWS نفسه أن تبني قواعد الكبت بأثر رجعي، لسلوكيات محدّدة أكّدت تكراراً أنها إنذارات كاذبة، لا مرشّحاً شاملاً.

Inspector يفحص ما نشرته

يكتشف Amazon Inspector أحمال العمل بنفسه ويفحصها باستمرار. فلا يوجد تقييم تجدوله ولا نافذة فحص تخطّط لها. وحين يتغيّر مورد، أو تثبّت حزمة، أو يُنشَر CVE جديد يخصّ ذلك المورد، يعيد Inspector الفحص. وحين تصلح المشكلة، يرصد المعالجة ويغلق النتيجة عنك.

وينتج 3 أنواع من النتائج:

وقابلية الوصول الشبكي هي التي تُوقع الناس في أمرين: إنها لـ EC2 وحدها، وتعمل بدورة 12 ساعة لا باستمرار.

والخطورة تستحقّ ملاحظة لأن Inspector يفعل ما لا يفعله Config ولا GuardDuty. فهو يأخذ درجة CVSS الأساسية من National Vulnerability Database ويعدّلها بحسب بيئتك، منتجاً درجة Amazon Inspector. فالثغرة القابلة للاستغلال شبكياً على instance بلا مسار مفتوح إلى الإنترنت تحصل على درجة أدنى من الثغرة نفسها على instance مكشوف للإنترنت. وقد يحمل حسابان الـ CVE نفسه بخطورتين مختلفتين ويكونان محقّين معاً.

وقواعد الاحتفاظ تتبع نموذج الحالة. نتائج الموارد المحذوفة أو المنهاة أو التي لم تعد مؤهَّلة تُغلَق تلقائياً وتُحذَف بعد 3 أيام. والنتائج المغلقة لأي سبب آخر تُحذَف بعد 30 يوماً. والنتيجة المعالَجة التي تعود خلال 7 أيام تُفتَح من جديد بدل أن تُنشَأ مرة أخرى. ونتائج الـ instances المتوقّفة تبقى نشطة، لأن الـ instance المتوقّف ما زال يحمل الحزمة المصابة على قرصه.

بوكيل وبلا وكيل، وكيف يختار Inspector

فحص ثغرات الحزم على EC2 يستخدم إحدى طريقتين لجمع المخزون، والاختيار لكل instance ليس اعتباطياً.

الفحص بوكيل يجمع مخزون البرمجيات عبر وكيل SSM. ويجب أن يكون الـ instance مُداراً في Systems Manager داخل الحساب نفسه، ويعني ذلك عملياً وكيل SSM مثبّتاً ويعمل، مع ملف تعريف instance يمنح صلاحية SSM (وسياسة AmazonSSMManagedInstanceCore المُدارة تغطّي كل ما يحتاجه Inspector). وينشئ Inspector ارتباطات SSM خاصة به تنتهي أسماؤها بـ -do-not-delete ليثبّت إضافات الجمع ويسحب المخزون. وهذه الطريقة تفحص باستمرار: عند التشغيل، وعند تثبيت برمجية جديدة على Linux وMac، وحين يؤثّر CVE منشور حديثاً في الـ instance. وهي أيضاً الطريقة التي تدعم الفحص العميق في Inspector لحزم لغات البرمجة على Linux.

الفحص بلا وكيل لا يحتاج شيئاً على الـ instance. يأخذ Inspector لقطة لكل وحدة EBS مرتبطة به، ويسم اللقطة بـ InspectorScan، ويقرأها عبر EBS direct APIs، ويولّد النتائج، ثم يحذف اللقطة. ويكون الـ instance مؤهَّلاً حين يعمل بنظام تشغيل مدعوم، وتكون حالته Unmanaged EC2 instance أو Stale inventory أو No inventory، ويكون مدعوماً بـ EBS بنظام ملفات ext3 أو ext4 أو xfs، وتقلّ وحدات التخزين المرتبطة به عن 8 بإجمالي لا يتجاوز 1200 GB، ولا يستبعده وسم.

ووضع الفحص الهجين يجمع الطريقتين، وهو ما يسجّلك فيه تفعيل فحص EC2: الـ instances المُدارة بـ SSM تسلك الطريق بوكيل، وغير المُدارة المؤهَّلة تحصل على تغطية بلا وكيل. والفحوص بلا وكيل تعمل كل 24 ساعة، ويبحث Inspector عن instances صارت مؤهَّلة حديثاً كل ساعة. ويستطيع حساب مستقلّ أو المسؤول المفوَّض لـ Inspector تغيير وضع الفحص، وحين يضبطه المسؤول المفوَّض ينطبق الوضع على كل الحسابات الأعضاء في المنظمة.

ونتيجة واحدة توقّعها بدل أن تشخّصها: الـ instance نفسه قد ينتج نتائج مختلفة بحسب الطريقة التي فحصته. فعلى Linux، يفحص الفحص بلا وكيل كل المسارات المتاحة لحزم اللغات، بينما يغطّي الفحص بوكيل المسارات الافتراضية مع أي مسارات إضافية ضبطتها للفحص العميق.

ولإخراج instance من الفحص كلياً، ضع عليه وسماً بالمفتاح InspectorEc2Exclusion. ومفتاح الوسم غير حسّاس لحالة الأحرف، والقيمة اختيارية. ولا تُحاسَب على الـ instances المستبعَدة.

وإلى جانب فحص الحزم، يشغّل Inspector أيضاً فحوص CIS على أنظمة تشغيل EC2. وهي تستهدف الـ instances بالوسوم، وتحتاج أن يكون الـ instance مُداراً بـ SSM مع صلاحيات AmazonInspector2ManagedCisPolicy، وتعمل مرة عند الطلب أو بجدول يومي أو أسبوعي أو شهري. وتختار المستوى 1 من معيار CIS للإعدادات القاعدية التي لا يُتوقّع أن تعطّل الخدمة، أو المستوى 2 للبيئات عالية الأمان، والمستوى 2 يشمل كل ما في المستوى 1.

الكبت يعني شيئين مختلفين

هذا هو الحدّ الأجدر بالخروج من الدرس، لأن الخدمتين تستخدمان الكلمة نفسها لسلوكين مختلفين فعلاً.

واحذف قاعدة كبت في Inspector فتعود النتائج المطابقة إلى Active وتُنشَر من جديد إلى Security Hub CSPM وEventBridge. واحذف قاعدة كبت في GuardDuty فتتوقّف أرشفة المطابقات المستقبلية وحسب؛ وما أُرشف يبقى مؤرشفاً حتى تلغي أرشفته.

تشغيل الاثنين عبر منظمة

تتكامل الخدمتان مع AWS Organizations عبر مسؤول مفوَّض، وكلتاهما إقليمية، لكن التفاصيل تختلف بما يكفي للاختبار.

في GuardDuty، يعيّن حساب إدارة Organizations المسؤولَ المفوَّض، وتفعيل الخدمة عنده يُشغّل GuardDuty في تلك المنطقة وحدها. والقاعدة التي تُوقع الناس زوج: التعيين لكل منطقة، ويجب أن يكون الحساب نفسه في كل منطقة. عيّن الحساب 111122223333 في أيرلندا فلا تستطيع تعيين 555555555555 في كندا. وتتيح تفضيلات التفعيل التلقائي للمسؤول تغطية الحسابات الأعضاء NEW وحدها أو ALL بما فيها القائمة، ولإعداد NEW فخّ ترتيب في المناطق الاختيارية: يجب أن يشترك الحساب العضو في المنطقة قبل انضمامه إلى المنظمة، وإلا لم يعد جديداً. ويدير المسؤول الواحد 50,000 حساب عضو كحدّ أقصى. وإزالة المسؤول المفوَّض تزيل ارتباطات الأعضاء لكنها تترك GuardDuty مفعّلاً في تلك الحسابات.

وفي Inspector، يستطيع المسؤول المفوَّض تفعيل الخدمة للمنظمة كلها في خطوة واحدة، وضبط التفعيل التلقائي للحسابات التي تنضمّ لاحقاً. ويستطيع عرض النتائج المجمَّعة لكل الأعضاء، وتفعيل فحوصهم أو تعطيلها، وضبط وضع فحص EC2 للمنظمة بأكملها، وامتلاك إعدادات فحوص CIS على مستوى المنظمة. وثمّ حدّ خصوصية واحد: المسؤول المفوَّض لا يستطيع رؤية مقتطفات الكود العائدة للحسابات الأعضاء، لأن نتائج ثغرات الكود تتضمّن كوداً مصدرياً ملتقَطاً.

نصائح الاختبار

• «هل يهاجمني أحد؟» تشير إلى GuardDuty. و«ما المكشوف أو القابل للاستغلال؟» تشير إلى Inspector. والسؤال الذي يذكر CVE أو مستويات الترقيع أو صور الحاويات هو Inspector حتى لو استخدم لغة أمنية.
• لا شيء يحتاج تفعيلاً قبل GuardDuty. فإن قال خيار «فعّل VPC Flow Logs أولاً» أو «أنشئ trail في CloudTrail أولاً» فهو خطأ.
• والاستثناء هو DNS. محلّل غير تابع لـ AWS يعني غياب نتائج DNS، ولا إعداد في أي مكان يصلح ذلك.
• Malware Protection for S3 يعمل بلا تفعيل GuardDuty. وكل خطة حماية أخرى تتطلّبه.
• Runtime Monitoring هي خطة الحماية الوحيدة التي لا تُفعَّل تلقائياً عند التفعيل الأول.
• حدود الخطورة: Low من 1.0 إلى 3.9، وMedium من 4.0 إلى 6.9، وHigh من 7.0 إلى 8.9، وCritical من 9.0 إلى 10.0. والحرج يعني سلسلة هجوم من Extended Threat Detection.
• النتائج الجديدة تصل EventBridge خلال نحو 5 دقائق؛ والتحديثات تتبع وتيرة التصدير وافتراضيها 6 ساعات. والأتمتة المتأخّرة على هجوم مستمرّ هي هذا الإعداد غالباً.
• الكبت في GuardDuty يوقف التسليم اللاحق. والكبت في Inspector لا يوقفه. لا تدع الكلمة المشتركة تدمج بينهما.
• قابلية الوصول الشبكي في Inspector لـ EC2 وحدها وكل 12 ساعة. والفحص بلا وكيل للحزم كل 24 ساعة. أرقام مختلفة وآليات مختلفة.
• الوضع الهجين: المُدار بـ SSM يذهب بوكيل، وغير المُدار المدعوم بـ EBS يذهب بلا وكيل. والاستبعاد بوسم InspectorEc2Exclusion.
• المسؤول المفوَّض لـ GuardDuty: لكل منطقة، والحساب نفسه في كل مكان، وسقف 50,000 عضو، ولا يعيّنه إلا حساب إدارة Organizations.

والذي تحمله معك هو الانقسام في الجدول الأول: GuardDuty يخبرك أن شيئاً حدث، وInspector يخبرك أن شيئاً ممكن. ولا أحد منهما يرتّب الاثنين مقابل بعضهما، ولا يزيل التكرار بينهما، ولا يفعل شيئاً حيالهما. فنتيجة High في GuardDuty على instance سبق أن وسمه Inspector بـ CVE قابل للاستغلال عن بُعد وضع مختلف عن أي من النتيجتين وحدها، ولا يستطيع كاشف واحد قول ذلك. وهذا الربط، والأتمتة التي تتصرّف بناءً عليه، هو ما يبنيه الدرس التالي مع Security Hub.