حطيت قواعد على الجدار الناري (firewall) بس كلها صح؟ المنفذ 80، 443، 22 — شو لازم أقفل غير هذي؟

لا تفتح بورت ssh 22 يا رجل، غيّره لـ 2222 أو أي شي ثاني، بس ثبت fail2ban. بصراحة إذا ما عندك ميل لا تفتح smtp/imap خالص... خل بس 80، 443، 2222 مفتوحين، والباقي مقفل...

أوامر UFW: ufw default deny incoming، ufw allow 80/tcp، ufw allow 443/tcp، ufw limit 2222/tcp (لتحديد معدل اتصالات SSH)، ufw deny 3306/tcp (لإغلاق منفذ MySQL عن الخارج). للتحقق: ufw status numbered. لتفعيل السجلات: ufw logging on، level medium. إعدادات SSH (/etc/ssh/sshd_config): Port 2222، PermitRootLogin no، PubkeyAuthentication yes، PasswordAuthentication no (اعتماداً على المفاتيح). لإعادة التشغيل: systemctl restart sshd. للاتصال الداخلي: قواعد iptables أو مجموعات الأمان (على مستوى مزود السحابة).

أبسط إعداد: اقفل بورت 22 من الإنترنت، خلّه مفتوح بس من آي بي المكتب. أو غيّر البورت، حطه 2222. لا تفتح بورت MySQL 3306 أبداً، بس localhost... HTTP و HTTPS عادي، لا تفتح أي شي ثاني... طيب هذا كل شي، خلصت المهمة البسيطة.

طبقات الـ Firewall: المحيط (مستوى ISP)، الشبكة (جدار حماية الراوتر)، المضيف (جدار حماية على مستوى الجهاز). لسيرفر الويب: جدار حماية المضيف (UFW) + Cloud Security Group (إذا كان على السحابة). الوصول لـ SSH: Bastion host خلف VPN، أو على الـ IP whitelist. الوصول لقاعدة البيانات: الشبكة الداخلية فقط، أبداً من الخارج. السجلات لكل الحزم المرفوضة — التكامل مع SIEM مثالي. تحديد معدل SSH + حماية من TCP SYN flood.

بورت 22 مفتوح = أنت بتدعو الهاكرز 😂 غيّر البورت، ثبت fail2ban، وخلصت. بورتات الميل؟ إذا ما تحتاجها اقفلها، ليه تفتحها أصلاً...

أنت محق. لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها.

إذا كانت هذه أول مرة، ابدأ صغيراً، والتوسع يأتي لاحقاً. بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

إذا دخلنا في التفاصيل: لا تتحسن أي عملية لا يتم توثيقها، لأنك لا تعرف ما الذي يجب إصلاحه.

بالتوفيق.

عانيت من نفس الشيء.

أتفق جزئياً، وأختلف جزئياً. عندما تحاول تغيير كل شيء دفعة واحدة، لا يستقر أي شيء.

تسير الأمور على ما يرام في الأشهر الثلاثة الأولى، وتظهر المشاكل في الشهر الرابع. إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

عشنا تقريباً نفس التجربة العام الماضي وأكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار لكن بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

أوافق. الأمان ليس مطلقاً؛ بل يعني جعل الهجوم غير مجدٍ من حيث الجهد.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

عانيت من نفس الشيء. على كل حال إذا كانت هذه أول مرة، ابدأ صغيراً، والتوسع يأتي لاحقاً.

لو كنت مكانك، لسلك هذا المسار.

سمعنا هذا كثيراً، لكنه لم يحدث معنا أبداً. لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها.

معظم الحوادث لا تبدأ من ثغرة أمنية، بل من كلمة مرور مسربة. لو كنت مكانك، لسلك هذا المسار.

أخذت ملاحظة، شكرًا لك.

مررت بهذا الطريق، دعني أشرح. طيب إذا كان التحقق بخطوتين مفعلًا، فإن كلمة المرور المسروقة وحدها لا تكفي.

إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا... بصراحة لو كنت مكانك، لسلك هذا المسار.

دعوني ألخص ما قيل حتى الآن. أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

نسخة احتياطية غير مختبرة ليست نسخة احتياطية. بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

سأجرب ذلك.

مررت بهذا الطريق، دعني أشرح. تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.

لا تتحسن أي عملية لا يتم توثيقها، لأنك لا تعرف ما الذي يجب إصلاحه. إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.