ليلة القهوة والـ Logs: قصة من الميدان
أذكرها وكأنها البارحة. كنا في مرحلة إطلاق محمومة لمنتج جديد، والسيرفرات “بتولّع” من كثرة الطلبات. في ليلة من الليالي، حوالي الساعة الثانية فجراً، بدأ فريق العمليات يلاحظ بطئاً غريباً في استجابة إحدى الواجهات البرمجية (APIs) الحساسة. ما في أخطاء واضحة، لا يوجد ضغط كبير على المعالج أو الذاكرة، كل شيء يبدو “طبيعي” ظاهرياً.
قضيت الساعات التالية مع فنجان قهوة بارد وعيوني مثبتة على شاشة سوداء تعرض سيلاً لا ينتهي من سجلات الدخول (Access Logs). ملايين الأسطر تتدافع أمامي. كنت كمن يبحث عن إبرة في كومة قش، أو كما نقول “بدور على جمل وسط قطيع غنم”. كنت أبحث عن نمط، عن شيء غريب، عن أي خيط يقودني للمشكلة. بعد جهد جهيد، وبعد استخدام خليط من أوامر `grep` و `awk` و `sort` المعقدة، لمحنا النمط: عدد قليل من عناوين الـ IP كانت تقوم بعدد هائل من الطلبات ولكن بوتيرة بطيئة جداً وموزعة على نقاط نهاية (endpoints) مختلفة، وهو ما يعرف بهجوم “Low and Slow”. هذا النوع من الهجمات لا يفعّل أي من أنظمة الإنذار التقليدية المبنية على “إذا تجاوز العدد X، أطلق إنذاراً”.
في تلك الليلة، أدركت أن طريقتنا في التعامل مع السجلات خاطئة تماماً. لا يمكن للإنسان أن يراقب هذا الكم من البيانات. نحن لا نحتاج إلى المزيد من العيون، بل نحتاج إلى عقل إلكتروني لا يملّ ولا يكلّ، يستطيع أن يرى ما لا نراه. من هنا بدأت رحلتي العملية مع استخدام خوارزميات كشف الشذوذ (Anomaly Detection) في تحليل السجلات.
لماذا تغرق في بحر السجلات (Logs)؟ المشكلة الحقيقية
يا جماعة، أي نظام حديث اليوم ينتج كميات هائلة من السجلات: سجلات الواجهات البرمجية (API Logs)، سجلات أمنية (Security Logs)، سجلات التطبيقات، سجلات قواعد البيانات… ملايين بل مليارات الأسطر يومياً. هذه السجلات هي كنز حقيقي، لكنها مدفونة تحت جبل من البيانات “الطبيعية”.
المشكلة أننا نبحث عن أشياء نادرة جداً بطبيعتها:
- محاولات اختراق: مثل هجمات حجب الخدمة (DDoS)، حقن SQL، أو تلك الهجمات الخفية مثل التي واجهتها.
- أخطاء نادرة وفجائية (Spikes in errors): ارتفاع مفاجئ في أخطاء 5xx قد يدل على مشكلة في جزء من البنية التحتية.
- سلوك مستخدم غير طبيعي: مستخدم يقوم بسحب كمية بيانات ضخمة في وقت قصير جداً.
الأساليب التقليدية تفشل هنا فشلاً ذريعاً. لا يمكنك فحص كل شيء يدوياً، والقواعد البسيطة مثل `if request_count > 1000` لا تستطيع التقاط الأنماط المعقدة متعددة الأبعاد. المهاجم الذكي لن يرسل 1000 طلب في ثانية، بل قد يرسل 10 طلبات كل دقيقة من 100 IP مختلف. كيف ستكتب قاعدة `if` لهذه الحالة؟
من النص إلى الأرقام: كيف يرى الذكاء الاصطناعي الشذوذ؟
الحل الحقيقي يكمن في تحويل هذه المشكلة من “قراءة نصوص” إلى “تحليل أرقام”. هذا هو جوهر تعلم الآلة. نحن نستخدم تقنيات “التعلم غير المراقب” (Unsupervised Learning) لأننا في معظم الأحيان لا نملك بيانات مصنفة مسبقاً تقول “هذا هجوم” و “هذا طبيعي”. النظام يجب أن يتعلم مفهوم “الطبيعي” بنفسه، وأي شيء يخرج عن هذا المفهوم يعتبر “شاذاً” (Anomaly).
الخطوة الأولى هي “هندسة الميزات” (Feature Engineering)، حيث نحوّل كل سطر لوغ أو مجموعة من السجلات إلى متجه رقمي. ثم نستخدم خوارزميات متخصصة لتحديد النقاط الشاذة في هذا الفضاء الرقمي. أشهر خوارزميتين لهذا الغرض هما:
غابة العزل (Isolation Forest): أسرع طريقة لعزل الغرباء
تخيل أنك في غرفة مليئة بالناس (بيانات طبيعية)، وهناك شخص واحد يقف وحيداً في زاوية الغرفة (بيانات شاذة). إذا أردت أن تبني جداراً لعزل شخص عشوائي، فمن الأسهل والأسرع أن تعزل الشخص الوحيد في الزاوية أم شخصاً في منتصف الحشد؟ بالتأكيد الشخص الوحيد.
هذا هو المبدأ البسيط والعبقري لـ Isolation Forest. الخوارزمية تبني “أشجار قرار” عشوائية. النقاط الشاذة، لأنها “بعيدة” و “مختلفة”، يتم عزلها في عدد قليل جداً من التقسيمات (splits) في الشجرة. أما النقاط الطبيعية، فتحتاج إلى تقسيمات كثيرة لعزلها. بناءً على متوسط عدد التقسيمات اللازمة لعزل نقطة ما عبر غابة من الأشجار، تعطي الخوارزمية “درجة شذوذ” (Anomaly Score) لكل نقطة.
عامل الشذوذ المحلي (Local Outlier Factor – LOF): هل جارك غريب الأطوار؟
هذه الخوارزمية لها فلسفة مختلفة. هي لا تنظر للنقطة بشكل معزول، بل تقارنها بجيرانها. المبدأ هو: “قل لي من هم جيرانك، أقل لك من أنت”.
تقيس LOF كثافة البيانات حول نقطة معينة وتقارنها بكثافة البيانات حول جيرانها. إذا كانت نقطة ما في منطقة ذات كثافة أقل بكثير من جيرانها (أي أنها “وحيدة” أكثر من جيرانها)، فإنها تحصل على درجة شذوذ عالية. هذا يجعلها ممتازة في اكتشاف الشواذ في سياقات مختلفة. مثلاً، طلب واحد في الثانية قد يكون طبيعياً في وقت الذروة، ولكنه شاذ جداً في الساعة الثالثة فجراً. LOF تستطيع التقاط هذه الفروقات السياقية.
مثال عملي: حماية واجهة برمجية (API) من الطلبات المشبوهة
دعنا نطبق هالحكي بشكل عملي. السيناريو هو نفس مشكلتي القديمة: نريد اكتشاف عناوين IP التي تبدأ فجأة في إرسال طلبات غير طبيعية إلى الـ API الخاص بنا.
الخطوة 1: تجميع البيانات وهندسة الميزات (Feature Engineering)
أولاً، سنقوم بتجميع السجلات في نوافذ زمنية، مثلاً كل 5 دقائق. لكل عنوان IP فريد يظهر في هذه النافذة، سنقوم بحساب الميزات التالية:
request_count: إجمالي عدد الطلبات من هذا الـ IP.error_4xx_count: عدد الطلبات التي نتج عنها خطأ من عائلة 4xx (مثل 404 Not Found, 403 Forbidden).error_5xx_count: عدد الطلبات التي نتج عنها خطأ من عائلة 5xx (مثل 500 Internal Server Error).unique_endpoints_count: عدد نقاط النهاية (Endpoints) المختلفة التي طلبها هذا الـ IP.
بعد هذه العملية، سيكون لدينا مجموعة بيانات (Dataset) تشبه الجدول التالي:
| timestamp | ip_address | request_count | error_4xx_count | error_5xx_count | unique_endpoints_count |
|---------------------|-----------------|---------------|-----------------|-----------------|------------------------|
| 2023-10-27 10:05:00 | 1.2.3.4 | 50 | 2 | 0 | 3 |
| 2023-10-27 10:05:00 | 5.6.7.8 | 10 | 0 | 0 | 1 |
| 2023-10-27 10:05:00 | 9.10.11.12 | 250 | 240 | 10 | 25 |
...
السطر الثالث هنا يبدو مريباً جداً، أليس كذلك؟ هذا ما ستلتقطه الخوارزمية.
الخطوة 2: بناء النموذج وتدريبه (Model Building and Training)
سنستخدم مكتبة `scikit-learn` في بايثون لبناء نموذج `IsolationForest`. سنقوم بتدريب النموذج على بيانات تم جمعها خلال فترة “طبيعية” (مثلاً، بيانات أسبوع عادي لا توجد به مشاكل معروفة).
import pandas as pd
from sklearn.ensemble import IsolationForest
# لنفترض أن لدينا ملف 'normal_traffic.csv' يحتوي على بيانات من أيام عادية
df = pd.read_csv('normal_traffic.csv')
# نختار الميزات التي سنستخدمها للتدريب
features = ['request_count', 'error_4xx_count', 'error_5xx_count', 'unique_endpoints_count']
X_train = df[features]
# بناء النموذج
# contamination: هي النسبة المئوية المتوقعة من البيانات الشاذة في بياناتك
# هذا الرقم مهم جداً ويحتاج لتجربة. لنبدأ بقيمة صغيرة مثل 1%
model = IsolationForest(n_estimators=100, contamination=0.01, random_state=42)
# تدريب النموذج على البيانات الطبيعية
model.fit(X_train)
# الآن النموذج جاهز للتنبؤ
نصيحة من أبو عمر: معامل `contamination` هو أهم معامل عليك ضبطه. هو يخبر النموذج بمدى “حساسيته”. قيمة عالية تعني إنذارات كثيرة (بعضها قد يكون كاذباً). قيمة منخفضة قد تفوّت بعض الحالات. ابدأ بقيمة صغيرة جداً (مثلاً 0.005) وراقب عدد الإنذارات التي تحصل عليها، ثم قم بزيادتها تدريجياً حتى تصل إلى توازن مقبول بين اكتشاف الحالات الحقيقية وتقليل الإنذارات الكاذبة.
الخطوة 3: التشغيل الفوري وإطلاق الإنذارات (Real-time Deployment)
الآن، كل 5 دقائق، سنقوم بجمع البيانات الجديدة، تحويلها إلى ميزات، ثم استخدام النموذج المدرب للتنبؤ.
# لنفترض أن 'live_traffic_df' هي البيانات الجديدة لآخر 5 دقائق
X_live = live_traffic_df[features]
# التنبؤ باستخدام النموذج المدرب
# النتيجة ستكون 1 للبيانات الطبيعية و -1 للبيانات الشاذة
predictions = model.predict(X_live)
anomaly_scores = model.decision_function(X_live) # يعطي درجة الشذوذ
# إضافة النتائج إلى الداتا فريم
live_traffic_df['is_anomaly'] = predictions
live_traffic_df['anomaly_score'] = anomaly_scores
# فلترة وعرض العناوين الشاذة فقط
anomalies = live_traffic_df[live_traffic_df['is_anomaly'] == -1]
print("العناوين المشبوهة المكتشفة:")
print(anomalies)
# هنا يمكنك كتابة كود لإرسال إنذار (مثلاً إلى Slack أو بريد إلكتروني)
# أو حتى حظر الـ IP مؤقتاً باستخدام firewall-cmd أو ما شابه
عندما يكتشف النظام IP مشبوهاً، يمكنه تلقائياً إرسال إنذار لفريق الأمن مع كافة التفاصيل (لماذا تم اعتباره شاذاً، عدد طلباته، الأخطاء…)، أو حتى اتخاذ إجراء فوري مثل الحظر المؤقت.
هل نجحنا؟ قياس الأثر الحقيقي للنظام
بعد بناء النظام، كيف نعرف أنه يعمل بشكل جيد؟ المقارنة بين “قبل” و “بعد” هي المفتاح.
- قبل: اكتشاف يدوي بطيء، يعتمد على الصدفة أو الشكوى، زمن اكتشاف بالسااعات أو الأيام، الكثير من الحوادث لا تكتشف أبداً.
- بعد: اكتشاف آلي استباقي، خلال دقائق، يعتمد على تحليل رياضي للبيانات.
الإيجابيات الحقيقية والإنذارات الكاذبة (True Positives vs. False Positives)
هذا هو التحدي الأكبر. هدفنا هو زيادة “الإيجابيات الحقيقية” (True Positives) أي اكتشاف الهجمات الفعلية، وتقليل “الإيجابيات الكاذبة” (False Positives) أي الإنذارات التي تصدر لسلوك طبيعي. هذا التوازن يتم التحكم به عبر ضبط عتبة التنبيه (Threshold) أو معامل `contamination` في النموذج.
زمن الكشف والاستجابة (Time to Detect & Respond)
هذا هو المكسب الأكبر. بدلاً من أن يكتشف فريقك الهجوم بعد ساعات من حدوث الضرر، يمكن للنظام أن يكتشفه خلال 5 دقائق فقط. هذا الفرق في زمن الكشف قد يعني الفرق بين مجرد إزعاج بسيط وكارثة أمنية.
التأثير على الأداء (Performance Impact)
بما أن نظامنا يعمل بشكل “قريب من الفوري” (Near Real-time) عبر تحليل السجلات كل بضع دقائق، فإن تأثيره على أداء الـ API نفسه هو صفر. هو يعمل بشكل منفصل ولا يعترض طريق الطلبات الحية. وهذا يجعله حلاً آمناً جداً للتطبيق.
الخلاصة: من مطاردة الأشباح إلى الصيد الاستباقي 👨💻
يا خوي، التحول من التحليل اليدوي للسجلات إلى استخدام أنظمة كشف الشذوذ الذكية ليس ترفاً، بل ضرورة حتمية في عالم اليوم. هو ينقلك من دور رجل الإطفاء الذي يركض خلف الحرائق، إلى دور الحارس الذي يمنعها قبل أن تبدأ.
خوارزميات مثل Isolation Forest و LOF هي أدوات قوية جداً، وسهلة التطبيق نسبياً بفضل مكتبات مثل `scikit-learn`. هي لا تتطلب بيانات مصنفة، وتستطيع كشف أنماط لم تكن لتخطر على بالك.
نصيحتي الأخيرة لك: لا تخف من البداية. لا تحاول بناء نظام يغطي كل شيء من اليوم الأول. ابدأ صغيراً. اختر أهم مصدر للسجلات لديك (مثلاً سجلات الـ API Gateway)، حدد 3-4 ميزات بسيطة، اجمع بيانات أسبوع، درب نموذج Isolation Forest، ودعه يعمل في وضع المراقبة فقط. راقب الإنذارات التي يطلقها. ستتفاجأ من قيمة الأفكار (Insights) التي ستحصل عليها. من هناك، يمكنك التوسع والتطوير تدريجياً. ابدأ صغير، وشوف الخير.
