طرق حماية النظام (خادمات أسماء النطاقات

هناك عدة طرق ونقاط يمكن تطبيقها على خادمات أسماء النطاقات و خادمات المقررات لتفادي الأخطار التي يمكن أن تتعرض لها ومنها:
·حماية الاتصال الشبكي لخادمات أسماء النطاقات(Network Security):ويمكن تطبيق الحماية باستخدام جدار ناري أو موجة ووضع شروط وآلية معينة لفلترة رسائل الشبكة بحيث لا يتم فتح إلا المنافذ التي يحتاجها الخادم لتأدية عمله، فبالنسبة لنظام أسماء النطاقات يجب فتح المنفذ رقم 53 للبروتوكول (UDP) للسماح بتلقي الاستفسارات من أي جهة حول معلومة معينة، كما يجب فتح المنفذ رقم 53 للبروتوكول (TCP) و (UDP) للسماح فقط للخادمات الثانوية التي تحتاج نقل ملف النطاق كاملا إليها. كما يمكن استخدام جهاز التعرف على التطفل (Intrusion Detection) لتوفير الحماية اللازمة للخادمات والتعرف على الهجمات أو الاختراقات عند حدوثها.

·حماية نظام التشغيل (OS Security):كما يجب حماية نظام التشغيل وذلك بعمل التحديثات اللازمة بشكل دوري، والتأكد من صحة ودقة إعدادات نظام التشغيل وإزالة جميع الخدمات والبرامج الغير مستخدمة أو التي لا توجد حاجة لوجودها.

·تحديث برنامج الخادم باستمرار (Update DNS server):كما يجب تحديث البرنامج الذي يعمل كخادم لأسماء النطاقات بشكل مستمر ودوري، والذي يساعد على ذلك الاشتراك في القوائم البريدية الخاصة بالبرنامج نفسه و القوائم البريدية الأخرى المختصة في أمن الشبكات والمعلومات بشكل عام.

·التنوع في خادمات أسماء النطاقات (Diversity):من أهم التوصيات المقترحة عند إعداد خادمات أسماء النطاقات هو تجهيز خادمين (على الأقل) لتوفير خدمة استضافة أسماء النطاقات (أحدهما رئيسي والآخر ثانوي)، كما يوصى بأن تكون هذه الخادمات على شبكات منفصلة وذلك لتفادي مشاكل تعطل جميع الخادمات بسبب تعطل الشبكة. كما يفضل أن تكون هذه الخادمات تعمل على أنظمة تشغيل مختلفة ( مثلا: لينكسLinuxو سن سولارسSun Solaris)، ليس فقط ذلك بل ينصح أيضا باستخدام برامج مختلفة تعمل كخادمات أسماء النطاقات (مثلا: بايندBindو مارا دي ان اسMaraDNS) والسبب الرئيسي في هذا التنوع هو عدم توقف عمل جميع الخادمات أو سهولة اختراقها جميعا عند وجود ثغرة معينة في نظام التشغيل أو البرنامج الذي يقوم بدور خادم أسماء النطاقات عند اعتماد نوع معين على جميع الخادمات (ويمكننا القول بأن هذا التنوع قائم على مبدأ عدم وضع البيض في سلة واحدة).

·إخفاء الخادم الرئيسي لأسماء النطاقات (Hiding the Primary Name server):كما هو معلوم فانه يوجد على الأقل خادم رئيسي معلن لكل نطاق ولكن في الحقيقة يفضل وضع خادم آخر رئيسي مخفي (يمكن وضعة في شبكة داخلية آمنة) بحيث لا يعلم عنه أحد ولا يخاطبه إلا الخادم الرئيسي المعلن (الذي يأخذ منه ملفات النطاقات المستضافة) ثم يقوم بعد ذلك بتوزيعها على الخادمات الثانوية، والهدف من ذلك التأكد من الاحتفاظ بنسخة صحيحة من ملفات النطاقات المستضافة في مكان آمن بعيدا عن أيدي العابثين.

·تخصيص جهاز مستقل يعمل كخادم لأسماء النطاقات (Dedicated Machine for DNS servers):والهدف من ذلك تقليل الخدمات الموجودة على الجهاز والاكتفاء بخدمة أسماء النطاقات وسيؤدي ذلك إلى التقليل من احتمالية اختراق الجهاز عن طريق الخدمات الأخرى، والتركيز فقط على متابعة أمن نظام التشغيل و برنامج خادم أسماء النطاقات.

·عزل أنواع خادمات أسماء النطاقات عن بعضها البعض (Split--- # وصلة ممنوعة 1778 # -- Name Servers): كما يفضل وبشدة فصل خادمات أسماء النطاقات عن المقررات وذلك لتفادي مشاكل إفساد السجلات المؤقتة وأيضا يبسط ويسهل إعدادات الخادمات والتحكم فيها كما يزيد الأمن على هذه الخادمات. فمثلا خادمات أسماء النطاقات الرئيسية والثانوية يفضل عدم تفعيل خدمة التقرير عليها (Resolving) ويمكن ذلك بإضافة المتغير التالي في ملف إعدادات الخادم:

·مراجعة ملف إعدادات الخادم باستمرار وتتبع التوصيات المقترحة علية (review your configuration file): كما يوصى بمراجعة ملف إعدادات الخادم من وقت لآخر والتأكد أنه متوافق مع الخطة الأمنية للجهة (Security Plan) وتطبيق التوصيات المقترحة من الخبراء والمختصين لجعل الخادم أكثر أمانا وصلابة.

·استخدام خدمة امتدادات نظام أسماء النطاقات الأمن (Domain Name Service Security Extension-DNSSEC):وهي خدمة جديدة ومهمة تقوم بالتأكد من أمرين مهمين هما: صحة مصدر المعلومة ومن صحة المعلومة نفسها (لم يتم تغييرها أو العبث بها) وتستخدم بين الخادمات التي تخدم نفس اسم النطاق لتبادل الملفات بينها (الخادمات الرئيسية والثانوية) كما يمكن استخدامها في أمور أخرى. ويتم ذلك باستخدام سجلات خاصة من نوع (SIG,KEY) التي تستخدم التواقيع الرقمية (digital signatures) المشفرة بواسطة(MD5/RSA and DSA algorithms) والمفاتيح العامة والخاصة (Public and Private Keys). بحيث يقوم الخادم بالتوقيع (تشفير) على كل معلومة (سجل مصدر) مخزنة عليه باستخدام المفتاح الخاص وربطها بالمعلومة الرئيسية ومن ثم يقوم الخادم الآخر (الثانوي) باستخدام المفتاح العام للخادم للتأكد من صحة المعلومة. والعيب الرئيسي في هذه الطريقة هي كونها صعبة التمثيل والتطبيق وعليها بعض الملاحظات، وهي أفضل من الوضع الحالي وعادة ما تستخدم للخادمات وأسماء النطاقات الهامة والحساسة. وللمزيد من المعلومات حول هذا الموضوع يمكن زيارة الرابط التالي: (

http://www.dnssec.net).

·إخفاء نوع وإصدار الخادم(Hiding Server Version):وينصح أيضا بإخفاء رقم إصدار خادم أسماء النطاقات و المقررات وهذا الأمر يعطي صعوبة على المهاجم بتحديد نوع خادم أسماء النطاقات أو الإصدار الحالي له، حتى لا يستغل الثغرات الأمنية على الخادم في حال اكتشافها.

·حصر وتحديد الاستفسارات (Restricting Queries): ومن أهم الإعدادات التي يجب عملها هو حصر وتحديد مصدر الاستفسارات التي يقوم الخادم (المقرر) بخدمتها. وعادة ما تكون الأجهزة الداخلية على الشبكة هي التي يوم المقرر بخدمتها، ويمكن القيام بذلك باستخدام المرشحات (Access Lists) و المناظر (Views):

·منع خدمة نقل ملفات النطاقات للجهات الغير مصرحة (Preventing Unauthorized Zone Transfers): نظرا لأن ملف النطاق يحتوي على جميع أسماء وعناوين الأجهزة والخدمات المتوفرة لتلك الجهة فانه من المهم عدم السماح لأي شخص بالحصول على هذه المعلومات كاملة، لذلك يتم تحديد الخادمات التي تستطيع نقل ملف النطاق، ويمكن ذلك بتعريف هذه الخادمات على مستوى الخادم وجميع النطاقات المستضافة علية مثل:

·التحقق من طالب خدمة نقل الملفات (Authenticate Zone Transfers):وهذه الطريق مشابهة لامتدادات نظام أسماء النطاقات الآمن ولكنها أكثر بساطة (لا يتم تخزين التواقيع في ملف اسم النطاق)، إذ يتفق الخادمان على كلمة سر وطريقة تشفير معينه تمكنهم من تبادل ملفات النطاقات مع بعضهم البعض بعد التحقق من هوية كل واحد منهم وذلك بوضع توقيع على كل رسالة باستخدام كلمة السر وطريقة التشفير المتفق عليها:

·حصر وتقليل خدمة التحديث الآلي لملفات النطاق (Restrict Dynamic Updates):تفيد خدمة التحديث الآلي لملفات النطاق المستخدمين المتنقلين (Mobile users) فعند دخول المستخدم على الشبكة يعطى عنوان رقمي خاص به ومن ثم يتم تحديث نظام أسماء النطاقات وربط ذلك العنوان بالمستخدم بالتضافر مع بروتوكول تعريف الأجهزة آليا (Dynamic Host Configuration Protocol-DHCP)، ولكن يجب التعامل معها بحذر وحرص، كما يجب إعطاء إمكانية التعديل الآلي (على ملفات النطاق) إلى خادم (DHCP) فقط وباستخدام كلمة سر وطريقة تشفير معينة حتى يتم التوقيع على كل طلب تحديث يتم على ملف النطاق. وللمزيد من المعلومات يمكنكم زيارة الرابط التالي:
(http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html).

·تشغيل خادم أسماء النطاقات بأقل صلاحيات على نظام التشغيل (Running BIND with Least Privilege): يجب تشغيل برنامج خادم أسماء النطاقات عن طريق مستخدم معين له صلاحيات محدودة جدا في استخدام موارد النظام ،فلا يمكنه مثلا الوصول إلى الملفات الحساسة (مثل ملف كلمات المستخدمين السرية) أو حتى تشغيل أو استخدام برامج أخرى موجودة على الخادم، وتكمن الفائدة من ذلك عند اختراق برنامج خادم أسماء النطاقات فان المهاجم لا يستطيع الحصول على موارد النظام ولا تخريب أشياء أخرى وذلك لأننا قد قمنا بحصر الصلاحيات المستخدم الذي قام بتشغيل برنامج خادم أسماء النطاقات. وللمزيد من المعلومات يمكنكم زيارة الرابط التالي: (http://www.faqs.org/docs/Linux-HOWTO/Chroot-BIND-HOWTO.html) أو الرابط التالي (http://www.losurs.org/docs/howto/Chroot-BIND.html).

·وضع مدة قصوى للسجلات المؤقتة ومساحة محددة لها: و الفائدة الرئيسية من هذا الأمر هو تحديد المصادر المتاحة لبرنامج خادم أسماء النطاقات بدلا من استنفاذ جميع مصادر الجهاز، وأيضا عدم الاحتفاظ بالسجلات المؤقتة لفترات طويلة حتى وان أراد الخادم المسئول عن ذلك النطاق الاحتفاظ بالسجلات لمدة طويلة، لأنه قد يكون ذلك حصل بسبب خطأ أو لأن خادمهم قد تم اختراقه ومن ثم استرجاعه فيجب علينا عدم الاحتفاظ بالسجلات لوقت طويل

·عدم ربط أسماء الأجهزة بمالكها أو طبيعة استخدامها:وهذه قاعدة معروفة تقوم على إخفاء نوع الجهاز أو مكانه أو حتى اسم صاحب الجهاز حتى لا نسهل على المهاجمين استغلال هذه المعلومات لاختراق الأجهزة أو استغلال المعلومة في الهندسة الاجتماعية (Social Engineering). فمثلا إذا قمنا بتسمية جهاز قاعدة البيانات الخاص بالشركة باسم (mysql-ser.domain.com.sa) نكون بذلك بينا أن هذا الجهاز يعمل كقاعدة بيانات للشركة ونوعه (MySQL) فيمكن للمهاجم البحث عن الثغرات الخاصة بهذا البرنامج ومحاولة مهاجمة الجهاز من خلالها، وبهذا نكون قد سهلنا العملية له.

·التأكد من صحة ملفات أسماء النطاقات وتجنب الأخطاء الشائعة التي يمكن الوقوع فيها: بعد إعداد أو تحديث ملف اسم النطاق يجب التأكد من أن ذلك تم على الوجهة الصحيح، ويمكن استخدام بعض الأدوات الخاصة بنظام أسماء النطاقات (مثل:nslookupأوdigأوhost) و التي قد تساعد على اكتشاف الأخطاء من ثم تصحيحها تفاديا للوقوع في المشاكل التي قد تؤثر على عمل اسم النطاق أو أحد خدماته.
وهذه قائمة بالأخطاء الشائعة التي قد تحدث عند بناء أو تحديث ملف اسم النطاق:

1.نسيان وضع نقطة "." عند نهاية أي نص (يمثل اسم جهاز أو خدمة أو نطاق فرعي) داخل ملف اسم النطاق، لأن ذلك سيؤدي إلى إلصاق اسم النطاق في نهاية ذلك النص:

; The zone file for "example.com"
ns1IN A212.26.18.1
www.example.comIN A212.26.18.2
; The result of the previous 2 lines are equivalent to:
;ns1.example.com. IN A 212.26.18.1
;www.example.com.example.com. IN A 212.26.18.2
; as you can see ns1 is accepted but www is incorrect!
2.عدم استخدام أرقام عناوين الانترنت الداخلية (Private IP addresses) أو أرقام العنوان المحلي (loopback) في ملفات أسماء نطاقات المستخدمة على الانترنت، لأنه على الانترنت لا يمكن الوصول إلا إلى الأرقام العامة (Public IP addresses):

;The zone file for "example.com"
ns1.example.com. IN A127.0.0.1
www.example.com. IN A10.1.1.1.
ftp.example.com. IN A172.16.1.1.
mail.example.com.IN A192.168.1.1.
; all of the previous hosts will not be reached on the internet.
3.التقليل من استخدام سجلات المترادفات (CNAME) قدر المستطاع، لأنها قد تسبب بعض المشاكل خصوصا عند استخدام أسماء الأجهزة أو الخدمات المعرفة من خلالها في بناء سجلات أخرى داخل ملف اسم النطاق.

; The zone file for "example.com"
ns1.example.com.IN A212.26.18.1
ns2.example.com.IN CNAMEns1.example.com.
mail.example.com.IN CNAMEns1.example.com.
; These 2 lines will not work properly!
example.com. INMX 10mail.example.com.
example.com.IN NSns2.example.com.

; Both ns2 & mail should have their own "A" recode not "CNAME"

4.عدم استخدام السجلات الملصقة (Glue Records) إلا عند الحاجة لأن ذلك يؤدي إلى مشاكل في التزامن وصحة المعلومات عند تغير قيم السجلات في ملفاتها الأصلية، ويمكن استخدام السجلات الملصقة فقط عن توكيل (delegate) نطاقات فرعية من النطاق الرئيسي بحيث تكون أسماء الخادمات المسئولة عن النطاق الفرعي تقع داخل النطاق الرئيسي أو النطاق الفرعي فقط.

; The zone file for "example.com"
Sub.example.com.IN NSns1.example.com.
Sub.example.com.IN NSns2.hosting.com.
ns1.example.com.IN A212.26.18.1
ns2.hosting.com. INA212.26.18.2
ns3.sub.example.com. INA 212.26.18.3

; Both ns2.hosting.com& ns3.sub.example.com are glue records.
; But there is no need for ns2.hosting.com to be in this zone file!
; It should be in the zone file for hosting.com.

5.استخدام القيم الموصى بها عند تعريف أو تحديث سجل معومات ملف النطاق الـ "SOA" وكذلك زمن التحديث العام الخاص بسجلات ملف النطاق (TTL):

6.عند تحديث ملف اسم النطاق يجب زيادة رقم تعريف الملف (serial) الموجود في سجل الـ "SOA"، حتى يمكن للخادمات الثانوية معرفة أن ملف اسم النطاق تم تحديثه ويجب عليهم الحصول على النسخة المحدثة.
7.يجب أن لا تكون سجلات البريد الالكتروني ""MXوالخادمات الرئيسية للنطاق "NS" تؤشران على عناوين انترنت رقمية (IP Addresses)، بل تؤشران على أسماء أجهزة (لها عناوين انترنت رقمية مباشرة وليستCNAME).

; The zone file for "example.com"
example.com.IN NS212.26.18.1
example.com.IN MX10212.26.18.2
; These two lines can t work and dose not mean any thing!.

8.عند توكيل خادمات أخرى لنطاق فرعي يجب التأكد من أن هذه الخادمات مستضيفة للنطاق الفرعي على الوجه الصحيح وأن في ملف النطاق الفرعي يوجد سجل "NS" خاص لكل خادم لأن عدم توفر ذلك قد يؤدي إلى مشاكل عديدة (Lame Delegation).
9.وأيضا من أكثر المشاكل انتشارا هو عدم التزامن بين الخادمات الرئيسي والثانوية، بحيث يعطي كل خادم رد مختلف عن الخادمات الأخرى. ويجب التأكد دوما من إمكانية وصول الخادمات بعضها ببعض (عدم وجود عوائق على الشبكة مثل جدار ناري أو موجة يمنع التراسل بينها) حتى يتم تبادل الملفات بشكل صحيح.

·نسخ ملفات أسماء النطاقات وحفظها في مكان آمن:كما يفضل أن نقوم بنسخ جميع ملفات النطاقات ووضعها في مكان آمن وعلى جهاز مستقل ولا يمكن الوصول إليه من قبل الآخرين، وذلك تحسبا لوجود أي مشاكل قد تطرأ على الخادمات فيتم فقد الملفات من عليها. والأفضل بناء برامج تقوم بأتمتته هذه العملية بدلا من العمل اليدوي.

·متابعة ملفات تتبع حالة الخادم (Monitor the log file) وملف الإحصاءات (Statistics File):كما يجب إعداد ملفات تتبع حالة الخادم لمعرفة رسائل التحذير والخطأ التي قد تواجه الخادم أثناء تأدية عملة، كما يجب إعداد ملف الإحصاءات التي تعطي تقارير عديدة عن الخادم (مثل عدد الاستفسارات التي قام بخدمتها حسب نوعها).


·الاشتراك في القوائم البريدية الخاصة بالمخاطر التي تهدد النظام: ومن أهم هذه القوائم البريدية قائمة الإعلانات الخاصة ببرنامج بايند (Bind) ويمكن الاشتراك فيها من خلال الرابط التالي: (http://www.isc.org/index.pl?/sw/bind/bind-lists.php) ، كما يمكن الاشتراك أيضا بالقائمة البريدية الخاصة بنظام أسماء النطاقات بشكل عام من خلال إرسال رسالة اشتراك إلى العنوان البريدي التالي: (namedroppers-request@ops.ietf.orgهذا البريد الإلكتروني محمي من المتطفلين و برامج التطفل، تحتاج إلى تفعيل جافا سكريبت لتتمكن من مشاهدته).

·تسجيل اسم نطاق بشكل صحيح وآمن: سبق وأن بينا المخاطر التي قد تواجهه المستخدم الذي يقوم بتسجيل اسم النطاق وما يترتب عليها من أمور، ولتجنب هذه المخاطر يمكن للمستخدم إتباع النقاط التالية عند تسجيل اسم النطاق:

1.عدم الاعتماد على أشخاص غير موثوقين أو على شركات الاستضافة في تسجيل اسم النطاق.
2.تسجيل اسم النطاق لفترة طويلة (أكثر من سنة) إذا أمكن ذلك.
3.الاحتفاظ بمعلومات التسجيل في مكان آمن.
4.التأكد من صحة معلومات المنسق الإداري وأنه هو الشخص الصحيح.
5.تحديث معلومات التسجيل باستمرار وإتباع إجراءات تمديد التسجيل و التأكد من دفع المبالغ المطلوبة في الوقت المناسب.
6.استخدام كلمة مرور قوية (مكونة من حروف وأرقام ورموز خاصة وطولها على الأقل ثمانية خانات) لإدارة اسم النطاق أو للبريد الالكتروني المسئول عن النطاق.
7.كما يفضل تسجيل أسماء النطاقات المشابه لاسم النطاق وخصوصا إذا كان اللبس وارد عند مستخدمي الانترنت.
8.يجب وجود عقد بين مسجل النطاق ومستضيف النطاق يضمن تطبيق التوصيات الفنية اللازمة لتشغيل اسم النطاق و الخدمات القائمة عليه. كما يفضل التحقق من صحة الجهة المستضيفة ومصداقيتها في التعامل وإمكانية مقاضاتها قانونيا عند إخلالها بالاتفاق (لا سمح الله).

·التأكد من صحة أسماء النطاقات والخدمات المعتمدة عليها:كما يجب على المستخدمين التأكد جيدا من صحة أسماء النطاقات أو الأجهزة (المستخدمة في المواقع الشبكة أو عناوين البريد الالكتروني) حتى لا يقعوا فريسة سهلة للمهاجمين من خلال (DOMAIN FISHING).

·التأكد جيدا من صحة تعريف نظام أسماء النطاقات في إعدادات الشبكة على الأجهزة:كما يجب التأكد من صحة تعريف نظام أسماء النطاقات (داخل إعدادات الشبكة) على جميع الأجهزة وأنه لم يتم العبث بها ولا بملف الترجمة الداخلي (hosts) الموجود عليها.

تعديل المقال