gopassivedns

تسجيل DNS المعتمد على الشبكة بلغة Go

ملخص

مسجّل DNS يعتمد على التقاط الشبكة، مستوحى من https://github.com/gamelinux/passivedns. يستخدم gopacket للتعامل مع libpcap ومعالجة الحزم. يُخرج سجلات بصيغة JSON. صُمّم للتعامل مع التقاط الاستعلامات عالية الحجم في بيئات تحتوي على عدد يتراوح بين خادم تحليل واحد ومئات.

لماذا لا نستخدم PassiveDNS من gamelinux؟

إنه خيار جيد. بنيت هذه الأداة لأنني أعتقد أن المهام التي تتضمن معالجة كميات كبيرة من البيانات غير الموثوقة مع العديد من الحالات الطرفية غير الموثقة جيدًا يجب أن تُدار بواسطة بيئة تشغيل مدارة لمنع هجمات تلف الذاكرة. لقد قمت بنشر PassiveDNS في عدة مؤسسات، وقمت ببناء gopassivedns لحل بعض المشكلات المحددة التي لاحظتها: كنت بحاجة إلى تجهيز عدد كبير من المواقع، وكنت بحاجة إلى توسيع نطاق طبقة التخزين للتعامل مع عدد كبير جدًا من الاستعلامات، وأردت مجموعة اختبارات بتغطية جيدة لجميع الحالات الطرفية لـ DNS.

لماذا لا نستخدم Bro (أو أي نظام تسجيل DNS آخر للكشف عن التطفل)؟

هذا أيضًا خيار جيد. عادةً ما تُنشر أنظمة مثل Bro على مخارج الشبكة، مما يؤدي إلى إخفاء المصدر الحقيقي للاستعلام خلف خوادم التحليل التكراري. وهذا يعني أنك تحتاج عمومًا إلى نشر Bro مع تسجيل استعلامات الخادم التحليلي (إذا كنت تستطيع)، ثم دمج السجلات من كليهما في نظام تسجيل مركزي لتتبع الاستعلام إلى العميل. صُمّم gopassivedns ليُنشر على خوادم التحليل لديك دون تغيير إعدادات الخادم التحليلي و/أو على مخارج الشبكة، لتسجيل مركزي عبر بروتوكول موثوق وتحليل بسيط في أي نظام سجلات.

لماذا لا نستخدم تسجيل استعلامات الخادم التحليلي فقط؟

دعم خوادم التحليل لتسجيل الاستعلامات، بما في ذلك السؤال والإجابة، متفاوت في أحسن الأحوال. أحد أكثر خوادم DNS انتشارًا، BIND، لا يدعمه على الإطلاق. البعض الآخر، مثل Windows DNS، لديه تنسيقات سجلات سيئة للغاية. بالإضافة إلى ذلك، فإن التسجيل المعتمد على الشبكة سيلتقط الاستعلامات المرسلة مباشرة إلى الخوادم البعيدة (مثل Google DNS) من عملائك.

الاستخدام

يمكن تحديد خيارات التكوين كمتغيرات بيئية، أو في ملف .env، أو عبر سطر الأوامر. الأولوية هي معلمات سطر الأوامر، ثم ملف .env، ثم المتغيرات المحددة بالفعل في البيئة. خيارات التكوين كالتالي:

• -dev [جهاز] جهاز الشبكة للالتقاط (ENV: PDNS_DEV)
• -fluentd_socket [مأخذ] مسار مقبس Fluentd يونكس المستخدم للتسجيل بتنسيق messagepack (ENV: PDNS_FLUENTD_SOCKET)
• -bpf [مرشح bpf] مرشح BPF للالتقاط (الافتراضي: port 53) (ENV: PDNS_BPF)
• -pcap [ملف] ملف pcap للمعالجة (ENV: PDNS_PCAP_FILE)
• -logfile [ملف] ملف سجل لاستعلامات DNS (مقترح للنشر الصغير أو التصحيح فقط) (ENV: PDNS_LOG_FILE)
• -logMaxAge أقصى عمر لملف السجل قبل التدوير، بالأيام (الافتراضي: 28) (ENV: PDNS_LOG_AGE)
• -logMaxBackups أقصى عدد من الملفات المحتفظ بها بعد التدوير (الافتراضي: 3) (ENV: PDNS_LOG_BACKUP)
• -logMaxSize أقصى حجم لملف السجل قبل التدوير، بالميغابايت (الافتراضي: 100) (ENV: PDNS_LOG_SIZE)
• -quiet لا تسجل استعلامات DNS إلى STDOUT (ENV: PDNS_QUIET)
• -debug تفعيل تسجيل التصحيح إلى STDOUT (ENV: PDNS_DEBUG)
• -gc_age [رقم] العمر الذي يجب عنده جمع الاتصالات غير المكتملة (الافتراضي: -1m) (ENV: PDNS_GC_AGE)
• -gc_interval [رقم] الفاصل الزمني لتشغيل جمع القمامة على جدول الاتصالات (الافتراضي: 3m) (ENV: PDNS_GC_INTERVAL)
• -kafka_brokers [وسطاء] قائمة مفصولة بفواصل لوسطاء كافكا (ENV: PDNS_KAFKA_PEERS)
• -kafka_topic [موضوع] موضوع كافكا للتسجيل (ENV: PDNS_KAFKA_TOPIC)
• -cpuprofile [ملف] تفعيل تتبع استخدام المعالج (ENV: PDNS_PROFILE_FILE)
• -numprocs [رقم] عدد goroutines المستخدمة لتحليل بيانات الحزمة (الافتراضي: 8) (ENV: PDNS_THREADS)
• -pfring استخدام PF_RING للتقاط الحزمة (ENV: PDNS_PFRING)
• -statsd_host المضيف والمنفذ لخادم statsd (مثال: localhost:8125) (ENV: PDNS_STATSD_HOST)
• -statsd_interval الفاصل الزمني، بالثواني، بين الإرسال إلى statsd (ENV: PDNS_STATSD_INTERVAL)
• -statsd_prefix بادئة اسم المقياس المستخدمة (الافتراضي: gopassivedns) (ENV: PDNS_STATSD_PREFIX)
• -snaplen [int] طول snaplen المستخدم في مخزن pcap (ENV: PDNS_SNAPLEN)
• -name اسم هذا المستشعر للاستخدام في الإحصائيات ورسائل السجل (الافتراضي: اسم المضيف) (ENV: PDNS_NAME)
• -syslog_facility مرفق syslog (ENV: PDNS_SYSLOG_FACILITY)
• -syslog_priority أولوية syslog (ENV: PDNS_SYSLOG_PRIORITY)

يجب عليك تقديم إما -dev أو -pcap.

توجد مشكلات معروفة مع goroutines وعملية التحويل إلى خدمة خلفية القياسية (https://github.com/golang/go/issues/227)، لذا أوصي بشدة باستخدام إحدى الطرق الموضحة هنا: http://stackoverflow.com/questions/10067295/how-to-start-a-go-program-as-a-daemon-in-ubuntu لتشغيل هذه العملية كخدمة خلفية باستخدام أدوات النظام.

إذا اخترت استخدام تسجيل syslog، فإننا نستخدم "log/syslog" من Go والذي يتطلب وجود مقبس يونكس للتواصل مع syslog في أحد المسارات /dev/log أو /var/run/log أو /var/run/syslog.

دليل النشر

أين أنشر هذه الأداة؟

لديك 3 خيارات: انشرها على خادم (خوادم) التحليل لديك، أو على بوابة (بوابات) الشبكة لديك، أو كليهما. النشر على خوادم التحليل مفيد لأنك ستحصل على عنوان IP الخاص بالعميل الذي أرسل الطلب الأصلي. يمكنك أيضًا رؤية الساق الصاعدة للطلب (من الخادم التحليلي إلى الخادم التالي في السلسلة)، ما لم تضبط مرشح BPF الخاص بك لتجاهل تلك الساق. النشر على البوابات يعني أنك لا ترى الساق من العميل إلى الخادم التحليلي الداخلي، لذا قد يكون من الصعب ربط الطلب بعميل معين. من ناحية أخرى، سترى الطلبات التي تتجاوز خوادم التحليل الداخلية. سترى أيضًا بالطبع الاستعلامات القادمة من الخادم التحليلي إلى أي خادم تحليل علوي يستخدمه. في عالم مثالي، سأنشر هذه الأداة على كل خادم تحليل داخلي لدي وعلى نقطة تجسس على بواباتي. سيكون لخوادم التحليل الداخلية مرشح BPF يتجاهل الساق الصاعدة للاستعلام، ولن تتجاهل البوابة أي شيء.

ماذا أفعل بالنتائج؟

حاليًا، أوصي باستخدام logstash لنقل السجلات إلى مجموعة elasticsearch. جميع السجلات بصيغة JSON، لذا سيكون هذا سهلاً جدًا. أقترح أيضًا استخدام شيء مثل HDFS للتخزين طويل المدى والتحليل الجماعي. استعلامات DNS هي مصدر مذهل للبيانات الداخلية!

البناء والتثبيت

• استنساخ هذا المستودع
• تثبيت libpcap و libpcap-dev
• تشغيل 'go get'
• تشغيل 'go build -o gopassivedns' (الخيار -o هو مجرد احتياط، بافتراض أنك استنسخت المستودع فلن تحتاجه)
• تشغيل 'cp gopassivedns /some/path/to/gopassivedns'