Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
cfn_nag — أداة فحص (Linting) لقوالب CloudFormation | Kitploit
أدوات/GitHubGitHub/stelligent/cfn_nag
تحليل الشفرة الثابت (SAST)تدقيق التكوينأمن السحابةDevSecOpsكشف الأسرارسوء التكوين
GitHubstelligent/cfn_nag

cfn_nag

أداة فحص (Linting) لقوالب CloudFormation

عرض المستودع
1.3k208منذ 2 سنواتتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

cfn_nag

الخلفية

تبحث أداة cfn-nag عن أنماط في قوالب CloudFormation قد تشير إلى بنية تحتية غير آمنة. بشكل تقريبي، ستبحث عن:

  • قواعد IAM متساهلة للغاية (wildcards)
  • قواعد مجموعات الأمان متساهلة للغاية (wildcards)
  • سجلات وصول غير مفعّلة
  • تشفير غير مفعّل
  • قيم حرفية لكلمات المرور

لمزيد من الخلفية حول الأداة، يرجى الاطلاع على هذا المنشور في مدونة Stelligent:

Finding Security Problems Early in the Development Process of a CloudFormation Template with "cfn-nag"

التثبيت

التثبيت عبر Gem

بافتراض تثبيت Ruby >= 2.5.x، يكون التثبيت مجرد:

root@kitploit:~
gem install cfn-nag

التثبيت عبر Brew

على MacOS أو Linux يمكنك بدلاً من ذلك التثبيت عبر brew:

root@kitploit:~
brew install ruby brew-gem
brew gem install cfn-nag

CodePipeline

لتشغيل cfn_nag كإجراء في CodePipeline، يمكنك النشر عبر AWS Serverless Application Repository.

الاستخدام

للتنفيذ:

root@kitploit:~
cfn_nag_scan --input-path <path to cloudformation json>

يمكن أن يكون المسار دليلاً أو قالباً محدداً. إذا كان دليلاً، فستتم معالجة جميع ملفات .json, و .template و .yml و .yaml، بما في ذلك العودية إلى الأدلة الفرعية.

تنسيق الإخراج الافتراضي هو نص حر، ولكن يمكن اختيار إخراج json باستخدام العلم --output-format json.

اختيارياً، يقوم العلم --debug بإلقاء معلومات حول داخلية تحميل القواعد.

شغّل مع --help للحصول على قائمة كاملة بالمفاتيح المدعومة.

لرؤية قائمة بجميع القواعد التي يدعمها cfn-nag حالياً، توجد أداة سطر أوامر تقوم بإلقائها إلى stdout:

root@kitploit:~
cfn_nag_rules

النتائج

  • يتم إلقاء النتائج إلى stdout
  • المخالفة الفاشلة تُرجع رمز خروج غير صفري.
  • التحذير يُرجع رمز خروج صفري/نجاح.
  • المخالفة القاتلة توقف التحليل (لكل ملف) لأن القالب تالف بشكل خطير

التشغيل في Docker

يتم توفير Dockerfile للراحة. وهو منشور على DockerHub باسم stelligent/cfn_nag.

https://hub.docker.com/r/stelligent/cfn_nag

يمكنك أيضاً بناؤه محلياً.

root@kitploit:~
docker build -t stelligent/cfn_nag .

يمكنك تركيب دليل محلي يحتوي على قوالب داخل حاوية Docker ثم استدعاء cfn_nag في الحاوية. يستخدم هذا المثال قوالب الاختبار المستخدمة في اختبار الوحدات لـ cfn_nag:

root@kitploit:~
$ docker run -v `pwd`/spec/test_templates:/templates -t stelligent/cfn_nag /templates/json/efs/filesystem_with_encryption.json
{
  "failure_count": 0,
  "violations": [

  ]
}
$ docker run -v `pwd`/spec/test_templates:/templates -t stelligent/cfn_nag /templates/json/efs/filesystem_with_no_encryption.json
{
  "failure_count": 1,
  "violations": [
    {
      "id": "F27",
      "type": "FAIL",
      "message": "EFS FileSystem should have encryption enabled",
      "logical_resource_ids": [
        "filesystem"
      ]
    }
  ]
}

التشغيل كإجراء GitHub

يمكن تشغيل cfn_nag_scan كجزء من سير عمل GitHub لتقييم الكود أثناء خطوط التكامل المستمر.

في ملف سير عمل GitHub الخاص بك، أنشئ خطوة تستخدم إجراء cfn_nag:

root@kitploit:~
- name: Simple test
  uses: stelligent/cfn_nag@master
  with:
    input_path: tests

مزيد من المعلومات حول إجراء GitHub تجدها هنا.

تصفية النتائج

البروفايلات

يدعم cfn-nag مفهوم "البروفايل" وهو عملياً قائمة سماح بالقواعد المطلوب تطبيقها. البروفايل هو ملف نصي يجب أن يحتوي على معرّف قاعدة واحد في كل سطر. عند تحديده عبر وسيط سطر الأوامر --profile-path، سيقوم cfn-nag بإرجاع المخالفات من تلك القواعد المحددة فقط.

الدافع وراء إنشاء "بروفايل" هو أن المطورين المختلفين قد يهتمون بقواعد مختلفة. على سبيل المثال، قد يهتم "infrastructure_developer" بقواعد IAM، بينما قد لا يتمكن "app_developer" من إنشاء موارد IAM وبالتالي لا يهتم بتلك القواعد.

فيما يلي مثال لبروفايل:

root@kitploit:~
F1
F2
F27
W3
W5

قائمة الرفض العامة

قائمة الرفض هي عكس البروفايل بشكل أساسي: إنها قائمة بالقواعد التي لا يجب تطبيقها أبداً. عند تحديدها عبر وسيط سطر الأوامر --deny-list-path، لن يُرجع cfn-nag أبداً مخالفات من تلك القواعد المحددة في الملف.

في حال تم تحديد قاعدة في كليهما، ستأخذ قائمة الرفض الأولوية على البروفايل، ولن يتم تطبيق القاعدة.

التنسيق كما يلي. الحقلان البارزان الوحيدان هما RulesToSuppress وid لكل عنصر. لن يتم تفسير reason بواسطة cfn-nag، ولكن يُنصح بتبرير وتوثيق سبب عدم تطبيق القاعدة أبداً.

root@kitploit:~
RulesToSuppress:
- id: W3
  reason: W3 is something we never care about at enterprise X

كبت القواعد لكل مورد

في حال وجود قاعدة تريد كبتها، يمكن إضافة مفتاح Metadata خاص بـ cfn_nag إلى المورد المتأثر لإخبار cfn_nag بعدم إثارة فشل أو تحذير لتلك القاعدة.

على سبيل المثال، إذا كنت تقوم بإعداد ELB عام مواجه للجمهور ومفتوح للاتصالات الواردة من الإنترنت بموارد مثل التالية:

public_alb.yaml

root@kitploit:~
# Partial template
PublicAlbSecurityGroup:
  Properties:
    GroupDescription: 'Security group for a public Application Load Balancer'
    VpcId:
      Ref: vpc
  Type: AWS::EC2::SecurityGroup
PublicAlbSecurityGroupHttpIngress:
  Properties:
    CidrIp: 0.0.0.0/0
    FromPort: 80
    GroupId:
      Ref: PublicAlbSecurityGroup
    IpProtocol: tcp
    ToPort: 80
  Type: AWS::EC2::SecurityGroupIngress

سيقوم cfn_nag بإثارة تحذيرات مثل التالية:

root@kitploit:~
$ cfn_nag_scan -i public_alb.yaml
------------------------------------------------------------
public_alb.yaml
------------------------------------------------------------------------------------------------------------------------
| WARN W9
|
| Resources: ["PublicAlbSecurityGroup"]
|
| Security Groups found with ingress cidr that is not /32
------------------------------------------------------------
| WARN W2
|
| Resources: ["PublicAlbSecurityGroup"]
|
| Security Groups found with cidr open to world on ingress.  This should never be true on instance.  Permissible on ELB

Failures count: 0
Warnings count: 2

بإضافة البيانات الوصفية، يمكن كبت هذه التحذيرات:

public_alb_with_suppression.yaml

root@kitploit:~
# Partial template
PublicAlbSecurityGroup:
  Properties:
    GroupDescription: 'Security group for a public Application Load Balancer'
    VpcId:
      Ref: vpc
  Type: AWS::EC2::SecurityGroup
  Metadata:
    cfn_nag:
      rules_to_suppress:
        - id: W9
          reason: "This is a public facing ELB and ingress from the internet should be permitted."
        - id: W2
          reason: "This is a public facing ELB and ingress from the internet should be permitted."
PublicAlbSecurityGroupHttpIngress:
  Properties:
    CidrIp: 0.0.0.0/0
    FromPort: 80
    GroupId:
      Ref: PublicAlbSecurityGroup
    IpProtocol: tcp
    ToPort: 80
  Type: AWS::EC2::SecurityGroupIngress
root@kitploit:~
$ cfn_nag_scan -i public_alb_with_suppression.yaml
------------------------------------------------------------
public_alb_with_supression.yaml
------------------------------------------------------------
Failures count: 0
Warnings count: 0

تعيين قيم معلمات القالب

يمكن أن تمثل معلمات قالب CloudFormation مشكلة للتحليل الثابت لأن القيم تُحدد عند نقطة النشر. بعبارة أخرى، القيم غير متاحة عند إجراء التحليل الثابت - فالتحليل الثابت يمكنه فقط النظر إلى "الكود" الموجود أمامه. لذلك لن يتم الإبلاغ عن قاعدة دخول مجموعة أمان بقيمة 0.0.0.0/0 إذا كانت cidr معلمة وتم تمرير 0.0.0.0/0 في وقت النشر.

للسماح بفحص قيم المعلمات، يمكن للمستخدم تحديد قيم المعلمات في ملف JSON يتم تمريره عبر سطر الأوامر إلى كل من cfn_nag وcfn_nag_scan باستخدام العلم --parameter-values-path=<filename/uri>.

تنسيق JSON هو مفتاح واحد، "Parameters"، قيمته قاموس حيث يتوافق كل زوج مفتاح/قيمة مع المعلمات:

root@kitploit:~
{
  "Parameters": {
    "Cidr": "0.0.0.0/0"
  }
}

سيوفر هذا "0.0.0.0/0" للمعامل التالي:

root@kitploit:~
Parameters:
  Cidr:
    Type: String

انتبه إلى أنه إذا كانت هناك معلمات إضافية في JSON، فسيتم تجاهلها بهدوء (للسماح لـ cfn_nag_scan بتطبيق نفس JSON على جميع القوالب).

إذا كان JSON تالفاً أو لا يستوفي المواصفات أعلاه، فسيفشل التحليل مع مخالفة FATAL.

التعيينات

قبل الإصدار 0.5.55، كانت استدعاءات Fn::FindInMap تُتجاهل فعلياً. كان النموذج الأساسي يتركها كما هي، ولذلك كانت تظهر كقيم Hash للقواعد. مثال: { "Fn::FindInMap" => [map1, key1, key2]}

بدءاً من 0.5.55، سيحاول النموذج حساب قيمة استدعاء FindInMap وتقديم تلك القيمة للقواعد. يدعم هذا التقييم المفاتيح التي تكون:

  • نص ثابت
  • مراجع إلى معلمات (مع استبدال المعلمات)
  • مراجع إلى دوال AWS الزائفة (انظر القسم التالي)
  • خرائط متداخلة

إذا لم تستطع منطق التقييم تحديد قيمة لمفتاح، فستعود إلى السلوك القديم المتمثل في إرجاع Hash للتعبير بأكمله.

دوال AWS الزائفة

قبل 0.5.55 أيضاً، كانت استدعاءات دوال AWS الزائفة تُتجاهل فعلياً. كان النموذج الأساسي يتركها كما هي، ولذلك كانت تظهر كقيم Hash للقواعد. مثال: {"Ref"=>"AWS::Region"}. حالة الاستخدام الشائعة هي تنظيم التعيينات حسب المنطقة، لذا فإن تقييم الدوال الزائفة مهم لدعم تقييم الخرائط بشكل أفضل.

بدءاً من 0.5.55، سيقدم النموذج دوال AWS الزائفة التالية للقواعد بالقيم الافتراضية:

root@kitploit:~
'AWS::URLSuffix' => 'amazonaws.com',
'AWS::Partition' => 'aws',
'AWS::NotificationARNs' => '',
'AWS::AccountId' => '111111111111',
'AWS::Region' => 'us-east-1',
'AWS::StackId' => 'arn:aws:cloudformation:us-east-1:111111111111:stack/stackname/51af3dc0-da77-11e4-872e-1234567db123',
'AWS::StackName' => 'stackname'

بالإضافة إلى ذلك، يمكن للمستخدم النهائي تجاوز القيمة المقدمة عبر آلية استبدال المعلمات التقليدية. مثال:

root@kitploit:~
{
  "Parameters": {
    "AWS::Region": "eu-west-1"
  }
}

التحكم في سلوك الشروط

حتى الإصدار 0.4.66 من cfn_nag، لم يقم النموذج الأساسي بأي معالجة لـ Fn::If داخل القالب. هذا يعني أنه إذا كانت الخاصية تحتوي على قيمة شرطية، فكان على القاعدة تحليل Fn::If. ونظراً لأن Fn::If يمكن أن يظهر في أي مكان تقريباً، فقد خلق ذلك موقف "اضرب الخلد" لمطوري القواعد. في أفضل الأحوال، كان بإمكان منطق القاعدة تجاهل القيم التي كانت Hash بافتراض أن القيمة لم تكن Hash في المقام الأول.

لمعالجة هذه المشكلة، أصبح السلوك الافتراضي لـ cfn_nag الآن استبدال Fn::If بالنتيجة الصحيحة (true). هذا يعني افتراضياً أن القواعد لن تفحص النتائج الخاطئة (false) بحثاً عن مخالفات أمنية.

بالإضافة إلى استبدال Fn::If على مستوى قيم الخصائص، يتم تطبيق نفس السلوك على Fn::If في المستوى الأعلى للخصائص (Properties). مثال:

root@kitploit:~
Resource1:
  Type: Foo
  Properties: !If
    - IsNone
    - Description: Up
    - Description: DOwn

سيبدو كما يلي:

root@kitploit:~
Resource1:
  Type: Foo
  Properties:
    Description: Up

لتوفير بعض التحكم في هذا السلوك، يمكن للمستخدم تحديد قيم الشروط في ملف JSON يتم تمريره عبر سطر الأوامر إلى كل من cfn_nag وcfn_nag_scan باستخدام العلم --condition-values-path=<filename/uri>.

تنسيق JSON هو قاموس يتوافق فيه كل زوج مفتاح/قيمة مع الشروط:

root@kitploit:~
{
  "Condition1": true,
  "Condition2": false
}

مقاييس تعقيد السياسات من Stelligent (spcm)

أساس SPCM موصوف في منشور المدونة Thought Experiment Proposed Complexity Metric for IAM Policy Documents.

بدءاً من الإصدار 0.6.0 من cfn_nag:

  • spcm_scan يمكن لـ spcm_scan فحص دليل من قوالب CloudFormation (مثل cfn_nag_scan) وإنشاء تقرير بمقاييس SPCM بتنسيق JSON أو HTML
  • تمت إضافة قاعدة (إلى cfn_nag) للتحذير من IAM::Policy أو IAM::Role بدرجة SPCM >= 50 (افتراضياً)
  • يمكن التحكم في عتبة القاعدة عبر سطر الأوامر: cfn_nag_scan --rule-arguments spcm_threshold:100
  • يمكن لمطوري القواعد المخصصة الآن تطوير قواعد تقبل قيم المستخدم النهائي للإعدادات عبر نفس آلية --rule-arguments. كل ما يحتاجه كائن Rule هو تعريف attr_accessor، مثل attr_accessor :spcm_threshold وسيتولى cfn_nag تفاصيل حقن القيم من --rule-arguments

توزيع القواعد المخصصة

يتضمن إصدار 0.5.x بعض التغييرات الرئيسية في كيفية توزيع القواعد المخصصة وتحميلها. قبل هذا الإصدار، كان هناك مكانان يتم تحميل القواعد منهما: دليل lib/cfn-nag/custom_rules داخل جوهرة cfn_nag الأساسية، ودليل القواعد المخصصة المحدد في سطر الأوامر.

هناك حالتا استخدام فرضتا إعادة تصميم لكيفية وأين يتم تحميل القواعد المخصصة. تم تعميم آلية تحميل القواعد بحيث يمكن استخدام مستودعات القواعد المخصصة لاكتشاف القواعد.

  1. مجموعة من "ملفات القواعد" مبعثرة على نظام ملفات ليست رائعة من منظور تطوير البرمجيات التقليدي. لا يوجد إصدار أو إمكانية تتبع لهذه الملفات، لذلك يقدم 0.5.x مفهوم "جوهرة قواعد cfn_nag". يمكن للمطور تطوير قواعد مخصصة كجزء من جوهرة منفصلة، وإصدارها وتثبيتها... ويتم الإشارة إلى تلك القواعد من cfn_nag طالما أن بيانات جوهرة (gem metadata) تتضمن cfn_nag_rules => true. بالنسبة لجوهرة باسم مثل "cfn-nag-hipaa-rules"، سيتم تحميل أي *.rb ضمن lib/cfn-nag-hipaa-rules. يجب أن تشتق أي قواعد مخصصة من CfnNag::BaseRule في cfn-nag/base_rule (وليس cfn-nag/custom-rules/base). إذا كان يجب أن تشتق القاعدة من شيء آخر، فإن تعريف دالة cfn_nag_rule? تُرجع true سيتسبب أيضاً في تحميلها كقاعدة.

  2. عندما يعمل cfn_nag في AWS Lambda - لا يوجد نظام ملفات حقيقي (باستثناء /tmp) بالمعنى التقليدي. لذلك، فقط القواعد الأساسية قابلة للاستخدام من Lambda. لدعم القواعد المخصصة، يدعم cfn_nag اكتشاف القواعد من حاوية S3 بدلاً من نظام الملفات.

كل ما رأيته على الأرجح حول كيفية تطوير قواعد مخصصة في Ruby لا يزال صحيحاً.

لاكتشاف القواعد من حاوية S3، أنشئ ملف s3.yml بهذا المحتوى:

root@kitploit:~
---
repo_class_name: S3BucketBasedRuleRepo
repo_arguments:
  s3_bucket_name: cfn-nag-rules-my-enterprise
  prefix: /rules

لتطبيق ملفات *Rule.rb في الحاوية cfn-nag-rules-my-enterprise بالبادئة /rules (مثل /rules/MyNewRule.rb)، حدد هذا الملف في سطر الأوامر لـ cfn_nag كما يلي:

root@kitploit:~
cat my_cfn_template.yml | cfn_nag --rule-repository s3.yml

إذا كانت القواعد في أكثر من حاوية، فأنشئ عدة ملفات s3*.yml وحددها في وسيط --rule-repository.

إذا كانت بيانات اعتماد AWS المحيطة لديها إذن للوصول إلى الحاوية cfn-nag-rules-enterprise، فستجد جميع القواعد مثل /rules/*Rule.rb. إذا كان يجب استخدام aws_profile معين، أضفه كمفتاح تحت repo_arguments، مثل aws_profile: my_aws_profile

إلى جانب نظام الملفات وتثبيتات الجواهر وS3 - تدعم البنية الجديدة نظرياً تطوير "مستودعات قواعد" أخرى لتحميل القواعد من DynamoDb أو قواعد البيانات العلائقية أو خدمات ويب أخرى.

التطوير

قواعد جديدة

لتأليف قواعد جديدة لاستخدامك الخاص و/أو المساهمة المجتمعية، راجع تطوير القواعد المخصصة للتفاصيل.

يتوفر فيديو شاشة يوضح تطوير قواعد مخصصة بتقنية TDD من البداية إلى النهاية هنا:

https://www.youtube.com/watch?v=JRZct0naFd4&t=1601s

الاختبارات

لتشغيل الاختبارات، يجب التأكد من تثبيت Docker وتبعيات cfn_nag عبر:

root@kitploit:~
gem install bundle
bundle install

ثم، لتشغيل جميع الاختبارات، فقط شغّل rake test:all.

لتشغيل اختبارات النهاية إلى النهاية، شغّل rake test:e2e. سيقوم السكريبت بتجميع جميع الجواهر في Gemfile، وبناء وتثبيت جوهرة cfn_nag محلياً، وتثبيت تبعيات الاختبارات، ثم تنفيذ الاختبارات الموسومة بـ 'end_to_end'. وسيقوم أيضاً بسحب قوالب نموذجية مقدمة من Amazon وتشغيل cfn_nag_scan عليها، لمعرفة ما إذا كانت أي قوالب معروفة الجودة تسبب استثناءات داخل cfn-nag.

التثبيت المحلي

لتثبيت فرع git الحالي محلياً:

root@kitploit:~
bundle install
scripts/deploy_local.sh

التطوير عن بُعد باستخدام VS Code

توجد بيئة تطوير عن بُعد كاملة تم إنشاؤها وإعدادها مع جميع الأدوات والإعدادات المضبوطة مسبقاً لتسهيل تطوير القواعد وإنشائها. يمكنك تفعيل ذلك باستخدام وظيفة التطوير عن بُعد في VS Code.

  • ثبّت حزمة إضافات Remote Development الخاصة بـ VS Code
  • افتح المستودع في VS Code
  • عندما يُطلب منك Folder contains a dev container configuration file. Reopen folder to develop in a container انقر الزر Reopen in Container
  • عند الفتح في المستقبل استخدم خيار [Dev Container] cfn_nag Development

مزيد من المعلومات حول إعداد التطوير عن بُعد في VS Code تجدها هنا، VS Code Remote Development.

الدعم

للإبلاغ عن خطأ أو طلب ميزة، قدّم مشكلة عبر مستودع GitHub على: https://github.com/stelligent/cfn_nag/issues/new

تنزيل الأداة