kalilinux/build-scripts/kali-vm# سكربت بناء صور Kali Linux الافتراضية
هذا هو سكربت البناء لإنشاء صور الآلة الافتراضية (VM) الخاصة بـ Kali Linux.
حاليًا، هناك طريقتان ممكنتان للبناء:
build.sh - البناء مباشرةً من جهازكbuild-in-container.sh - البناء من داخل حاوية (Docker أو Podman)في كلتا الحالتين، يتم البناء فعليًا من داخل آلة افتراضية يتم إنشاؤها بسرعة بواسطة أداة البناء debos. يستخدم debos fakemachine داخليًا، والذي يعتمد بدوره على QEMU/KVM.
تأكد من استنساخ مستودع git محليًا:
$ sudo apt install -y git
$ git clone https://gitlab.com/kalilinux/build-scripts/kali-vm.git
$ cd kali-vm/
نظرًا لمتطلبات QEMU/KVM، يجب أن تكون عضوًا في مجموعة kvm.
يمكنك التحقق عن طريق:
$ # Not apart of the group
$ grep kvm /etc/group
kvm:x:104:
$
$ # In the group
$ grep kvm /etc/group
kvm:x:104:kali
إذا لم يظهر اسم المستخدم الخاص بك في السطر الناتج، فهذا يعني أنك لست في المجموعة، ويجب عليك إضافة نفسك إلى مجموعة kvm:
$ sudo adduser $USER kvm
ثم سجّل الخروج ثم سجّل الدخول مرة أخرى لكي يسري التغيير.
إذا كنت تبني مباشرةً من جهازك باستخدام build.sh، فستحتاج إلى تثبيت debos:
$ sudo apt install -y 7zip debos dosfstools qemu-utils zerofree
ثم استخدم السكربت build.sh لبناء صورة آلة افتراضية مباشرةً على جهازك.
إذا كنت تفضل البناء من داخل حاوية، فستحتاج إلى تثبيت وتهيئة إما docker أو podman على جهازك.
ثم استخدم السكربت build-in-container.sh لبناء صورة.
build-in-container.sh هو مجرد غلاف فوق build.sh.
سيكتشف محرك الحاويات المتوافق مع OCI الذي يجب استخدامه، ويتولى إنشاء صورة الحاوية إذا لم تكن موجودة، ثم في النهاية يشغّل الحاوية لتنفيذ البناء من داخلها.
يتطلب docker إضافة المستخدم إلى مجموعة Docker، تمامًا كما سبق مع KVM، أو استخدام حساب الجذر (مثل $ sudo ./build-in-container.sh).
تم اختبار podman مع كل من الوضع الجذري (rootful) (مثل $ sudo ./build-in-container.sh) والوضع غير الجذري (rootless) (مثل $ ./build-in-container.sh).
استخدم إما build.sh أو build-in-container.sh، حسب تفضيلك.
من هذه النقطة سنستخدم build.sh للاختصار.
أفضل نقطة بداية، كما هو الحال دائمًا، هي رسالة الاستخدام:
$ ./build.sh -h
Usage: build.sh <options> [-- <debos options>]
Build a Kali Linux VM image
Build options:
-a ARCH Build an image for this architecture, default: amd64
Supported values: amd64
-b BRANCH Kali branch used to build the image, default: kali-rolling
Supported values: kali-dev kali-last-snapshot kali-rolling
-f FORMAT Format to export the image to, default depends on the VARIANT
Supported values: hyperv ova ovf qemu raw vagrant virtualbox vmware
-k Keep raw disk image and other intermediary build artifacts
-m MIRROR Mirror used to build the image, default: http://http.kali.org/kali
-r ROOTFS rootfs to use to build the image, default: none
-s SIZE Size of the disk image in GB, default: 86
-v VARIANT Variant of image to build (see below for details), default: generic
Supported values: generic hyperv qemu rootfs virtualbox vmware
-x VERSION What to name the image release as, default: rolling
-z Zip images and metadata files after the build
Customization options:
-D DESKTOP Desktop environment installed in the image, default: xfce
Supported values: e17 gnome i3 kde lxde mate xfce none
-H HOSTNAME Set system host name, default: kali
-K KEYBOARD Set keyboard layout, default: us
Refer to the README.md for more details
-L LOCALE Set locale, default: en_US.UTF-8
-P PACKAGES Install extra packages (comma/space separated list)
-T TOOLSET The selection of tools to include in the image, default: default
Supported values: default everything headless large none
-U USERPASS Username and password, separated by a colon, default: kali:kali
-Z TIMEZONE Set timezone, default: America/New_York
The different variants of images are:
generic Image with all virtualization support pre-installed, default format: raw
hyperv Image pre-configured for Hyper-V "Enhanced Session Mode", default format: hyperv
qemu Image with QEMU and SPICE guest agents pre-installed, default format: qemu
rootfs Not an image, a root filesystem (no bootloader/kernel), packed in a .tar.gz
virtualbox Image with VirtualBox guest utilities pre-installed, default format: virtualbox
vmware Image with Open VM Tools pre-installed, default format: vmware
The different formats are:
hyperv VHDX disk image, powershell install scripts
ova streamOptimized VMDK disk image, OVF metadata file, packed in a OVA archive
ovf monolithicSparse VMDK disk image, OVF metadata file
qemu QCOW2 disk image, no metadata
raw sparse disk image, no metadata
virtualbox VDI disk image, .vbox metadata file
vmware 2GbMaxExtentSparse VMDK disk image, VMX metadata file
Supported environment variables:
http_proxy HTTP proxy URL, refer to the README.md for more details
Most useful debos options:
--artifactdir DIR Set artifact directory, default: images
--memory, -m SIZE Limit amount of memory to build VM in GB, default: 4G
--scratchsize SIZE Limit amount of HDD to build VM in GB, default: 45G
--debug-shell Get a shell on the VM
--help, -h See the complete list of options for debos
Refer to the README.md for examples
الخيارات الافتراضية ستبني صورة Kali rolling وسطح المكتب الافتراضي ومجموعة الأدوات الافتراضية لبنية AMD64.
هذه صورة قرص خام (raw)، أي صورة ثنائية بسيطة للقرص (يمكن تشغيلها باستخدام QEMU).
مثال:
$ ./build.sh
لبناء صورة Kali Linux مخصصة لـ VMware. هذا يعني أنها تأتي مع Open VM Tools مثبتة مسبقًا، والصورة الناتجة جاهزة للاستيراد «كما هي» في VMware.
أيضًا، سنبنيها من آخر إصدار مستقر من Kali، وسنستخدم GNOME كبيئة سطح مكتب بدلاً من Xfce الافتراضي المعتاد:
./build.sh -v vmware -b kali-last-snapshot -D gnome
لبناء صورة Kali Linux مصممة لـ VirtualBox. تأتي مع أدوات ضيف VirtualBox مثبتة مسبقًا، ويمكن استيراد الصورة «كما هي» في VirtualBox.
علاوة على ذلك، نريد قرصًا افتراضيًا بسعة 150 جيجابايت، وسنثبّت اختيار أدوات «everything»:
./build.sh -v virtualbox -s 150 -S everything
لبناء صورة Kali خفيفة، لا تحتوي على بيئة سطح مكتب ولا مجموعة الأدوات الافتراضية. هذه صورة عامة (generic)، تأتي مع دعم لمعظم محركات الآلات الافتراضية. سنقوم بتصديرها إلى صيغة OVA، المناسبة لكل من VMware وVirtualBox.
يمكنك تثبيت حزم إضافية باستخدام الخيار -P.
إما استخدام الخيار عدة مرات (مثل -P pkg1 -P pkg2 ...)، أو إعطاء قيمة مفصولة بفواصل/مسافات (مثل -P "pkg1,pkg2, pkg3 pkg4")، أو مزيج من الاثنين.
لنقم أيضًا بتثبيت الحزمة metasploit-framework:
./build.sh -v generic -f ova -D headless -P metasploit-framework
عند بناء سلسلة من الصور، قد يكون من الأنسب (والأسرع) تقسيم البناء إلى جزأين: أولاً، بناء rootfs، ثم بناء الصور بإعادة استخدام هذا rootfs كنقطة انطلاق.
في المثال أدناه، بنينا rootfs بنسخة kali-rolling أولاً، ثم بنينا سلسلة من صور Vagrant:
./build.sh -b kali-rolling -v rootfs
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v hyperv
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v qemu
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v virtualbox
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v vmware
لتعيين keyboard settings، استخدم الخيار -K.
الإعداد يكون بالشكل <layouts>/<models>/<variants>/<options>. يمكن حذف كل إعداد (وفي هذه الحالة يُستخدم الافتراضي)، أو يمكن أن يحتوي على قيم متعددة مفصولة بفواصل. في أبسط الحالات، قد ترغب فقط في تغيير تخطيط لوحة المفاتيح، لذا يمكنك تعيين us لتخطيط لوحة المفاتيح الأمريكية، وde لتخطيط لوحة المفاتيح الألمانية، وهكذا. يمكن العثور على شروحات وأمثلة أطول في صفحة الدليل keyboard(5).
للقائمة بالقيم المدعومة، يمكنك الرجوع إلى الملف /usr/share/X11/xkb/rules/xorg.lst (المقدم من الحزمة xkb-data على أنظمة Debian وما يشابهها). يحتوي هذا الملف على أقسام مختلفة (! layout, ! model, !variant و !option) تسرد القيم المحتملة لكل إعداد.
يمكنك أيضًا التحقق مما هو مكوّن على نظامك باستخدام cat /etc/default/keyboard.
هناك أيضًا اختصار -K same لمطابقة النظام المضيف (أي ما هو مضبوط في الملف /etc/default/keyboard).
لتعيين locale، استخدم الخيار -L.
اختر قيمة من العمود الأول في /usr/share/i18n/SUPPORTED، أو تحقق مما هو مكوّن على نظامك باستخدام grep -v ^# /etc/locale.gen، أو ببساطة echo $LANG.
هناك أيضًا اختصار -L same لمطابقة النظام المضيف.
لتعيين timezone، استخدم الخيار -Z.
ابحث في /usr/share/zoneinfo واختر مجلدًا ومجلدًا فرعيًا.
عند الشك، شغّل tzselect لإرشادك، أو انظر إلى ما هو مكوّن على نظامك باستخدام realpath /etc/localtime.
هناك أيضًا اختصار -Z same لمطابقة النظام المضيف.
لتعيين اسم وكلمة مرور المستخدم غير المميز (unprivileged user)، استخدم الخيار -U.
القيمة عبارة عن سلسلة نصية واحدة ويُستخدم الرمز : لفصل اسم المستخدم عن كلمة المرور.
هنا سنبني صورة Kali ونقوم بإعدادها لمحاكاة النظام المضيف: نفس locale ونفس timezone ونفس اسم المستخدم (مع كلمة مرور password):
./build.sh -K same -L same -Z same -U $USER:password
يمكن بناء أنواع مختلفة من الصور، اعتمادًا على محرك الآلة الافتراضية الذي تريد تشغيل صورة Kali فيه. يحدد النوع (VARIANT) بشكل أساسي الحزمة الإضافية التي سيتم تثبيتها في الصورة، لإضافة دعم لمحرك آلة افتراضية معين. ثم تحدد الصيغة (FORMAT) صيغة القرص الافتراضي، وملفات البيانات الوصفية الإضافية التي سيتم إنتاجها.
إذا لم يتم تعيينها، يتم ضبط الصيغة (الخيار -f) تلقائيًا وفقًا للنوع (الخيار -v).
ليست كل مجموعة من النوع والصيغة منطقية، لذا يحاول الجدول أدناه تلخيص التركيبات الأكثر شيوعًا.
| النوع | الصيغة | صيغة القرص | البيانات الوصفية | الحزمة |
|---|---|---|---|---|
| generic | raw | raw (sparse file) | none | |
| generic | ova | streamOptimized VMDK | OVF | OVA |
| generic | ovf | monolithicSparse VMDK | OVF | |
| qemu | qemu | QCOW2 | none | |
| virtualbox | virtualbox | VDI | VBOX | |
| vmware | vmware | 2GbMaxExtentSparse VMDK | VMX |
صور generic تأتي مع حزم دعم المحاكاة الافتراضية مثبتة مسبقًا لـ QEMU وVirtualBox وVMware، ومن هنا جاء الاسم «generic».
بينما الصور الأخرى التي تستهدف محرك آلة افتراضية معينًا، تأتي فقط مع دعم لمحرك المحاكاة الافتراضية هذا تحديدًا.
فقط الصيغة ova تعرّف حاوية: نتيجة البناء هي ملف .ova، وهو ببساطة أرشيف tar.
بالنسبة للصيغ الأخرى، ينتج البناء ملفات منفصلة.
يمكن تجميعها معًا في أرشيف 7z باستخدام الخيار -z.
هناك أيضًا نوع rootfs: هذه ليست صورة.
إنها ببساطة شجرة نظام ملفات الجذر الخاص بـ Kali Linux، بدون النواة ومحمل الإقلاع، ومعبأة في أرشيف .tar.gz.
حالة الاستخدام الرئيسية هي إعادة استخدامها كمدخل لبناء صورة نظام تشغيل، وليست مخصصة للاستخدام خارج نظام البناء.
عند بناء صور أنظمة التشغيل، من المفيد وجود آلية تخزين مؤقت لتجنب تنزيل جميع الحزم من الإنترنت مرارًا وتكرارًا.
لتحقيق هذا الغرض، يحاول سكربت البناء اكتشاف وكلاء التخزين المؤقت المعروفين الذين قد يعملون على المضيف المحلي.
يشير أولاً إلى تكوين APT المحلي Acquire::http::Proxy. إذا لم يكن معينًا، فإنه يحاول اكتشاف apt-cacher-ng و squid-deb-proxy عن طريق التحقق مما إذا كانت هناك خدمة تستمع على المنفذ الافتراضي الخاص بها.
لا تعمل هذه الآلية مع approx (وهو وكيل تخزين مؤقت معروف لـ APT)، لأنه يبدأ تشغيله تلقائيًا عند الطلب.
لتجاوز هذا الاكتشاف، يمكنك تصدير متغير البيئة http_proxy بنفسك.
ومع ذلك، يجب أن تتذكر أن البناء يحدث داخل آلة افتراضية QEMU، لذلك فإن localhost في بيئة البناء يشير إلى الآلة الافتراضية، وليس إلى المضيف.
إذا كنت تريد الوصول إلى المضيف من الآلة الافتراضية، فمن المرجح أنك تريد استخدام http://10.0.2.2.
على سبيل المثال، إذا كنت تريد استخدام وكيل يعمل على جهازك على المنفذ 9876، استخدم: export http_proxy=http://10.0.2.2:9876.
إذا كنت تريد التأكد من عدم استخدام أي وكيل، استخدم: export http_proxy=.
راجع أيضًا https://github.com/go-debos/debos#environment-variables لمزيد من التفاصيل.
بدلاً من ذلك، يمكنك إعداد مرآة محلية.
من الممكن تقسيم البناء إلى خطوتين.
يمكنك أولاً بناء rootfs باستخدام ./build.sh -v rootfs، ثم بناء صورة بناءً على هذا rootfs باستخدام ./build.sh -r ROOTFS_NAME.tar.gz.
هذا منطقي إذا كنت تخطط لبناء عدة أنواع من الصور، على سبيل المثال.
عندما تمتلئ منطقة المساحة المؤقتة (أي عندما تكون قيمة --scratchsize منخفضة جدًا)، قد يفشل البناء مع هذا النوع من رسائل الخطأ:
[...]: failed to write (No space left on device)
[...]: Cannot write: No space left on device
الحل: ارفع قيمة --scratchsize.
يمكنك تمرير وسائط إلى debos بعد الحرف الخاص --، فإذا احتجت مثلاً إلى 50G، يمكنك تنفيذ ./build.sh [...] -- --scratchsize=50G.
عند تصحيح أخطاء فشل البناء، من المناسب أن يتم إسقاطك في شل داخل الآلة الافتراضية حيث يتم البناء.
هذا ممكن عن طريق إعطاء الخيار --debug-shell لـ debos: ./build.sh [...] -- --debug-shell.
هذه مشكلة معروفة، راجع https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132 للحصول على حل بديل.