11/08/2025
كيف الـ Redis صار طابور خامس بمشروعي، خليني احكيلكم التفاصيل:
مرة كنت شغال على مشروع Laravel ضمن Docker، وعندي Redis container لحتى يدير الكاش والـ queues.
وأنا مفكّر كل شي تمام، فجأة بلاحظ الـ Horizon صار ينهار وعم يطلعلي error:
READONLY You can't write against a read only replica
استغربت، فتحت redis-cli وشفت انه الـ Redis تبعي انقلب replica لسيرفر غريب!
هون صار الموقف فيه كتير أسئلة مين هاد الـ IP الغريب؟ وليش Redis تبعي صار replica لشي سيرفر مجهول؟
الشي المخيف؟ هالشي صار أوتوماتيكياً وبدون أي أثر مباشر، وكأنك فجأة لقيت حدا غريب ماسك مفاتيح بيتك!
و لتفهم مدى جدية الموقف نحنا هون صار عنا data poisoning: ممكن يحقنوا قيم وهمية بالكاش، يبدّلوا sessions، أو يمرّروا إعدادات تخرب الـ Logic للمشروع كله. والأسوأ؟
في سيناريوهات معيّنة بيقدر المهاجم يستغل Redis ليتمدّد عالـ host أو يزرع backdoor عبر ملفات النظام إذا لقاها متاحة. يعني الموضوع مو بس downtime الموضوع سلامة البيانات، موثوقية الـ auth، وحتى integrity تبع التطبيق نفسه على المحك.
هون فهمت الغلطة: أنا فاتح الـ port على الإنترنت بدون أي authentication، و Redis بشكل default ما فيه أي حماية إذا تركته مفتوح. أي bot أو script على الإنترنت بيقدر يبعت أمر REPLICAOF ويحوّل الـ instance تبعي لنسخة read-only من سيرفره. هالشي بيتكرر أوتوماتيك لأنه في bots بتعمل scan على كل IPs المكشوفة.
فورا رجعت الـ Redis لـ master و سكّرت الـ Port الخارجي
اتعلم من خطئي و انتبه:
أي service مثل Redis, MySQL, MongoDB إذا ما كان لازم تكون مكشوفة للإنترنت، خليها internal فقط.
دائماً فعّل authentication حتى جوّا الشبكة.
لا تعتمد على الـ defaults، لأن كتير خدمات default settings تبعها مفتوحة.
