Strelka - ملفات المسح الضوئي في مقياس مع بيثون و ZeroMQ
Strelka هو نظام لفحص الملفات في الوقت الحقيقي يستخدم لصيد التهديدات ، وكشف التهديدات ، والاستجابة للحوادث. استناداً إلى التصميم الذي وضعته Laika BOSS لمؤسسة لوكهيد مارتن والمشاريع المماثلة (انظر: المشاريع ذات الصلة ) ، فإن الغرض من Strelka هو إجراء استخراج الملفات وجمع البيانات الوصفية على نطاق واسع.
تختلف Strelka عن مشاريعها الأخوية بطرق قليلة مهمة:
- برنامج Codebase هو Python 3 (أقل إصدار مدعوم هو 3.6)
- مصمم للأنظمة الموزعة غير التفاعلية (أجهزة استشعار مراقبة أمن الشبكة ، البرامج النصية للاستجابة الحية ، استخراج الأقراص / الذاكرة ، إلخ.)
- يدعم طلبات الملفات المباشرة والبعيدة (Amazon S3 ، Google Cloud Storage ، وغيرها) مع التشفير والتشفير الاختياري
- استخدام شبكات / تنسيقات ومراسلات ومراسلات بيانات معتمدة على نطاق واسع (ZeroMQ ، المخازن المؤقتة للبروتوكولات ، YAML ، JSON)
- مدمج تسجيل نتائج الفحص وإدارة السجل (متوافق مع Filebeat / ElasticStack ، Splunk ، الخ)
أسئلة مكررة
"من هو Strelka؟"
Strelka هي واحدة من الجيل الثاني من كلاب الفضاء السوفياتي لتحقيق رحلات الفضاء المدارية - الاسم هو تحية إلى Laika BOSS لمؤسسة لوكهيد مارتن ، واحدة من أول المشاريع العامة من هذا النوع والتي يستند إليها التصميم الأساسي ل Strelka.
"لماذا أريد نظام فحص الملفات؟"
البيانات الوصفية للملفات هي دعامة إضافية للبيانات (إلى جانب الشبكة ، نقطة النهاية ، المصادقة ، والسحابة) التي تكون فعالة في تمكين صيد التهديد ، وكشف التهديدات ، والاستجابة للحوادث ويمكن أن تساعد محللي الأحداث والمستجيبين للحوادث في سد فجوات الرؤية في بيئتهم. هذا النوع من النظام مفيد بشكل خاص لتحديد الجهات الفاعلة التي تهدد خلال KC3 و KC7 . للحصول على أمثلة لما يمكن أن يفعله Strelka ، يرجى قراءة حالات الاستخدام .
"هل يجب علي التبديل من نظام المسح الحالي للملفات إلى Strelka؟"
يعتمد ذلك - نوصي بمراجعة ميزات كل منها واختيار الأداة الأنسب لاحتياجاتك. نعتقد أن أهم العوامل المحفزة للتحول إلى Strelka هي:
- قاعدة الكود الحديثة (Python 3.6+)
- المزيد من الماسحات الضوئية (40+ عند الإطلاق) وأنواع الملفات (60+ عند الإطلاق) من المشاريع ذات الصلة
- يدعم طلبات الملفات المباشرة والبعيدة
- المدمج في التشفير والتوثيق لاتصالات العميل
- بنيت باستخدام المكتبات والتنسيقات التي تسمح عبر منصة دعم عبر اللغة
"هل الماسحات الضوئية Strelka متوافقة مع Laika BOSS أو File Scanning Framework أو Assemblyline؟"
بسبب الاختلافات في التصميم ، لا تتوافق الماسحات الضوئية Strelka بشكل مباشر مع Laika BOSS أو File Scanning Framework أو Assemblyline. مع بعض الجهد ، من المحتمل أن يتم نقل معظم الماسحات الضوئية إلى المشاريع الأخرى.
"هل Strelka نظام كشف التسلل (IDS)؟"
لا ينبغي التفكير في Strelka كمعهد IDS ، ولكن يمكن استخدامه للكشف عن التهديد من خلال مطابقة قاعدة YARA وتفسير البيانات الوصفية المتتالية. يتبع تصميم Strelka الفلسفة التي وضعتها أنظمة جمع البيانات الوصفية الشائعة الأخرى (Bro، Sysmon، Volatility، إلخ): فهو يستخرج البيانات ويترك عملية اتخاذ القرار للمستخدم.
"هل تعمل على نطاق واسع؟"
كل شخص لديه تعريفه الخاص لـ "على نطاق واسع" ، ولكننا كنا نستخدم Strelka وأنظمة مثله لفحص ما يصل إلى 100 مليون ملف يوميًا لأكثر من عام ولم نصل أبدًا إلى نقطة يتعذر على النظام فيها قياس احتياجاتنا - - مع زيادة حجم الملف وتنوعه ، يجب أن يسمح لك حجم النظام أفقيا بمسح أي عدد من الملفات.
"ألا يستخدم هذا الكثير من النطاق الترددي؟"
نعم! لم يتم تصميم Strelka للعمل في بيئات النطاق الترددي المحدود ، ولكن قمنا بتجربة حلول لهذا ، وهناك حيل يمكنك استخدامها للحد من عرض النطاق الترددي. هذه ما وجدناه أكثر نجاحًا:
- قم بخفض الحجم الإجمالي للملفات المرسلة إلى Strelka
- استخدام نظام تتبع لإرسال ملفات فريدة فقط إلى Strelka (تكون خوادم Redis المتصل بالشبكة مفيدة بشكل خاص لهذا الغرض)
- استخدم التحكم في حركة المرور (tc) لتشكيل الوصلات إلى Strelka
"هل يجب أن أشغل مجموعة Strelka الخاصة بي على جهاز استشعار شبكة Bro / Suricata؟"
لا! تعمل مجموعات Strelka على تشغيل عمليات مكثفة تعتمد على CPU والتي قد تؤثر سلبًا على تطبيقات النظام الحرجة مثل Bro و Suricata. إذا كنت ترغب في دمج مستشعر الشبكة مع Strelka ، فاستخدم
strelka_dirstream.py
. هذه الأداة قادرة على إرسال ملايين الملفات يوميًا من مستشعر شبكة مفرد إلى مجموعة Strelka دون التأثير على تطبيقات النظام الحرجة. التركيب
نظام التشغيل الموصى به لـ Strelka هو Ubuntu 18.04 LTS (Bionic Beaver) - قد يعمل مع الإصدارات السابقة من Ubuntu إذا تم تثبيت الحزم المناسبة. نوصي باستخدام حاوية Docker لعمليات نشر الإنتاج وطلبات السحب الترحيبية التي تضيف إرشادات للتثبيت على أنظمة التشغيل الأخرى.
Ubuntu 18.04 LTS
- تحديث الحزم وتثبيت حزم البناء
apt-get update && apt-get install --no-install-recommends automake build-essential curl gcc git libtool make python3-dev python3-pip python3-wheel
- تثبيت حزم وقت التشغيل
apt-get install --no-install-recommends antiword libarchive-dev libfuzzy-dev libimage-exiftool-perl libmagic-dev libssl-dev python3-setuptools tesseract-ocr unrar upx jq
- تثبيت حزم pip3
pip3 install beautifulsoup4 boltons boto3 gevent google-cloud-storage html5lib inflection interruptingcow jsbeautifier libarchive-c lxml git+https://github.com/aaronst/macholibre.git olefile oletools pdfminer.six pefile pgpdump3 protobuf pyelftools pygments pyjsparser pylzma git+https://github.com/jshlbrd/pyopenssl.git python-docx git+https://github.com/jshlbrd/python-entropy.git python-keystoneclient python-magic python-swiftclient pyyaml pyzmq rarfile requests rpmfile schedule ssdeep tnefparse
- قم بتثبيت YARA
curl -OL https://github.com/VirusTotal/yara/archive/v3.8.1.tar.gz
tar -zxvf v3.8.1.tar.gz
cd yara-3.8.1/
./bootstrap.sh
./configure --with-crypto --enable-dotnet --enable-magic
make && make install && make check
echo "/usr/local/lib" >> /etc/ld.so.conf
ldconfig
- تثبيت يارا بيثون
curl -OL https://github.com/VirusTotal/yara-python/archive/v3.8.1.tar.gz
tar -zxvf v3.8.1.tar.gz
cd yara-python-3.8.1/
python3 setup.py build --dynamic-linking
python3 setup.py install
- إنشاء الدلائل Strelka
mkdir /var/log/strelka/ && mkdir /opt/strelka/
- استنساخ هذا المستودع
git clone https://github.com/target/strelka.git /opt/strelka/
- ترجمة البروتستوب Strelka
cd /opt/strelka/server/ && protoc --python_out=. strelka.proto
- (اختياري) قم بتثبيت الأدوات المساعدة Strelka
cd /opt/strelka/ && python3 setup.py -q build && python3 setup.py -q install && python3 setup.py -q clean --all
عامل ميناء
- استنساخ هذا المستودع
git clone https://github.com/target/strelka.git /opt/strelka/
- بناء الحاوية
cd /opt/strelka/ && docker build -t strelka .
بداية سريعة
بشكل افتراضي ، تم تكوين Strelka لاستخدام نشر "quickstart" صغير يسمح للمستخدمين باختبار النظام. هذا التكوين غير مستحسن لعمليات نشر الإنتاج. باستخدام اثنين من الإطارات الطرفية ، قم بما يلي:
صالة 1
$ strelka.py
مخرج 2: $ strelka_user_client.py --broker 127.0.0.1:5558 --path <path to the file to scan>
$ cat /var/log/strelka/*.log | jq .
تقوم الوحدة الطرفية 1 بتشغيل مجموعة Strelka (وسيط و 4 عمال ودوران
السجل) مع تسجيل تصحيح الأخطاء ويتم استخدام Terminal 2 لإرسال طلبات
الملفات إلى الكتلة وقراءة نتائج الفحص. نشر
خدمات
يقوم تصميم Strelka كنظام موزع بإنشاء الحاجة إلى الأدوات المساعدة من جانب العميل والخادم. توفر الأدوات المساعدة من جانب العميل أساليب لإرسال طلبات الملفات إلى نظام مجموعة وأدوات مساعدة من جانب الخادم لتوفير طرق لتوزيع وفحص الملفات المرسلة إلى نظام مجموعة.
strelka.py
strelka.py
هو أداة مساعدة غير تفاعلية من جانب الخادم تحتوي على كل ما يلزم لتشغيل مجموعة Strelka واسعة النطاق وموزعة. هذا يشمل: - القدرة على تشغيل الخوادم في أي مجموعة من الوسطاء / العمال
- الوسيط يوزع مهام الملف على العمال
- يقوم العمال بإجراء تحليل للملفات على المهام
- تسجيل نتيجة المسح على القرص
- دوران السجل شكلي والإدارة
- متوافق مع الشاحنين سجل الخارجية (على سبيل المثال Filebeat ، وكيل الشحن العالمي Splunk ، الخ)
- يدعم التشفير والمصادقة للاتصالات بين العملاء والسماسرة
- عمليات الطفل ذاتية الشفاء (الوسطاء ، العمال ، إدارة السجلات)
etc/strelka/strelka.yml
تهيئة: etc/strelka/strelka.yml
و etc/strelka/pylogging.ini
. تظهر صفحة المساعدة الخاصة بـ
strelka.py
أدناه: usage: strelka.py [options]
runs Strelka as a distributed cluster.
optional arguments:
-h, --help show this help message and exit
-d, --debug enable debug messages to the console
-c STRELKA_CFG, --strelka-config STRELKA_CFG
path to strelka configuration file
-l LOGGING_INI, --logging-ini LOGGING_INI
path to python logging configuration file
strelka_dirstream.py
strelka_dirstream.py
هو أداة مساعدة غير تفاعلية من جانب العميل تُستخدم لإرسال الملفات من دليل إلى مجموعة Strelka في الوقت الفعلي تقريبًا. تستخدم هذه الأداة المساعدة inotify لمشاهدة الدليل وإرسال الملفات إلى الكتلة في أقرب وقت ممكن بعد أن تتم كتابتها. بالإضافة إلى ذلك ، بالنسبة لمصادر الملفات المحددة ، يمكن لهذه الأداة تحليل البيانات الأولية المضمنة في اسم ملف الملف وإرسالها إلى الكتلة كبيانات تعريف خارجية. تعتبر مستشعرات شبكة Bro هي مصدر الملفات الوحيد المعتمد حاليًا ، ولكن يمكن إضافة مصادر أخرى خاصة بالتطبيقات.
استخدام الأداة المساعدة مع Bro لا يتطلب أي تعديل للشفرة المصدرية Bro ، ولكنه يتطلب من مستشعر الشبكة تشغيل برنامج Bro نصي يمكّن استخراج الملفات. نوصي باستخدام برنامج stub bro script (
etc/bro/extract-strelka.bro
) لاستخراج الملفات. سوف تعمل أيضًا نصوص الاستخراج الأخرى ، ولكنها لن تقوم بتشخيص البيانات الوصفية لـ Bro. يتم إدارة هذه الأداة مع ملف تكوين واحد:
etc/dirstream/dirstream.yml
. تظهر صفحة المساعدة الخاصة بـ
strelka_dirstream.py
أدناه: usage: strelka_dirstream.py [options]
sends files from a directory to a Strelka cluster in near real-time.
optional arguments:
-h, --help show this help message and exit
-d, --debug enable debug messages to the console
-c DIRSTREAM_CFG, --dirstream-config DIRSTREAM_CFG
path to dirstream configuration file
strelka_user_client.py
strelka_user_client.py
هي أداة مساعدة موجهة من قبل المستخدم ، والتي يتم استخدامها لإرسال طلبات ملفات مخصصة إلى مجموعة.
يجب استخدام هذا العميل عند الحاجة إلى تحليل الملف لملف معين أو مجموعة
ملفات - يتم تصميمه بشكل صريح للمستخدمين ويجب ألا يتوقع منه تنفيذ طلبات
ملفات طويلة العمر أو مؤتمتة بالكامل. نوصي باستخدام هذه الأداة المساعدة كمثال على ما هو مطلوب في إنشاء أدوات مساعدة عميل جديدة. باستخدام هذه الأداة ، يمكن للمستخدمين إرسال ثلاثة أنواع من طلبات الملفات:
- ملف فردي
- دليل الملفات
- ملف بعيد (انظر: طلبات الملفات عن بعد )
strelka_user_client.py
أدناه: usage: strelka_user_client.py [options]
sends ad-hoc file requests to a Strelka cluster.
optional arguments:
-h, --help show this help message and exit
-d, --debug enable debug messages to the console
-b BROKER, --broker BROKER
network address and network port of the broker (eg
127.0.0.1:5558)
-p PATH, --path PATH path to the file or directory of files to send to the
broker
-l LOCATION, --location LOCATION
JSON representation of a location for the cluster to
retrieve files from
-t TIMEOUT, --timeout TIMEOUT
amount of time (in seconds) to wait until a file
transfer times out
-bpk BROKER_PUBLIC_KEY, --broker-public-key BROKER_PUBLIC_KEY
location of the broker Curve public key certificate
(this option enables curve encryption and must be used
if the broker has curve enabled)
-csk CLIENT_SECRET_KEY, --client-secret-key CLIENT_SECRET_KEY
location of the client Curve secret key certificate
(this option enables curve encryption and must be used
if the broker has curve enabled)
-ug, --use-green determines if PyZMQ green should be used, which can
increase performance at the risk of message loss
generate_curve_certificates.py
generate_curve_certificates.py
هي أداة مساعدة تُستخدم لإنشاء شهادات منحنى الوسيط والعامل. هذه الأداة مطلوبة لإعداد التشفير / المصادقة المنحنى. تظهر صفحة المساعدة الخاصة بـ
generate_curve_certificates.py
أدناه: usage: generate_curve_certificates.py [options]
generates curve certificates used by brokers and clients.
optional arguments:
-h, --help show this help message and exit
-p PATH, --path PATH path to store keys in (defaults to current working
directory)
-b, --broker generate curve certificates for a broker
-c, --client generate curve certificates for a client
-cf CLIENT_FILE, --client-file CLIENT_FILE
path to a file containing line-separated list of
clients to generate keys for, useful for creating many
client keys at once
validate_yara.py
validate_yara.py
هي أداة مساعدة تستخدم بشكل متكرر للتحقق من صحة دليل ملفات قواعد YARA. هذا يمكن أن يكون مفيدا عند تصحيح الأخطاء المتعلقة ScanYara
الضوئي ScanYara
. تظهر صفحة المساعدة الخاصة بـ
validate_yara.py
أدناه: usage: validate_yara.py [options]
validates YARA rules files.
optional arguments:
-h, --help show this help message and exit
-p PATH, --path PATH path to directory containing YARA rules
-e, --error boolean that determines if warnings should cause
errors
ملفات التكوين
يستخدم Strelka YAML لتكوين الأدوات المساعدة من جانب العميل والخادم. نوصي باستخدام التكوينات الافتراضية وتعديل الخيارات حسب الحاجة.
تكوين Strelka (
strelka.py
) يتم تخزين ملف تكوين مجموعة Strelka في
etc/strelka/strelka.yml
ويحتوي على ثلاثة أقسام: daemon و remote و scan. تكوين الشيطان
تحتوي إعدادات البرنامج الخفي على خمسة أقسام فرعية: العمليات والشبكة والوسيط والعمال والمسجل.
يتحكم قسم "العمليات" في العمليات التي يطلقها البرنامج. خيارات التكوين هي:
- "run_broker": boolean الذي يحدد ما إذا كان يجب على الخادم تشغيل عملية وسيط Strelka (افتراضيات إلى True)
- "run_workers": boolean الذي يحدد ما إذا كان يجب أن يقوم الخادم بتشغيل العمليات المنفذة Strelka (افتراضات إلى True)
- "run_logrotate": boolean الذي يحدد ما إذا كان يجب على الخادم تشغيل عملية تدوير سجل Strelka (افتراضيات إلى True)
- "worker_count": عدد العمال الذين ينتجون (الافتراضيات إلى 4)
- "shutdown_timeout": مقدار الوقت (بالثواني) الذي سينقضي قبل أن يقتل الخفي بالقوة عمليات الطفل بعد أن يكون قد تلقى أمر إيقاف التشغيل (الافتراضي إلى 45 ثانية)
- "broker": عنوان الشبكة للوسيط (افتراضيًا إلى 127.0.0.1)
- "request_socket_port": منفذ الشبكة الذي يستخدمه العملاء لإرسال طلبات الملفات إلى الوسيط (افتراضيات إلى 5558)
- "task_socket_port": منفذ الشبكة الذي يستخدمه العمال لتلقي المهام من الوسيط (افتراضيات إلى 5559)
- "poller_timeout": مقدار الوقت (بالمللي ثانية) الذي يستقصيه broker لطلبات العميل وحالات العامل (القيم الافتراضية إلى 1000 ميلي ثانية)
- "broker_secret_key": موقع شهادة المفتاح السري منحنى الوسيط (يمكّن التشفير منحنى ، يتطلب من العملاء استخدام Curve ، افتراضيات بلا)
- "client_public_keys": موقع الدليل الذي يحتوي على شهادات المفتاح العام للعميل منحنى (يُمكِّن التشفير والتشفير منحنى ، يتطلب من العملاء استخدام Curve ، افتراضيات بلا)
- "prune_frequency": تردد (بالثواني) حيث يقوم العاملون الوسيطون بالتخلص من الموتى (الافتراضي إلى 5 ثوان)
- "prune_delta": دلتا (بالثواني) التي يجب أن تمر منذ آخر مرة قام فيها العامل بتسجيل الدخول مع الوسيط قبل اعتباره ميتًا ويتم تشذيبه (افتراضيًا إلى 10 ثوانٍ)
- "task_socket_reconnect": مقدار الوقت (بالمللي ثانية) الذي يحاول مأخذ المهمة إعادة الاتصال به في حالة قطع اتصال TCP ، سيؤدي ذلك إلى حدوث ارتعاش إضافي (افتراضات إلى 100ms زائد الارتعاش)
- "task_socket_reconnect_max": الحد الأقصى لمقدار الوقت (بالمللي ثانية) التي يحاول فيها مأخذ المهمة إعادة الاتصال في حالة قطع اتصال TCP ، سيؤدي ذلك إلى حدوث ارتعاش إضافي (الافتراضات إلى 4000ms زائد الارتعاش)
- "poller_timeout": مقدار الوقت (بالمللي ثانية) الذي يستقصيه العمال لمهام الملف (افتراضيات 1000 ميلي ثانية)
- "file_max": عدد الملفات التي سيقوم العامل بإجرائها قبل إيقاف التشغيل (الإعداد الافتراضي إلى 10000)
- "time_to_live": مقدار الوقت (بالدقائق) الذي سيقوم بتشغيله العامل قبل إيقاف التشغيل (الإعداد الافتراضي إلى 30 دقيقة)
- "heartbeat_frequency": تردد (بالثواني) يقوم العامل بإرسال نبض القلب إلى الوسيط إذا لم يتلقى أي مهام للملفات (القيمة الافتراضية إلى 10 ثوان)
- "log_directory": الموقع الذي يتم فيه تسجيل نتائج فحص العامل (الإعدادات الافتراضية إلى / var / log / strelka /)
- "log_field_case": حالة الحقل ("camel" أو "snake") لبيانات ملف سجل نتائج الفحص (الافتراضات إلى الجمل)
- "log_bundle_events": boolean الذي يحدد ما إذا كان يجب تجميع نتائج الفحص في حدث واحد كصفيف أو في أحداث متعددة (افتراضيات إلى True)
- "directory": دليل لتشغيل سجل التدوير (افتراضيات / var / log / strelka /)
- "compression_delta": delta (بالدقائق) التي يجب تمريرها منذ آخر تعديل لملف السجل قبل أن يتم ضغطه (افتراضيًا إلى 15 دقيقة)
- "deletion_delta": delta (بالدقائق) التي يجب أن تمر منذ آخر تعديل لملف السجل المضغوط قبل حذفه (افتراضيًا إلى 360 دقيقة / 6 ساعات)
التكوين عن بعد
يحتوي التكوين عن بعد على قسم فرعي واحد: بعيد.
يتحكم القسم "عن بعد" في كيفية استرداد العمال للملفات من مخازن الملفات البعيدة. يتم دعم مخازن Google Cloud Storage و Amazon S3 و OpenStack Swift و HTTP. يتم قراءة كل الخيارات في ملف التكوين هذا اختياريًا من متغيرات البيئة إذا كانت "خالية". خيارات التكوين هي:
- "remote_timeout": مقدار الوقت (بالثواني) للانتظار قبل انتهاء استرجاع الملفات الفردية
- "remote_retries": عدد المرات التي ستتم فيها إعادة محاولة استرجاع الملفات الفردية في حالة انتهاء المهلة
- "google_application_credentials": المسار إلى ملف بيانات اعتماد Google Cloud Storage JSON
- "aws_access_key_id": معرف مفتاح الوصول إلى AWS
- "aws_secret_access_key": مفتاح الوصول السري لـ AWS
- "aws_default_region": منطقة AWS الافتراضية
- "st_auth_version": إصدار مصادقة OpenStack (افتراضيًا إلى 3)
- "os_auth_url": OpenStack Keystone authentication URL
- "os_username": اسم المستخدم OpenStack
- "os_password": كلمة مرور OpenStack
- "os_cert": OpenStack Keystone certificate
- "os_cacert": OpenStack Keystone CA Certificate
- "os_user_domain_name": مجال مستخدم OpenStack
- "os_project_name": اسم مشروع OpenStack
- "os_project_domain_name": مجال مشروع OpenStack
- "http_basic_user": اسم مستخدم مصادقة HTTP الأساسي
- "http_basic_pass": كلمة مرور مصادقة HTTP الأساسية
- "http_verify": المسار إلى حزمة CA (ملف أو دليل) المستخدم للتحقق من SSL (افتراضي إلى False ، لا يوجد تحقق)
تكوين المسح
يحتوي تكوين المسح على قسمين فرعيين: التوزيع والماسحات الضوئية.
يتحكم قسم "التوزيع" في كيفية توزيع الملفات عبر النظام. خيارات التكوين هي:
- "close_timeout": مقدار الوقت (بالثواني) الذي يمكن أن يقضيه الماسح الضوئي في إغلاق نفسه (افتراضيًا إلى 30 ثانية)
- "distribution_timeout": مقدار الوقت (بالثواني) الذي يمكن من خلاله توزيع ملف واحد على جميع الماسحات (الافتراضات إلى 1800 ثانية / 30 دقيقة)
- "scanner_timeout": مقدار الوقت (بالثواني) الذي يمكن أن يقضيه الماسح الضوئي في فحص أحد الملفات (افتراضيًا إلى 600 ثانية / 10 دقائق ، يمكن تجاوزه لكل ماسح ضوئي)
- "maximum_depth": أقصى عمق سيتم معالجة ملفات الأطفال بواسطة الماسحات الضوئية
- "taste_mime_db": موقع قاعدة البيانات MIME المستخدمة لتذوق الملفات (الافتراضات إلى بلا ، الافتراضي للنظام)
- "taste_yara_rules": موقع دليل ملفات YARA التي تحتوي على القواعد المستخدمة لتذوق الملفات (الإعدادات الافتراضية إلى etc / strelka / taste /)
ScanZip
) والقيمة هي قائمة من القواميس التي تحتوي على قيم للتعيينات وأولوية الماسح الضوئي وخيارات الماسح الضوئي. يحدث التعيين من خلال نظام من التطابقات الإيجابية والسلبية: تؤدي أي مطابقة سلبية إلى تخطي الماسحة المهمة ويتسبب تطابق إيجابي واحد على الأقل في تعيين الماسح الضوئي. يتم استخدام معرف فريد (
*
) لتعيين الماسحات الضوئية لجميع النكهات. راجع توزيع الملفات ، والماسحات الضوئية ، والنكهات ، والتذوق لمزيد من التفاصيل حول النكهات. يوجد أدناه نموذج للتهيئة يقوم بتشغيل الماسح الضوئي "ScanHeader" على كل الملفات والماسحة الضوئية "ScanRar" على الملفات التي تطابق قاعدة YARA المسماة "rar_file".
scanners:
'ScanHeader':
- positive:
flavors:
- '*'
priority: 5
options:
length: 50
'ScanRar':
- positive:
flavors:
- 'rar_file'
priority: 5
options:
limit: 1000
يوجد أدناه نموذج لتكوين يوضح كيف يمكن مطابقة ملفات RAR مع قاعدة YARA (
rar_file
) ، ونوع MIME ( application/x-rar
) ، واسم الملف (أي تلك النهاية بـ .rar
). scanners:
'ScanRar':
- positive:
flavors:
- 'application/x-rar'
- 'rar_file'
filename: '\.rar$'
priority: 5
options:
limit: 1000
في ما يلي نموذج للتهيئة يوضح كيفية مطابقة ملفات RAR بشكل إيجابي مع قاعدة YARA (
rar_file
) ونوع MIME ( application/x-rar
) ، ولكن فقط إذا لم تتم مطابقتها سلبًا مع اسم الملف ( \.rar$
) . قد يتسبب هذا التكوين في تعيين ScanRar
فقط لملفات RAR التي لا تحتوي على الامتداد ".rar". scanners:
'ScanRar':
- negative:
filename: '\.rar$'
positive:
flavors:
- 'application/x-rar'
- 'rar_file'
priority: 5
options:
limit: 1000
فيما يلي نموذج لتكوين يوضح كيف يمكن للماسح الضوئي الواحد تطبيق خيارات مختلفة بناءً على التعيين.
scanners:
'ScanX509':
- positive:
flavors:
- 'x509_der_file'
priority: 5
options:
type: 'der'
- positive:
flavors:
- 'x509_pem_file'
priority: 5
options:
type: 'pem'
تكوين تسجيل بايثون (
strelka.py
) يستخدم
strelka.py
ملف ini ( etc/strelka/pylogging.ini
) لإدارة إحصائيات مستوى الكتلة وإخراج المعلومات بواسطة مسجل Python. بشكل افتراضي ، سيقوم ملف التكوين هذا بتسجيل البيانات إلى stdout وتعطيل تسجيل الحزم المستوردة بواسطة الماسحات الضوئية. تكوين DirStream (
strelka_dirstream.py
) يتم تخزين ملف التكوين dirstream Strelka في
etc/dirstream/dirstream.yml
ويحتوي على قسمين فرعيين: العمليات والعاملين. يتحكم قسم "العمليات" في العمليات التي أطلقتها الأداة. خيارات التكوين هي:
- "shutdown_timeout": مقدار الوقت (بالثواني) الذي سينقضي قبل أن تقتل الأداة عمليات الطفل بالقوة بعد أن يتلقى أمر إيقاف التشغيل (الافتراضي إلى 10 ثوان)
- "الدليل": الدليل الذي يتم إرسال الملفات منه (افتراضيات بلا)
- "source": تطبيق يقوم بكتابة الملفات إلى الدليل ، ويستخدم للتحكم في وظيفة تحليل بيانات التعريف (الافتراضات إلى None)
- "meta_separator": سلسلة فريدة تستخدم لفصل أجزاء من بيانات التعريف في اسم الملف ، وتستخدم في تحليل البيانات الوصفية وإرسالها مع الملف إلى المجموعة (الافتراضات إلى "S ^ E ^ P")
- "file_mtime_delta": delta (بالثواني) التي يجب أن تمر منذ آخر تعديل للملف قبل إرساله إلى الكتلة (افتراضي إلى 5 ثوان)
- "delete_files": boolean الذي يحدد ما إذا كان يجب حذف الملفات بعد إرسالها إلى المجموعة (الافتراضات إلى False)
- "broker": عنوان الشبكة ومنفذ الشبكة الخاص بالوسيط (افتراضيات "127.0.0.1:5558")
- "timeout": مقدار الوقت (بالثواني) لانتظار إرسال الملف بنجاح إلى الوسيط (افتراضي إلى 10)
- "use_green": boolean الذي يحدد ما إذا كان يجب استخدام PyZMQ باللون الأخضر (يمكن أن يؤدي ذلك إلى زيادة الأداء في خطر فقدان الرسالة أو الافتراضات إلى True)
- "broker_public_key": موقع شهادة المفتاح العام منحنى الوسيط (تمكن تشفير المنحنى ، يجب استخدامه في حالة تمكين الوسيط (Curve))
- "client_secret_key": موقع العميل المفتاح منحنى المفتاح السري (يمكّن التشفير منحنى ، يجب أن يستخدم إذا كان لدى الوسيط تمكين المنحنى)
etc/bro/extract-strelka.bro
ويتضمن المتغيرات التي يمكن إعادة تعريفها في وقت تشغيل Bro. هذه المتغيرات هي: - "mime_table": جدول سلاسل (
source
Bro) تم تعيينه إلى مجموعة من السلاسل (Bromime_type
) - يحدد هذا المتغير نوع ملفات MIME من مقتطفات Bro وهو قابل للتكوين بناءً على الموقع الذي حدده Bro الملف (على سبيل المثال استخراجapplication/x-dosexec
ملفاتapplication/x-dosexec
من SMTP ، ولكن ليس SMB أو FTP) - "filename_re": نمط regex يمكنه استخراج الملفات على أساس
filename
Bro - "unknown_mime_source": مجموعة من السلاسل (
source
Bro) تحدد ما إذا كان يجب استخراج ملفات من نوع MIME غير معروف بناءً على الموقع الذي حددته Bro الملف (على سبيل المثال استخراج الملفات غير المعروفة من SMTP ، وليس SMB أو FTP) -
"meta_separator": السلسلة المستخدمة في أسماء الملفات المستخرجة إلى
البيانات الوصفية Bro الإضافية المدمجة - يجب أن يتطابق هذا مع القيمة
المعادلة في
etc/dirstream/dirstream.yml
- "directory_count_interval": الفاصل الزمني لجدولة عدد المرات التي يتحقق فيها البرنامج النصي من عدد الملفات في دليل الاستخراج
- "directory_count_threshold": int المستخدم كمشغل لتعطيل استخراج الملفات مؤقتًا إذا وصل عدد الملفات في دليل الاستخراج إلى الحد
التشفير والمصادقة
يحتوي Strelka على تشفير ومصادقة اختياريين لتوصيلات العميل التي يوفرها CurveZMQ.
CurveZMQ
CurveZMQ (Curve) هو بروتوكول تشفير ومصادقة ZMQ. قراءة المزيد حول هذا الموضوع هنا .
باستخدام المنحنى
يستخدم Strelka Curve لتشفير ومصادقة الاتصالات بين العملاء والسماسرة. بشكل افتراضي ، يتم إعداد دعم Curve من Strelka لتمكين التشفير ولكن ليس المصادقة.
لتمكين تشفير Curve ، يجب تحميل الوسيط بمفتاح خاص - يجب أن يكون لدى أي عملاء يتصلون بالوسيط المفتاح العمومي للوسيط للاتصال بنجاح.
لتمكين تشفير Curve والتوثيق ، يجب تحميل الوسيط بمفتاح خاص ودليل للمفاتيح العامة للعميل - يجب أن يكون لدى أي عملاء يتصلون بالوسيط المفتاح العمومي للوسيط وأن يتم تحميل مفتاح العميل الخاص بهم على الوسيط للتوصيل بنجاح.
يمكن استخدام الأداة
generate_curve_certificates.py
لإنشاء شهادات العميل والوسيط. عناقيد المجموعات
فيما يلي التوصيات والاعتبارات الواجب مراعاتها عند نشر التجمعات.
توصيات عامة
تنطبق التوصيات التالية على جميع المجموعات:
- لا تقم بتشغيل العمال على نفس الخادم كوسيط
- هذا يضع صحة الكتلة بأكملها في خطر إذا تم استخدام الملقم بشكل زائد
- لا الإفراط في تخصيص العمال إلى وحدات المعالجة المركزية
- عامل واحد لكل وحدة المعالجة المركزية
- تخصيص 1 غيغابايت على الأقل من ذاكرة الوصول العشوائي لكل عامل
- إذا لم يكن لدى العمال ما يكفي من ذاكرة الوصول العشوائي ، سيكون هناك أخطاء ذاكرة مفرطة
- تتطلب الملفات الكبيرة (خاصة الملفات المضغوطة) المزيد من ذاكرة الوصول العشوائي
- في مجموعات كبيرة ، تبدأ العوائد المتناقصة أعلى من 4 غيغابايت من ذاكرة الوصول العشوائي لكل عامل
- تخصيص قدر RAM بقدر معقول للوسيط
- يتم تخزين رسائل ZMQ بالكامل في الذاكرة - في عمليات نشر كبيرة مع العديد من العملاء ، قد يستخدم الوسيط الكثير من ذاكرة الوصول العشوائي إذا لم يتمكن العمال من مواكبة عدد مهام الملفات
اعتبارات التحجيم
يجب مراعاة المتغيرات المتعددة عند تحديد الحجم المناسب لعنصر:
- عدد طلبات الملفات في الثانية
- نوع طلبات الملفات
- تستغرق طلبات الملفات البعيدة وقتًا أطول لمعالجة طلبات الملفات المباشرة
- تنوع الملفات المطلوبة
- تستغرق الملفات الثنائية وقتًا أطول للمسح من الملفات النصية
- عدد قواعد YARA المنشورة
- يستغرق فحص ملف يتضمن 50000 قاعدة وقتًا أطول من مسح ملف يحتوي على 50 قاعدة
اعتبارات Docker
فيما يلي قائمة بالاعتبارات التي يجب وضعها في الاعتبار عند تشغيل مجموعة مع حاويات Docker:
- مشاركة المجلدات ، وليس الملفات ، مع الحاوية
- سيقوم العاملون في Strelka بقراءة ملفات التهيئة وملفات قواعد YARA عند بدء التشغيل - حيث أن مشاركة وحدات التخزين مع الحاوية تضمن ظهور نسخ محدثة من هذه الملفات على localhost بشكل دقيق داخل الحاوية دون الحاجة إلى إعادة تشغيل الحاوية
- زيادة وقف المهلة
- بشكل افتراضي ، سيقوم Docker بقتل الحاوية بشكل قسري إذا لم يتوقف بعد 10 ثوان - يجب زيادة هذه القيمة إلى أكبر من قيمة
shutdown_timeout
فيetc/strelka/strelka.yml
- بشكل افتراضي ، سيقوم Docker بقتل الحاوية بشكل قسري إذا لم يتوقف بعد 10 ثوان - يجب زيادة هذه القيمة إلى أكبر من قيمة
- زيادة حجم شيم
-
بشكل افتراضي ، يقوم Docker بتحديد حجم shm للحاوية إلى 64 ميجابايت -
وهذا يمكن أن يسبب أخطاء مع الماسحات الضوئية Strelka التي تستخدم
tempfile
-
بشكل افتراضي ، يقوم Docker بتحديد حجم shm للحاوية إلى 64 ميجابايت -
وهذا يمكن أن يسبب أخطاء مع الماسحات الضوئية Strelka التي تستخدم
- تعيين خيارات التسجيل
- بشكل افتراضي ، لا يمتلك Docker أي حد للسجل لخرج السجلات بواسطة حاوية
إدارة
نظرًا لتصميمها الموزع ، فإننا نوصي باستخدام تزامن الحاويات (على سبيل المثال Kubernetes) أو إدارة التهيئة / التزويد (مثل Ansible ، SaltStack ، إلخ) لأنظمة إدارة التجمعات.
Commentaires
Enregistrer un commentaire