تكرار السؤال: …
الإجابة المختصرة
تحدث هجمات MITM عند اعتراض وتعديل البيانات بين طرفين دون علمهما ويحميها التشفير والشهادات الموثوقة، وهجمات SYN Flood تغرق الخادم بطلبات اتصال وهمية لملء طابور الاتصالات واستنزاف موارده.
الشرح
في هجوم SYN Flood، يرسل المهاجم ملايين حزم SYN بعناوين IP وهمية (Spoofed IPs)، فيرد الخادم بـ SYN-ACK وينتظر رد ACK النهائي واضعاً الاتصال في طابور نصف المكتمل (SYN Queue / Backlog). تمتلئ ذاكرة الخادم ويتوقف عن استقبال أي مستخدم حقيقي. تعالج تقنية SYN Cookies ذلك بطريقة ذكية: لا يخصص الخادم أي ذاكرة على الإطلاق في البداية! بل يشفر بيانات الاتصال والوقت في الرقم التسلسلي المبدئي (Initial Sequence Number)، وعندما يرد العميل الشرعي بـ ACK، يتحقق الخادم من صحة التشفير حسابياً ويفتح الاتصال فوراً.
مثال بالكود
import hashlib, hmac, struct, time
SECRET = b"server-secret"
def syn_cookie(src_ip: str, src_port: int, dst_port: int, client_isn: int) -> int:
minute = int(time.time() // 60) & 0x1F
mac = hmac.new(SECRET, f"{src_ip}{src_port}{dst_port}{client_isn}{minute}".encode(), hashlib.sha256).digest()
return (struct.unpack(">I", mac[:4])[0] & ~0x1F) | minute # becomes the server's initial sequence number
# On SYN the server stores NOTHING, so a flood of fake SYNs cannot fill its connection table.
# On the final ACK it recomputes the cookie from (ACK number - 1); only a valid one allocates a connection.
# Linux: sysctl -w net.ipv4.tcp_syncookies=1أخطاء شائعة
- تعطيل فحص الشهادات الرقمية (SSL Verification) في بيئة التطوير ونسيان إعادة تفعيله في الإنتاج، مما يجعل التطبيق عرضة فورية لاختراق MITM.