هل هناك أي شيء يمكنني القيام به لمنع شخص من معرفة أن موقعي يستخدم Drupal بالنظر إلى شفرة المصدر للصفحة الأمامية؟ أقصد الأشخاص الذين يقومون بفحص المواقع باستخدام البرامج التي تكتشف البرنامج تستخدم لتشغيل الموقع لتكون قادرة على مهاجمته باستخدام أي نقطة ضعف معروفة.
إذا لم يكن من الممكن إخفاء حقيقة أن الموقع يستخدم Drupal ، فهل من الممكن الخلط بينها (على سبيل المثال ، من خلال اسم مستعار لصفحات العقدة بعناوين URL مثل http://example.com/servlets/<node-id>.jsp
)؟
هذا سؤال قديم تمت الإجابة عليه بالفعل ، لكنني بذلت مؤخرًا بعض الجهد في كتابة وصف الكل الأشياء التي قد تحتاج إلى تغييرها:
في الأساس: قد يكون من الممكن من الناحية الفنية إخفاء حقيقة أن موقعك يشغل Drupal ، ولكنك ستقضي الكثير من الوقت عليه بحيث لا يستحق ذلك. يجب عليك بدلاً من ذلك التركيز على جعلها آمنة وعلى عمليات آمنة (مثل القدرة على نشر التحديثات بسرعة ومراقبة السجلات وما إلى ذلك).
لا يمكنك إخفاؤها بالكامل. معظم ما هو مطلوب للقيام بذلك ، سيتطلب نواة القرصنة. أكبر إخبار ، هو متغير جافا سكريبت Drupal
الذي يمكن قراءته من الصفحة الأولى ، أو أي صفحة لهذه المسألة.
إذا كنت ترغب في تحسين أمان مواقعك من خلال إخفاء أنه Drupal ، فإن جهدك ينفق بشكل أفضل على مراجعات الشفرة بدلاً من محاولة إخفاء حقيقة أن الموقع مصنوع باستخدام Drupal.
من السهل جدا القيام بذلك ، كيام!
وأخيرًا وليس آخرًا ، تأكد من أن موقعك بسيط جدًا ولا يتطلب JS أو CSS للسلوكيات العادية (لا تستخدم طرق العرض أو Ctools ...) ، ولا يدعم مصادقة المستخدم ، وما إلى ذلك ، وهذا يعني أن موقعك يجب أن أن تكون بسيطة مثل موقع html ثابت.
حسنًا ، كل ذلك لجعل الناس يعتقدون أن موقعك لا يعمل Drupal. على أي حال ، الأمن بالغموض لا طائل منه.
هناك مقال رسمي ومناقشة بخصوص نفس .
لا يمكنك. لا تحاول
- الهجمات الآلية (حتى الآن الهجمات الأكثر شيوعًا) لا تفحص الخادم قبل تجربة مآثرها .
سيؤدي فحص سجلات أي موقع رفيع المستوى إلى إظهار آلاف الطلبات غير المثمرة لـ/AspBB/db/betaboard.mdb
_private/cmd.asp
/scripts/../../winnt/system32/cmd.exe
/wp-login/
/administrator/components/com_wmtgallery/admin.wmtgal
،/cgi-bin/ip.cgi
... وأي عدد من محاولات الاستغلال التاريخي على أي نظام غير ذي صلة.
تحدث الهجمات على برمجيات إكسبلويت حتى لو لم تكن برمجيات إكسبلويت موجودة في نظام التشغيل أو نظام إدارة المحتوى. مهما فعلت لتحديد هوية موقعك بشكل خاطئ يتم تجاهلها على أي حال من قبل المتسللين الهواة.- أيا كان ما تعتقد أنه يمكنك إخفاءه ، هناك أدلة أخرى لأي نظام.
ببساطة إزالة بعض السلاسل التي تحتوي على "دروبال" لا يخفي موقعك لأي متلصص معقول. هناك العشرات من الطرق التي يمكن استخدامها لتخمين ما يخدم صفحاتك ، حتى الخدمات المخصصة لإخباره هل هذا الموقع يشغل دروبال. فقط الكلمات الرئيسية التي التي تعرفها وتعتقد أنها تهديد هي مجموعة فرعية صغيرة من المؤشرات الحقيقية.
اسأل عن index.php /؟ q = المستخدم. ثم حاول تعطيل هذه الاستجابة دون شل موقعك.- الأمن بالغموض ليس بالأمن. إنه يعطي انطباعًا زائفًا بأنك "آمن" عندما تخفي فقط نقاط ضعف وراء ستار دخاني يمكن لأي مهاجم يشكل أي تهديد حقيقي أن يتمكن من رؤيته.
- على الرغم من أنه ليس من المستحيل اختراق القرص إلى النقطة التي تكون فيها معظم آثار Drupal مخفية من مصدر HTML ، (إنها مفتوحة المصدر بعد كل شيء) الخطوات المطلوبة للقيام بذلك ستكسر بالضرورة النواة بشكل سيء للغاية سيكون الفرع المخترق الخاص بك من التعليمات البرمجية غير متوافق مع تحديثات الأمان الحقيقية أنك لم تستطع تصحيحها وستكون مفتوحة حقًا لأي تهديدات مستقبلية حقيقية حددها فريق الأمان. هذا هو الطريق الصحيح لضعف النظام.
- تحتوي معظم الوحدات المهمة أو المفيدة على رمز "التوقيع" الخاص بها الذي يصعب إخفاؤه دون إعادة كتابة كبيرة. إذا كنت تستخدم "طرق العرض" ، أو "cck" ، أو "ad" ، أو "imagecache" ، أو "jquery" ، أو css-aggregation ، أو السمات المساهمة أو أي شيء مفيد على موقعك - يمكن لشخص ما أن يقول . عادة ما يتطلب إخفاء ذلك تمامًا إجراء تحويل كامل لوظائف السمة - على الأقل. حتى ذلك الحين ، من المحتمل ألا يعمل التعليم الثانوي .
- لإزالة تحديد العديد من الميزات المتقدمة ، مثل التثبيت السهل لبرنامج Google Analytics الذي قد يستخدم Drupal للعمل ، يجب عليك إما التخلي عن هذه الميزات تمامًا أو إعادة كتابتها بطريقة لا يستفيد من Drupal. في بعض الأحيان يكون ذلك ممكنًا ، ولكنه في جميع الحالات يؤدي إلى نتائج عكسية.
قد تكون مهتمًا بقراءة تأمين موقعك أيضًا.
تذكر لا تخترق النواة
شيء إضافي قد تفعله هو استخدام وحدة File Aliases لتغيير هيكل الملف الافتراضي.
تسمح لك الأسماء المستعارة للملفات الوحدة باستخدام أسماء مستعارة قابلة للتخصيص لرموز الملفات التي تم تحميلها ، مما يمنحك القدرة على الحفاظ على نظام الملفات منظمًا كالمعتاد مع توفير مسارات نظيفة المظهر (على سبيل المثال ، لا مزيد من المواقع/الافتراضية// files /).
ليس هناك فائدة من الاختباء أن موقعك يدير دروبال. إنها طريقة خاطئة للنظر في تطوير مواقع الويب. ما يجب التركيز عليه هو الأمان. تأكد من تنفيذ جميع تدابير الأوراق المالية وسوف يكون كل شيء على ما يرام. لا يوجد سبب واحد في العالم لإخفاء أنك تستخدم نظامًا مُعيّنًا أو برنامجًا آخر. باستخدام إضافات FF مثل Wappalyzer ، يمكنك معرفة ما إذا كان أحد المواقع يستخدم Drupal في الحال ، لذا فإن السؤال بسيط للغاية.
أتفق مع الآخرين أنه لا يمكنك إخفاءه بالكامل. إذا نظرت إلى مصدر HTML ، فستلاحظ أنه لم يتم تجميع ملفات CSS و JavaScript عدة مرات. يجب تمكين تجميع CSS و JavaScript.
في ذلك الماضي ، قمت بتبديل الخطوط الخاصة بي لخطوط المشروع النموذجية Ruby مثل Lucida Sans ، مما يؤدي أيضًا إلى زيادة أحجام الإدخال مثل جميع الورك الذي يفعله الأطفال.
وهبة أخرى هي رسم "اللصوص" لحقول الإكمال التلقائي. كما أنه لا يعمل عند زيادة حجم الإدخال. إليك واحدة يمكنك سرقتها: http://beta.seattlebedandb breakfast.com/misc/throbber.gif