> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # تأمين المقسم من الاحتيال على المكالمات Toll Fraud - URL: https://arabroot.io/articles/تأمين-المقسم-من-الاحتيال-على-المكالمات/ - Published: 2026-10-19T08:00:00.000Z - Updated: 2026-10-20T20:47:06.000Z - Description: نهاجم مقسم Asterisk في مختبر معزول بأدوات فحص SIP حقيقية، ثم نسد الثغرات بكلمات مرور قوية وfail2ban وTLS وSRTP ونرى الفرق على الشبكة. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, الشبكات والوصول, الأمن السيبراني, Asterisk في [تتبع مكالمة SIP عبر الشبكة](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A9-sip-%D8%B9%D8%A8%D8%B1-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-%D9%88%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D8%A7%D8%AA%D8%AC%D8%A7%D9%87-%D9%88%D8%A7%D8%AD%D8%AF/#production) قلنا إن المقسم المتصل بخط خارجي هدف دائم للمهاجمين، وإن فتح منفذ SIP لكل الإنترنت يعني أن أي شخص يستطيع أن يجرب كلمات المرور على تحويلاتك. وهذا المقال يفي بذلك الوعد: سوف نبني مقسم Asterisk ضعيف الإعداد عمداً، ثم نهاجمه بالأدوات نفسها التي يستخدمها المهاجم الحقيقي، ونرى كيف يسجل المقسم الهجوم، ثم نسد الثغرة واحدة واحدة حتى يصبح الهجوم نفسه بلا فائدة. والمقصد ليس الإثارة، وإنما أن ترى بعينك ما الذي يحميك فعلاً وما الذي يبدو حماية وليس كذلك. المواضيع في السلسلة: - [مصطلحات الاتصالات الهاتفية VoIP للمبتدئين](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-voip-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) - [تتبع مكالمة SIP عبر الشبكة: لماذا يصل الصوت في اتجاه واحد؟](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A9-sip-%D8%B9%D8%A8%D8%B1-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-%D9%88%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D8%A7%D8%AA%D8%AC%D8%A7%D9%87-%D9%88%D8%A7%D8%AD%D8%AF/) - [لماذا يتقطع الصوت في مكالمات VoIP؟ قياس Jitter وPacket Loss](https://arabroot.io/articles/%D9%84%D9%85%D8%A7%D8%B0%D8%A7-%D9%8A%D8%AA%D9%82%D8%B7%D8%B9-%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A7%D8%AA-voip/) - [ربط المقسم PBX بشبكة الهاتف عبر SIP Trunk والأرقام DID](https://arabroot.io/articles/%D8%B1%D8%A8%D8%B7-%D8%A7%D9%84%D9%85%D9%82%D8%B3%D9%85-%D8%A8%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D9%87%D8%A7%D8%AA%D9%81-%D8%B9%D8%A8%D8%B1-sip-trunk/) - [دليل Asterisk العملي: من التحويلة Extension إلى الرد الآلي IVR](https://arabroot.io/articles/%D8%AF%D9%84%D9%8A%D9%84-asterisk-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D9%8A-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A9-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%B1%D8%AF-%D8%A7%D9%84%D8%A7%D9%84%D9%8A/) - [FreePBX: مقسم هاتف PBX كامل تديره من المتصفح](https://arabroot.io/articles/freepbx-%D9%85%D9%82%D8%B3%D9%85-%D9%87%D8%A7%D8%AA%D9%81-%D9%83%D8%A7%D9%85%D9%84-%D8%AA%D8%AF%D9%8A%D8%B1%D9%87-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AA%D8%B5%D9%81%D8%AD/) - [FreeSWITCH للمنصات الكبيرة ومراكز الاتصال Contact Center](https://arabroot.io/articles/freeswitch-%D9%84%D9%84%D9%85%D9%86%D8%B5%D8%A7%D8%AA-%D8%A7%D9%84%D9%83%D8%A8%D9%8A%D8%B1%D8%A9-%D9%88%D9%85%D8%B1%D8%A7%D9%83%D8%B2-%D8%A7%D9%84%D8%A7%D8%AA%D8%B5%D8%A7%D9%84/) - [3CX أم FreePBX أم FreeSWITCH؟ كيف تختار المقسم PBX](https://arabroot.io/articles/3cx-%D8%A7%D9%85-freepbx-%D8%A7%D9%85-freeswitch/) - [هواتف SIP المكتبية والتطبيقات: لماذا لا يرن الجوال النائم؟](https://arabroot.io/articles/%D9%87%D9%88%D8%A7%D8%AA%D9%81-sip-%D8%A7%D9%84%D9%85%D9%83%D8%AA%D8%A8%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%AC%D9%88%D8%A7%D9%84/) - [مركز اتصال Call Center على Asterisk: الطابور وتقرير SLA](https://arabroot.io/articles/%D9%85%D8%B1%D9%83%D8%B2-%D8%A7%D8%AA%D8%B5%D8%A7%D9%84-call-center-%D8%B9%D9%84%D9%89-asterisk/) - تأمين المقسم من الاحتيال على المكالمات Toll Fraud (الموضوع الحالي) - [موازنة الحمل Load Balancing أمام خوادم Asterisk مع Kamailio](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%B2%D9%86%D8%A9-%D8%A7%D9%84%D8%AD%D9%85%D9%84-%D8%A3%D9%85%D8%A7%D9%85-%D8%AE%D9%88%D8%A7%D8%AF%D9%85-asterisk-%D9%85%D8%B9-kamailio/) وكل ما في هذا المقال يعمل داخل شبكة Docker داخلية معزولة لا طريق لها إلى الإنترنت، والماسح والمقسم كلاهما Container على جهازك أنت، فلا تهاجم بهذه الأدوات أي نظام لا تملكه، والسبب أن فحص مقسم لا تملكه جريمة في أغلب الأنظمة، ومنها نظام مكافحة الجرائم المعلوماتية في المملكة. وهذا المقال من [مرحلة الاتصالات الهاتفية VoIP](https://arabroot.io/start/#stage-voip)، وفيما يلي ترتيب مقالات المرحلة: - [مصطلحات الاتصالات الهاتفية VoIP للمبتدئين](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-voip-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) - [تتبع مكالمة SIP عبر الشبكة: لماذا يصل الصوت في اتجاه واحد؟](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A9-sip-%D8%B9%D8%A8%D8%B1-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-%D9%88%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D8%A7%D8%AA%D8%AC%D8%A7%D9%87-%D9%88%D8%A7%D8%AD%D8%AF/) - جودة الصوت: الترميز Codecs والتأخير Latency والاهتزاز Jitter وQoS - ربط المقسم بشبكة الهاتف: SIP Trunk والأرقام DID - Asterisk: المحرك الذي بنيت عليه أغلب أنظمة الاتصالات - FreePBX: مقسم هاتف كامل بواجهة إدارة - FreeSWITCH للمنصات الكبيرة ومراكز الاتصال - 3CX أم FreePBX أم FreeSWITCH؟ - هواتف المكتب والتطبيقات: أجهزة SIP وLinphone وتطبيقات الجوال - مركز اتصال Call Center: الطوابير والتسجيل والتقارير - تأمين المقسم من الاحتيال على المكالمات Toll Fraud (المقال الحالي) - توجيه SIP وموازنته للمنصات الكبيرة مع Kamailio وسوف نتناول فيه ما يلي: - ما هو الاحتيال على المكالمات Toll Fraud، وقضية حقيقية موثقة بخسائر تجاوزت سبعين مليون دولار. - فحص المقسم بأداة sipvicious: اكتشاف السيرفر svmap، وتعداد التحويلات svwar، وكسر كلمة المرور svcrack. - سجل أحداث الأمان Security Events في Asterisk، وكيف يحظر fail2ban الماسح تلقائياً. - التحصين: كلمات المرور القوية، وقوائم التحكم ACL، ومنع المكالمات المجهولة، وتقييد الاتصال الدولي. - تشفير الإشارة بـ SIP over TLS وتشفير الصوت بـ SRTP، مع التقاط يبين الفرق على الشبكة. ## ما هو الاحتيال على المكالمات Toll Fraud؟ الاحتيال على المكالمات Toll Fraud هو أن يسيطر مهاجم على مقسمك ويستخدمه ليجري مكالمات مدفوعة على حسابك، والفاتورة تأتيك أنت. والصورة الكلاسيكية أن المهاجم يسجل أرقاماً دولية باهظة التكلفة أو أرقام خدمات مدفوعة Premium Rate Numbers يملكها هو أو شريكه، ثم يخترق مقسم شركة ما، ويجعله يتصل بهذه الأرقام آلاف المرات في عطلة نهاية الأسبوع عندما لا يراقب أحد، فيتقاسم مع صاحب الرقم ما تدفعه الشركة لمشغل الاتصالات. وهذه ليست نظرية، وإنما نموذج عمل إجرامي كامل له من ينفذه ومن يغسل أمواله. والصورة التالية تبين كيف تتحرك المكالمة والمال في هذا النوع من الاحتيال: ![مهاجم على الإنترنت يفحص مقسم شركة الضحية ويكسر كلمة مرور تحويلة ضعيفة، ثم يجعل المقسم يتصل بأرقام خدمات مدفوعة Premium Rate Numbers وأرقام دولية يملكها المهاجم، فيدفع مشغل الاتصالات لصاحب الرقم المدفوع، وتصل الفاتورة الضخمة إلى الشركة الضحية](https://arabroot.io/content/images/2026/10/pbx-security-01-toll-fraud.webp) المهاجم لا يسرق بياناتك، وإنما يبيع دقائق مكالمات على حسابك ولتعرف حجم المسألة على أرض الواقع، فهذه قضية موثقة أمام القضاء الأمريكي، نذكرها لأنها تبين الآلية نفسها التي سنجربها بعد قليل: 📌 في مايو 2017 حكمت محكمة اتحادية في ولاية نيوجيرسي على محمد سهيل قاسماني بالسجن 48 شهراً لأنه غسل أكثر من 19.6 مليون دولار لصالح عصابة اختراق مقاسم هاتفية قادها نور عزيز، وبلغ إجمالي خسائر الضحايا ما يتجاوز سبعين مليون دولار بحسب [بيان وزارة العدل الأمريكية](https://www.justice.gov/usao-nj/pr/man-who-laundered-millions-massive-computer-hacking-and-telecommunications-fraud-scheme?ref=arabroot.io). وكانت الطريقة أن المهاجمين يفحصون مقاسم PBX لشركات أمريكية بحثاً عن تحويلات غير مستخدمة، ثم يعيدون برمجتها لإجراء مكالمات دولية غير محدودة تحمل على حساب الشركات الضحية، وتوجه إلى أرقام خدمات مدفوعة وهمية لا تقدم خدمة حقيقية. وحول قاسماني وحده الأموال إلى نحو 650 مستفيداً في عشر دول على الأقل من بينها المملكة العربية السعودية. ولاحظ في هذه القضية ثلاث نقاط تهمك مباشرة: الأولى أن الهدف ليس بياناتك وإنما قدرة مقسمك على الاتصال، والثانية أن الهجوم يبدأ دائماً بالبحث عن تحويلة ضعيفة، والثالثة أن الضحية شركات عادية ظنت أن مقسمها لا يعني أحداً. وسوف نرى الآن كل خطوة من هذه الخطوات في مختبرنا. ## خريطة المختبر نبني في المختبر مقسم Asterisk واحداً، ونضع على الشبكة نفسها Container يلعب دور المهاجم، وفيه أدوات فحص SIP الحقيقية. والشبكة شبكة Docker داخلية أنشأناها بالخيار `--internal`، فلا طريق لها إلى الإنترنت أصلاً، ولا يوجد منفذ واحد مفتوح على جهازك، وبذلك يبقى كل الهجوم حبيساً بين Containers نملكها. والصورة التالية تبين الخريطة: ![شبكة Docker داخلية باسم are-pbxsec-net على النطاق 10.44.60.0/24، فيها مقسم Asterisk باسم are-pbxsec-pbx على العنوان 10.44.60.10 بمنفذ SIP 5060 وTLS 5061، وContainer المهاجم are-pbxsec-scan على العنوان 10.44.60.66 يحمل أدوات sipvicious، وهاتفان برمجيان على 10.44.60.30 و10.44.60.31، والشبكة معزولة بلا طريق إلى الإنترنت](https://arabroot.io/content/images/2026/10/pbx-security-02-lab-map.webp) المهاجم والمقسم كلاهما Container على جهازك، والشبكة الداخلية معزولة تماماً ولأنه لا توجد Image رسمية جاهزة تجمع المقسم وأدوات الفحص، سوف نبني Image واحدة من Ubuntu 24.04 فيها كل ما نحتاجه، ونثبت إصدار كل حزمة حتى تحصل على النتيجة نفسها: Asterisk مقسماً، و[sipvicious](https://github.com/EnableSecurity/sipvicious?ref=arabroot.io) أدوات الفحص، و[fail2ban](https://github.com/fail2ban/fail2ban?ref=arabroot.io) للحظر التلقائي، وtcpdump وsngrep لقراءة الحزم، وopenssl و[baresip](https://github.com/baresip/baresip?ref=arabroot.io) لتجربة التشفير. قم بإنشاء مجلد للمختبر وضع فيه الملف `Dockerfile` التالي: ```dockerfile FROM ubuntu:24.04 RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \ asterisk=1:20.6.0~dfsg+~cs6.13.40431414-2build5 \ asterisk-config=1:20.6.0~dfsg+~cs6.13.40431414-2build5 \ sipvicious=0.3.3-2 \ fail2ban=1.0.2-3ubuntu0.1 \ sngrep=1.8.0-1build2 \ tcpdump=4.99.4-3ubuntu4.24.04.1 \ openssl=3.0.13-0ubuntu3.16 \ baresip-core=1.0.0-4build14 \ sox iproute2 iptables iputils-ping python3 ca-certificates \ && rm -rf /var/lib/apt/lists/* ``` ⚠️ إصدار Asterisk في حزمة Ubuntu قديم (20.6.0)، وقد اخترناه لأنه أسرع طريق لمختبر قصير فقط. لا تقم باستخدام هذه الـ Image لمقسم حقيقي، والسبب أن المقسم المكشوف هدف دائم، فابدأ من إصدار مدعوم بحسب [جدول إصدارات Asterisk](https://docs.asterisk.org/About-the-Project/Asterisk-Versions/?ref=arabroot.io)، وسوف نفرد لتثبيت Asterisk للإنتاج دليلاً مستقلاً في هذه المرحلة. نبني الـ Image ثم نتأكد من وجود الأدوات: ```bash docker build -t are-pbxsec-tools:1 . docker run --rm are-pbxsec-tools:1 asterisk -V docker run --rm are-pbxsec-tools:1 svmap --version ``` والمخرج سوف يكون كما يلي: ```text Asterisk 20.6.0~dfsg+~cs6.13.40431414-2build5 svmap v0.3.3 ``` ## مقسم ضعيف عمداً الآن نجهز إعداد المقسم، وقد جعلناه ضعيفاً في موضع واحد بقصد: التحويلة 1001 كلمة مرورها هي رقمها نفسه، وهو أكثر خطأ شائع في المقاسم الحقيقية، أما التحويلة 1002 فكلمة مرورها طويلة. وهذا هو ملف `asterisk/pjsip.conf` الذي يعرف التحويلات عبر وحدة PJSIP كما شرحناها في [المقال السابق](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A9-sip-%D8%B9%D8%A8%D8%B1-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-%D9%88%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D8%A7%D8%AA%D8%AC%D8%A7%D9%87-%D9%88%D8%A7%D8%AD%D8%AF/#lab-asterisk): ```text [global] type=global user_agent=ArabRoot-Lab-PBX [transport-udp] type=transport protocol=udp bind=0.0.0.0:5060 [phone](!) type=endpoint context=internal disallow=all allow=ulaw,alaw rtp_symmetric=yes force_rport=yes rewrite_contact=yes [1001](phone) auth=1001 aors=1001 callerid="Reception" <1001> [1001] type=auth auth_type=userpass username=1001 password=1001 [1001] type=aor max_contacts=1 [1002](phone) auth=1002 aors=1002 callerid="Manager" <1002> [1002] type=auth auth_type=userpass username=1002 password=S3cureManager [1002] type=aor max_contacts=1 ``` وبقية الملفات قصيرة: خطة اتصال داخلية في `asterisk/extensions.conf`، ونطاق منافذ RTP في `asterisk/rtp.conf`، وأهمها إعداد السجلات في `asterisk/logger.conf` حيث أضفنا سطراً واحداً يفتح سجل أحداث الأمان، وسوف نحتاجه كثيراً: ```bash mkdir -p asterisk cat > asterisk/extensions.conf <<'EOF' [internal] exten => _10XX,1,NoOp(Internal ${CALLERID(num)} -> ${EXTEN}) same => n,Dial(PJSIP/${EXTEN},20) same => n,Hangup() EOF cat > asterisk/rtp.conf <<'EOF' [general] rtpstart=10000 rtpend=10099 EOF cat > asterisk/logger.conf <<'EOF' [general] [logfiles] console => notice,warning,error,verbose security => security EOF ``` السطر `security => security` يطلب من Asterisk أن يكتب أحداث الأمان في ملف منفصل اسمه `security`، وهذا هو ما تذكره [وثائق مسجل أحداث الأمان](https://docs.asterisk.org/Deployment/Asterisk-Security-Framework/Asterisk-Security-Event-Logger/?ref=arabroot.io) في Asterisk. الآن ننشئ الشبكة الداخلية المعزولة ونشغل المقسم: ```bash docker network create --internal --subnet 10.44.60.0/24 are-pbxsec-net docker run -d --name are-pbxsec-pbx --network are-pbxsec-net --ip 10.44.60.10 \ --cap-add NET_ADMIN --cap-add NET_RAW \ -v "$PWD/asterisk/pjsip.conf:/etc/asterisk/pjsip.conf" \ -v "$PWD/asterisk/extensions.conf:/etc/asterisk/extensions.conf" \ -v "$PWD/asterisk/rtp.conf:/etc/asterisk/rtp.conf" \ -v "$PWD/asterisk/logger.conf:/etc/asterisk/logger.conf" \ are-pbxsec-tools:1 asterisk -f docker exec are-pbxsec-pbx asterisk -rx 'pjsip show endpoints' ``` والمخرج سوف يكون كما يلي، ولاحظ أن التحويلتين `Unavailable` لأن أي هاتف لم يسجل بعد: ```text Endpoint: 1001/1001 Unavailable 0 of inf Endpoint: 1002/1002 Unavailable 0 of inf Objects found: 2 ``` ## فحص المقسم: من svmap إلى svcrack أدوات [sipvicious](https://github.com/EnableSecurity/sipvicious?ref=arabroot.io) ثلاث خطوات متتابعة يمر بها المهاجم، وهي نفسها التي يستخدمها مختبر الاختراق لتقييم مقسمه، ونشغلها كلها من Container منفصل على العنوان 10.44.60.66. ### svmap: أين المقسم وما هو؟ أول ما يفعله المهاجم هو مسح الشبكة بحثاً عمن يرد على بروتوكول SIP، وهذا عمل `svmap`، فنعطيه نطاق الشبكة كله: ```bash docker run --rm --network are-pbxsec-net --ip 10.44.60.66 \ are-pbxsec-tools:1 svmap 10.44.60.0/24 ``` والمخرج سوف يكون كما يلي: ```text +------------------+------------------+ | SIP Device | User Agent | +==================+==================+ | 10.44.60.10:5060 | ArabRoot-Lab-PBX | +------------------+------------------+ ``` في المخرج أعلاه لاحظ التالي: المقسم أعلن عن نفسه فوراً، بل أعلن أيضاً اسمه في ترويسة `User-Agent`، وهو هنا `ArabRoot-Lab-PBX` لأننا كتبناه بأنفسنا، أما في مقسم غير معد جيداً فيكون شيئاً مثل `Asterisk PBX 20.6.0`، فيعرف المهاجم نوع المقسم وإصداره، ومنها يعرف ثغراته المعروفة. وتغيير هذه الترويسة إلى قيمة عامة لا يمنع الهجوم، ولكنه يقلل المعلومة التي تهديها للمهاجم مجاناً. ### svwar: ما هي التحويلات الموجودة؟ الخطوة التالية أن يعرف المهاجم أرقام التحويلات، وهذا عمل `svwar`، فيجرب مدى من الأرقام ويستنتج الموجود من رد المقسم. نجرب المدى من 1000 إلى 1010: ```bash docker run --rm --network are-pbxsec-net --ip 10.44.60.66 \ are-pbxsec-tools:1 svwar -e 1000-1010 10.44.60.10 ``` والمخرج سوف يكون كما يلي: ```text ERROR:TakeASip:SIP server replied with an authentication request for an unknown extension. Set --force to force a scan. WARNING:root:found nothing ``` وهنا نتوقف عند نتيجة مهمة: الأداة فشلت في تعداد التحويلات، والسبب أن وحدة PJSIP الحديثة ترد بالرسالة `401 Unauthorized` على كل اسم مستخدم سواء كان موجوداً أو غير موجود، فلا يستطيع الماسح أن يفرق بين الموجود والمعدوم. وهذا سلوك أفضل بكثير من الوحدة القديمة chan\_sip التي كانت ترد برسالة مختلفة للتحويلة الموجودة، فتهدي المهاجم قائمة تحويلاتك. وإذا أجبرت الأداة بالخيار `--force` فسوف ترى الرد نفسه لكل رقم: ```text WARNING:TakeASip:Bad user = SIP/2.0 401 - svwar will probably not work! ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized ... Server: ArabRoot-Lab-PBX ...' ``` ولكن لا تفرح كثيراً، فالمهاجم لا يحتاج تعداد التحويلات أصلاً، والسبب أن أرقام التحويلات متوقعة: 1000 و1001 و1002، فهي أول ما يجربه أي مهاجم، لذلك ننتقل مباشرة إلى الخطوة الأخطر. ### svcrack: كسر كلمة المرور الأداة `svcrack` تجرب كلمات مرور كثيرة على تحويلة واحدة حتى تنجح واحدة، ونوجهها إلى التحويلة 1001 بمدى أرقام من 1000 إلى 1100 ككلمات مرور محتملة: ```bash docker run --rm --network are-pbxsec-net --ip 10.44.60.66 \ are-pbxsec-tools:1 svcrack -u 1001 -r 1000-1100 10.44.60.10 ``` والمخرج سوف يكون كما يلي: ```text +-----------+----------+ | Extension | Password | +===========+==========+ | 1001 | 1001 | +-----------+----------+ ``` كسرت الأداة التحويلة 1001 في ثوان، لأن كلمة مرورها هي رقمها نفسه. والآن أصبح المهاجم يملك تحويلة صالحة على مقسمك، وبها يستطيع أن يسجل هاتفاً ويجري مكالمات على حسابك، وهذا بالضبط ما حدث في قضية وزارة العدل التي ذكرناها. ولنتأكد أن قوة كلمة المرور هي الفرق، نوجه الأداة نفسها إلى التحويلة 1002 ذات كلمة المرور الطويلة: ```bash docker run --rm --network are-pbxsec-net --ip 10.44.60.66 \ are-pbxsec-tools:1 svcrack -u 1002 -r 1000-1050 10.44.60.10 ``` ```text WARNING:root:found nothing ``` لم تنجح الأداة، لأن كلمة المرور ليست في المدى الذي تجربه، وهذا هو الدرس الأول والأهم: كلمة المرور القوية وحدها تحول الهجوم من دقائق إلى عمر كامل من المحاولات. ولكن قوة كلمة المرور لا تمنع المحاولة نفسها، فلنر ماذا سجل المقسم من كل هذا. ## ماذا سجل المقسم؟ أحداث الأمان Security Events كل محاولة من الماسح تركت أثراً في سجل أحداث الأمان الذي فتحناه في `logger.conf`، وهو ملف منفصل يفصل أحداث الأمان عن بقية السجلات حتى تسهل مراقبتها. نقرأ أنواع الأحداث فيه ونعدها: ```bash docker exec are-pbxsec-pbx sh -c \ "grep -oE 'SecurityEvent=\"[A-Za-z]+\"' /var/log/asterisk/security | sort | uniq -c" ``` والمخرج سوف يكون كما يلي: ```text 52 SecurityEvent="ChallengeResponseFailed" 16 SecurityEvent="ChallengeSent" 7 SecurityEvent="InvalidAccountID" 1 SecurityEvent="SuccessfulAuth" ``` في المخرج أعلاه لاحظ التالي: - `ChallengeResponseFailed` هي محاولات كلمة المرور الخاطئة، و52 محاولة فاشلة في دقائق قليلة من عنوان واحد علامة لا تخطئها عين. - `InvalidAccountID` محاولات على تحويلات غير موجودة، أي تعداد التحويلات الذي رأيناه. - `SuccessfulAuth` مرة واحدة: هي اللحظة التي كسر فيها الماسح التحويلة 1001، وهي أخطر سطر في الملف. وكل سطر يحمل العنوان الذي جاء منه الهجوم بوضوح، وهذا سطر النجاح الخطير كاملاً: ```text [Oct 20 07:51:33] SECURITY[78] res_security_log.c: SecurityEvent="SuccessfulAuth",EventTV="2026-10-20T07:51:33.211+0000",Severity="Informational",Service="PJSIP",EventVersion="1",AccountID="1001",SessionID="1577822765",LocalAddress="IPV4/UDP/10.44.60.10/5060",RemoteAddress="IPV4/UDP/10.44.60.66/5060",UsingPassword="1" ``` الحقل `RemoteAddress` يقول إن المصدر هو 10.44.60.66، وهو الماسح، والحقل `AccountID` يقول إن التحويلة المكسورة هي 1001\. ومن هذا السطر بالضبط سوف يتعلم fail2ban من يحظر. ## حظر الماسح تلقائياً مع fail2ban أن ترى الهجوم في السجل شيء، وأن تردعه شيء آخر، فلا يعقل أن يراقب أحد السجل على مدار الساعة. وهنا يأتي دور [fail2ban](https://github.com/fail2ban/fail2ban?ref=arabroot.io)، وهو أداة تراقب ملف سجل، فإذا تكرر منها نمط فشل من عنوان واحد أكثر من حد معين، أضافت قاعدة في جدار الحماية تحظر ذلك العنوان لمدة. والفكرة بسيطة: المحاولات الفاشلة الكثيرة من عنوان واحد تعني مهاجماً، فاطرده. ⚠️ المرشح الجاهز باسم asterisk الذي يأتي مع fail2ban مكتوب لصيغة سجل الوحدة القديمة chan\_sip (أسطر مثل «Registration from … failed»)، وهو لا يطابق صيغة سجل أحداث الأمان الحديثة التي تنتجها PJSIP. وهذا خطأ شائع يجعل الناس يظنون أن fail2ban يعمل وهو لا يحظر شيئاً، لذلك سوف نكتب مرشحاً يطابق صيغة سجل الأمان الفعلية. نكتب مرشحاً خاصاً في `asterisk/fail2ban/asterisk-pjsip.conf` يلتقط أحداث فشل المصادقة ويستخرج منها العنوان: ```ini [Definition] failregex = ^.*SecurityEvent="(?:ChallengeResponseFailed|InvalidPassword|InvalidAccountID)".*RemoteAddress="IPV[46]/(?:UDP|TCP|TLS|WS|WSS)//\d+" datepattern = ^\[%%b %%d %%H:%%M:%%S\] ``` ونعرف الحظر في `asterisk/fail2ban/jail.local`، ولاحظ السطر `backend = polling`، فهو مهم: ```ini [asterisk-pjsip] enabled = true backend = polling filter = asterisk-pjsip logpath = /var/log/asterisk/security maxretry = 5 findtime = 600 bantime = 3600 action = iptables-allports[name=asterisk, protocol=all] ``` 🛑 القيمة الافتراضية لمصدر المراقبة في fail2ban داخل هذه البيئة هي systemd، فيحاول قراءة سجل النظام بدل ملفنا، فلا يرى شيئاً ولا يحظر أحداً. ولهذا وضعنا `backend = polling` صراحة ليراقب الملف الذي حددناه في `logpath`. وهذا مثال على «حماية موجودة لكنها لا تعمل»، وهي أخطر من غياب الحماية، لأنك تظن نفسك محمياً. قبل أن نشغل fail2ban نتأكد أن المرشح يطابق السجل فعلاً بأداته `fail2ban-regex`، فننسخ المرشح إلى مكانه ونختبره على السجل الحقيقي: ```bash docker cp asterisk/fail2ban/asterisk-pjsip.conf \ are-pbxsec-pbx:/etc/fail2ban/filter.d/asterisk-pjsip.conf docker cp asterisk/fail2ban/jail.local are-pbxsec-pbx:/etc/fail2ban/jail.local docker exec are-pbxsec-pbx \ fail2ban-regex /var/log/asterisk/security /etc/fail2ban/filter.d/asterisk-pjsip.conf ``` والمخرج المهم منه سطر واحد: ```text Lines: 77 lines, 0 ignored, 59 matched, 18 missed ``` طابق المرشح 59 سطراً من أسطر الفشل، وتجاهل الباقي مثل سطر النجاح وأسطر إرسال التحدي، وهو ما نريده بالضبط. الآن نفرغ السجل القديم حتى يكون الحظر من هجوم جديد واضحاً، ونشغل fail2ban: ```bash docker exec are-pbxsec-pbx sh -c ': > /var/log/asterisk/security' docker exec are-pbxsec-pbx fail2ban-client start docker exec are-pbxsec-pbx fail2ban-client status asterisk-pjsip ``` والمخرج سوف يكون كما يلي، ولاحظ السطر `File list` الذي يؤكد أن fail2ban يراقب ملفنا لا سجل النظام: ```text Status for the jail: asterisk-pjsip |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- File list: /var/log/asterisk/security `- Actions |- Currently banned: 0 |- Total banned: 0 `- Banned IP list: ``` الآن نعيد الهجوم من الماسح نفسه، ثم نسأل fail2ban عن حالته: ```bash docker run --rm --network are-pbxsec-net --ip 10.44.60.66 \ are-pbxsec-tools:1 svcrack -u 1002 -r 1000-1200 10.44.60.10 docker exec are-pbxsec-pbx fail2ban-client status asterisk-pjsip ``` والمخرج سوف يكون كما يلي، وانظر إلى آخر سطر: ```text `- Actions |- Currently banned: 1 |- Total banned: 1 `- Banned IP list: 10.44.60.66 ``` حظر fail2ban العنوان 10.44.60.66 في منتصف الهجوم. والماسح نفسه شعر بذلك، فقد توقف وطبع رسالة أنه لم يتلق رداً منذ عشر ثوان: ```text WARNING:ASipOfRedWine:It has been 10.004770278930664 seconds since we last received a response - stopping ``` والحظر فعلي في جدار الحماية، فقد أضاف fail2ban قاعدة في سلسلة `f2b-asterisk` نراها كما يلي: ```bash docker exec are-pbxsec-pbx iptables -L f2b-asterisk -n ``` ```text Chain f2b-asterisk (1 references) target prot opt source destination REJECT 0 -- 10.44.60.66 0.0.0.0/0 reject-with icmp-port-unreachable RETURN 0 -- 0.0.0.0/0 0.0.0.0/0 ``` ولنتأكد من أثر الحظر على المهاجم، نجعله يعيد أبسط خطوة، أي مسح المقسم بـ svmap الذي نجح في أول المقال: ```bash docker run --rm --network are-pbxsec-net --ip 10.44.60.66 \ are-pbxsec-tools:1 svmap 10.44.60.10 ``` ```text WARNING:root:found nothing ``` العنوان نفسه الذي رأى المقسم بوضوح قبل قليل لم يعد يرى شيئاً، لأن جدار الحماية يرفض كل حزمة منه. وهكذا أغلقنا الحلقة: الهجوم يحدث، والمقسم يسجله، وfail2ban يحظره دون تدخل منك. ولكن الحظر علاج بعد وقوع المحاولة، والأصل أن نقفل الباب قبل ذلك، وهذا هو التحصين. ## التحصين: كلمات المرور وACL والمكالمات المجهولة الحظر التلقائي طبقة أخيرة، وقبلها طبقات تمنع المحاولة من أن تنجح أصلاً، وهذه أهمها. ### كلمات مرور طويلة وعشوائية رأينا أن التحويلة 1001 سقطت في ثوان لأن كلمة مرورها رقمها، وأن 1002 صمدت. فاجعل كل كلمة مرور تحويلة طويلة وعشوائية ولا علاقة لها برقم التحويلة، وولدها من أداة لا من رأسك، مثل `openssl rand -base64 18`، وذلك لأن المهاجم يجرب القوائم الشائعة أولاً: رقم التحويلة، و1234، وكلمة password، واسم الشركة. ولا تعط موظفاً كلمة مرور تحويلة يكتبها بنفسه، فالاتساق هنا أهم من الراحة. ### قوائم التحكم في الوصول ACL إذا كانت كل هواتفك في مكاتبك أو تصل عبر شبكة خاصة، فلا داعي أن يقبل المقسم تسجيلاً من أي عنوان في العالم. ووحدة PJSIP تتيح قائمة تحكم ACL تسمح بنطاقات وترفض ما عداها، نكتبها قسماً مستقلاً ونربطها كما في [وثائق PJSIP](https://docs.asterisk.org/Configuration/Channel-Drivers/SIP/Configuring-res%5Fpjsip/PJSIP-Configuration-Sections-and-Relationships/?ref=arabroot.io): ```text [lab-acl] type=acl deny=0.0.0.0/0 permit=10.44.60.0/24 ``` وبهذا يرفض المقسم أي حزمة من خارج شبكتك قبل أن يصل الأمر إلى المصادقة أصلاً، فلا يرى الماسح البعيد شيئاً. وهذه الطبقة وحدها تلغي معظم هجمات الإنترنت، لأن أغلب الماسحات تأتي من عناوين لا تخص موظفيك. ### امنع المكالمات المجهولة بعض المقاسم معدة لتقبل مكالمة من مصدر لا يحمل مصادقة، وتسمى المكالمة المجهولة Anonymous أو Guest، وهي باب خلفي كامل للاحتيال. والقاعدة أن لا يقبل المقسم مكالمة إلا من تحويلة معروفة، وفي PJSIP يتحقق هذا بألا تنشئ تحويلة باسم `anonymous`، وبأن تحذف الكلمة من ترتيب التعرف على المتصل في القسم العام حتى لا يحاول المقسم أصلاً أن يعامل المجهول كتحويلة: ```text [global] type=global endpoint_identifier_order=ip,username ``` ### قيود الاتصال الدولي وحدوده حتى لو كسر المهاجم تحويلة، فالخسارة الكبرى تأتي من الاتصال الدولي باهظ الثمن، لذلك اجعل خطة الاتصال ترفض البادئة الدولية افتراضياً، ولا تسمح بها إلا لمن يحتاجها فعلاً. والمثال التالي يرفض أي رقم يبدأ بالبادئة الدولية 00، ويضع سقفاً لعدد المكالمات الخارجية المتزامنة حتى لا يفرغ المهاجم رصيدك في دقائق: ```text [outbound] ; ارفض الاتصال الدولي افتراضياً (00 بادئة دولية) exten => _00.,1,Hangup(21) ; المكالمات الخارجية المحلية: سقف عشر مكالمات متزامنة exten => _0[1-9]XXXXXXXX,1,Set(GROUP()=outbound) same => n,GotoIf($[${GROUP_COUNT(outbound)} > 10]?busy) same => n,Dial(PJSIP/${EXTEN}@trunk,60) same => n,Hangup() same => n(busy),Hangup(42) ``` الرمز 21 يعني أن المكالمة مرفوضة، والرمز 42 يعني أن القناة مزدحمة، وبهذين السطرين يتحول اختراق تحويلة واحدة من كارثة مالية إلى إزعاج محدود. ولاحظ أن هذا المثال يفترض وجود خط خارجي Trunk، وسوف نفصل ربط المقسم بالخط الخارجي في مقال SIP Trunk من هذه المرحلة. ## تشفير الإشارة: SIP over TLS كل ما سبق يحمي من يسجل على مقسمك، ولكن تبقى مشكلة أخرى: رسائل SIP والصوت تمر على الشبكة نصاً صريحاً، فمن يلتقط الحزم في الطريق يقرأ كل شيء. ولنر ذلك بأعيننا، نلتقط رسائل SIP العادية على المنفذ 5060 أثناء مكالمة، ونطبع ما فيها: ```bash docker exec -d are-pbxsec-pbx tcpdump -i eth0 -n -s0 -w /tmp/plain.pcap 'udp port 5060' # ... هاتف يتصل بآخر عبر المقسم ... docker exec are-pbxsec-pbx sh -c "tcpdump -r /tmp/plain.pcap -n -A 2>/dev/null | sed -n '/INVITE sip:1002/,/^$/p'" ``` والمخرج يحتوي على الرسالة كاملة ومقروءة، بما فيها بيانات المصادقة نفسها: ```text INVITE sip:1002@10.44.60.10 SIP/2.0 Via: SIP/2.0/UDP 10.44.60.30:5060;branch=z9hG4bKaebc45f4679a03dc;rport Contact: Authorization: Digest username="1001", realm="asterisk", nonce="1792483345/61aacc...", uri="sip:1002@10.44.60.10", response="bb99468e37fb7f754d32e2d5345548df", ... Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER ``` من يلتقط هذه الحزمة يعرف من يتصل بمن، ويحصل على ترويسة `Authorization` كاملة ليحاول كسرها في وقته. والحل أن تمر الإشارة داخل نفق TLS على المنفذ 5061، تماماً كما يحمي HTTPS تصفح الويب. نجهز أولاً شهادة للمقسم موقعة من سلطة شهادات صغيرة خاصة بالمختبر: ```bash openssl req -x509 -newkey rsa:2048 -nodes -keyout ca.key -out ca.crt -days 825 \ -subj "/CN=ArabRoot Lab CA" openssl req -newkey rsa:2048 -nodes -keyout asterisk.key -out asterisk.csr \ -subj "/CN=10.44.60.10" printf "subjectAltName=IP:10.44.60.10\n" > san.ext openssl x509 -req -in asterisk.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out asterisk.crt -days 825 -extfile san.ext ``` ثم نضيف إلى `pjsip.conf` ناقلاً يعمل بـ TLS على 5061 ونحمله الشهادة، كما في [دليل Asterisk للمكالمات الآمنة](https://docs.asterisk.org/Deployment/Secure-Calling/Secure-Calling-Tutorial/?ref=arabroot.io): ```text [transport-tls] type=transport protocol=tls bind=0.0.0.0:5061 cert_file=/etc/asterisk/keys/asterisk.crt priv_key_file=/etc/asterisk/keys/asterisk.key method=tlsv1_2 ``` بعد نسخ الشهادة إلى المقسم وإعادة تحميل الإعداد، نتأكد أن الناقل يعمل بالاتصال به عبر openssl من Container آخر، ومعنا شهادة سلطة المختبر للتحقق: ```bash openssl s_client -connect 10.44.60.10:5061 -CAfile ca.crt ``` والمخرج المهم منه الأسطر التالية: ```text depth=1 CN = ArabRoot Lab CA depth=0 CN = 10.44.60.10 Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Verify return code: 0 (ok) ``` تحققت هوية المقسم من الشهادة، واتفق الطرفان على بروتوكول TLSv1.2 وخوارزمية تشفير قوية. والآن نقارن ما يظهر على الشبكة في الحالتين بعد أن التقطنا مكالمة على 5060 وأخرى على 5061، ونعد الأسطر التي تحتوي على نص SIP مقروء في كل التقاط: ```bash docker exec are-pbxsec-pbx sh -c "tcpdump -r /tmp/plain.pcap -n -A 2>/dev/null | grep -ac 'sip:'" docker exec are-pbxsec-pbx sh -c "tcpdump -r /tmp/tls.pcap -n -A 2>/dev/null | grep -ac 'sip:'" ``` ```text 115 0 ``` على المنفذ العادي 5060 ظهر 115 سطراً فيه عناوين SIP مقروءة، أما على 5061 فلم يظهر أي سطر، لأن كل شيء مر مشفراً داخل TLS، ولا يرى الملتقط إلا بيانات التطبيق المعماة. وبهذا حمينا الإشارة، ولكن بقي الصوت نفسه. ## تشفير الصوت: SRTP TLS يحمي رسائل SIP، أما الصوت فيمر في تدفق RTP منفصل، ويحتاج تشفيراً خاصاً اسمه SRTP، أي RTP الآمن. وفي Asterisk نطلب تشفير الصوت بالخيار `media_encryption=sdes` في التحويلة، وهو يستخدم طريقة SDES لتبادل مفتاح التشفير داخل رسالة SDP: ```text [secure](!) type=endpoint context=internal disallow=all allow=ulaw,alaw rtp_symmetric=yes force_rport=yes rewrite_contact=yes media_encryption=sdes ``` وعندما تجري مكالمة بين تحويلتين على هذا القالب، يتغير وصف الوسائط في SDP: يصبح بروتوكول النقل `RTP/SAVP` بدل `RTP/AVP`، ويظهر سطر `a=crypto` يحمل المفتاح، كما نراه في الالتقاط: ```text m=audio 10044 RTP/SAVP 0 8 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0rizF6z2ziXCvYiMjKNOMq1+JFSz+WBJUJDeYn96 ``` الحرف S في `SAVP` يعني Secure، أي أن حزم الصوت أصبحت معماة، فلا يستطيع من يلتقطها أن يشغلها ويسمع المكالمة. وقارن هذا بالمكالمة العادية حيث يظهر `m=audio 20012 RTP/AVP 0 8 101` والصوت فيها G.711 صريح يمكن تسجيله وتشغيله. 🛑 لاحظ أن مفتاح التشفير في SDES يسافر داخل رسالة SDP نفسها في سطر `a=crypto`. فإذا مرت الإشارة نصاً صريحاً على 5060 كما في التقاطنا أعلاه، فإن من يلتقطها يحصل على المفتاح نفسه، ويفك به تشفير الصوت. ولهذا السبب لا معنى لـ SRTP وحده، وإنما يجب أن يمشي مع TLS: الإشارة المشفرة بـ TLS تخفي سطر `a=crypto`، فلا يصل المفتاح إلى الملتقط. والصورة التالية تلخص الطبقتين. ![مقارنة بين مكالمة على المنفذ 5060 حيث تمر رسائل SIP والصوت RTP نصاً صريحاً يقرؤه من يلتقط الحزم، ومكالمة على المنفذ 5061 حيث تمر الإشارة داخل نفق TLS والصوت في SRTP، فلا يرى الملتقط إلا بيانات معماة، مع ملاحظة أن مفتاح SRTP يسافر داخل الإشارة فيحميه TLS](https://arabroot.io/content/images/2026/10/pbx-security-03-encrypted-vs-plain.webp) TLS يخفي الإشارة والمفتاح معاً، وSRTP يعمي الصوت، والاثنان يعملان سوية ## قبل أن تنقل هذا إلى سيرفر حقيقي المختبر يبين المبدأ، وفي السيرفر الحقيقي هناك ما يضاف: - لا تعرض منفذ SIP لكل الإنترنت إذا كانت هواتفك في مكاتبك، واجعل الموظفين عن بعد يصلون عبر شبكة خاصة كما في [WireGuard](https://arabroot.io/articles/%D8%B4%D8%A8%D9%83%D8%A9-%D8%AE%D8%A7%D8%B5%D8%A9-%D9%85%D8%B9-wireguard-%D9%88-wg-easy/)، فيبقى SIP داخلها ولا يراه ماسح أصلاً. - استخدم إصداراً مدعوماً من Asterisk بحسب [جدول الإصدارات](https://docs.asterisk.org/About-the-Project/Asterisk-Versions/?ref=arabroot.io)، وراقب ترقياته الأمنية، فإصدار التوزيعة القديم ليس للإنتاج. - شهادة المختبر موقعة ذاتياً، أما في الإنتاج فاستخدم شهادة من سلطة موثوقة لمن يصل من خارج شبكتك، واجعل `method` على TLSv1.2 أو أحدث. - راقب سجل أحداث الأمان وفاتورة المكالمات معاً، فأول علامة على الاحتيال غالباً قفزة مفاجئة في عدد المكالمات الدولية في وقت لا يعمل فيه أحد، لا سطر في السجل. - اضبط جدار الحماية على السيرفر نفسه كما شرحنا في [تأمين خادم VPS من أول دخول](https://arabroot.io/articles/%D8%AA%D8%A3%D9%85%D9%8A%D9%86-%D8%AE%D8%A7%D8%AF%D9%85-vps-%D9%85%D9%86-%D8%A3%D9%88%D9%84-%D8%AF%D8%AE%D9%88%D9%84/)، فـ fail2ban داخل المقسم طبقة، لا سور وحيد. ## جدول التحصين السريع | الثغرة | ما يستغلها المهاجم | الإجراء | | --------------------------------------- | --------------------------------- | ------------------------------------------------------------- | | كلمة مرور ضعيفة أو مطابقة لرقم التحويلة | svcrack يكسرها في ثوان | كلمات مرور طويلة عشوائية من openssl rand | | المقسم يعلن نوعه وإصداره | svmap يحدد الثغرات المعروفة | user\_agent عام، وتحديث الإصدار | | قبول تسجيل من أي عنوان | فحص وتجربة كلمات مرور من الإنترنت | type=acl يسمح بشبكتك فقط، وشبكة خاصة للبعيد | | قبول مكالمات مجهولة Anonymous | اتصال دون مصادقة أصلاً | لا تحويلة anonymous، وendpoint\_identifier\_order=ip,username | | الاتصال الدولي مفتوح بلا حد | تفريغ الرصيد عبر أرقام مدفوعة | ارفض البادئة الدولية، وضع سقفاً للمكالمات المتزامنة | | محاولات متكررة لا يردعها شيء | الاستمرار في التجربة حتى النجاح | fail2ban بمرشح يطابق سجل PJSIP وbackend=polling | | الإشارة والصوت نصاً صريحاً | التقاط المكالمة وبيانات المصادقة | TLS على 5061 مع media\_encryption=sdes | ## إزالة المختبر نزيل ما أنشأناه بالاسم فقط، دون أوامر التنظيف العامة التي قد تحذف Containers أو Volumes تخص مشاريع أخرى على جهازك: ```bash docker rm -f are-pbxsec-pbx are-pbxsec-p1002 are-pbxsec-p2002 docker network rm are-pbxsec-net docker rmi are-pbxsec-tools:1 ``` ## تدريب عملي - غير كلمة مرور التحويلة 1001 إلى قيمة طويلة من `openssl rand -base64 18`، ثم أعد تشغيل `svcrack` عليها، وراقب سجل الأمان وهو يمتلئ بـ `ChallengeResponseFailed` دون أي `SuccessfulAuth`. - قلل `maxretry` في jail.local إلى 3 و`findtime` إلى 60، ثم شغل هجوماً خفيفاً، وقس بعد كم محاولة يقع الحظر، وفسر لماذا تغير العدد. ## الخلاصة - الاحتيال على المكالمات Toll Fraud يحول مقسمك إلى آلة تجني للمهاجم على حسابك، ويبدأ دائماً بفحص يبحث عن تحويلة ضعيفة. - أدوات sipvicious تكشف المقسم بـ svmap، وتكسر كلمة المرور الضعيفة بـ svcrack في ثوان، بينما تصمد كلمة المرور القوية تماماً. - وحدة PJSIP الحديثة لا تكشف أي تحويلة موجودة، فترد 401 على الجميع، وهذا تحسن أمني على الوحدة القديمة. - سجل أحداث الأمان يسجل كل محاولة بعنوان مصدرها، وfail2ban يحظر العنوان تلقائياً، بشرط مرشح يطابق صيغة PJSIP و`backend=polling`. - التحصين الحقيقي طبقات: كلمات مرور قوية، وACL يسمح بشبكتك فقط، ومنع المكالمات المجهولة، وتقييد الاتصال الدولي وحدوده. - TLS على 5061 يخفي الإشارة ومفتاح SRTP، وSRTP يعمي الصوت، والاثنان معاً يمنعان التقاط المكالمة على الشبكة. [![](https://arabroot.io/content/images/2026/10/voip-call-path-cover-cover.webp)دليلتتبع مكالمة SIP عبر الشبكة: لماذا يصل الصوت في اتجاه واحد؟نبني مقسماً وهاتفين خلف NAT في تجربة عملية، ونتتبع المكالمة حزمة بحزمة حتى نعرف لماذا يضيع الصوت وكيف نصلحه.](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A9-sip-%D8%B9%D8%A8%D8%B1-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-%D9%88%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D8%A7%D8%AA%D8%AC%D8%A7%D9%87-%D9%88%D8%A7%D8%AD%D8%AF/)[![](https://arabroot.io/content/images/2026/10/voip-terms-cover-cover.webp)دليلمصطلحات الاتصالات الهاتفية VoIP للمبتدئينشرح مبسط لمصطلحات الهاتف عبر الإنترنت، وما يمر في الشبكة بين ضغط زر الاتصال ووصول الصوت إلى الطرف الآخر.](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-voip-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/secure-vps-cover-cover-2.webp)دليلتأمين سيرفر VPS على Ubuntu من أول دخولقبل أن تثبت أي تطبيق على سيرفرك الجديد، هذه الخطوات تغلق أبرز الثغرات وأولها الدخول بمفتاح SSH بدل كلمة المرور.](https://arabroot.io/articles/%D8%AA%D8%A3%D9%85%D9%8A%D9%86-%D8%AE%D8%A7%D8%AF%D9%85-vps-%D9%85%D9%86-%D8%A3%D9%88%D9%84-%D8%AF%D8%AE%D9%88%D9%84/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، وبناء المختبر على Asterisk 20.6.0 وsipvicious 0.3.3 وfail2ban 1.0.2 وOpenSSL 3.0.13 من حزم Ubuntu 24.04 في شبكة Docker داخلية معزولة، مع هجوم SIP حقيقي وحظر تلقائي والتقاط TLS وSRTP.