22 : syn_attacks عند بدأ أي جلسة إتصال بإستخدام TCP/IP فإن العملية تسمى ب TCP/IP handshaking وهي تتم كالتالي : 1. يرسل الجهاز client رسالة إتصال syn للجهاز البعيد . 2. يرد الجهاز البعيد ب syn_ack على ال client إن كان المنفذ المراد الإتصال به مفتوح .وإلا يرد ب RST . 3. تبدأ الجلسة الفعلية لبدأ نقل البيانات بأن يرسل بعد ذلك client رسالة ack للجهاز البعيد . الآن لإستغلال عملية الإتصال الطبيعية هذه في شن هجوم على جهاز بعيد يجب أن نعرف أنه عند بدأ إتصال جديد مع السيرفر فإن السيرفر يقوم بإضافة مدخل syn بإسم ip الجهاز client الذي أرسل إشارة syn ليستطيع متابعة تسلسل عملية الإتصال . عندما تتم الإضافة يتم تخصيص جزء من موارد السيرفر لإستقبال وإتمام هذه العملية . يتم تخصيص جزء من الذاكرة يسمى ب backlog مخصص فقط لتضاف إليه طلبات syn الجديدة وستظهر على شكل SYN_RECV من netstat CONSOLE # netstat -n | grep SYN_RECV tcp 0 0 10.100.0.200:21 237.177.154.8:25882 SYN_RECV - tcp 0 0 10.100.0.200:21 236.15.133.204:2577 SYN_RECV - tcp 0 0 10.100.0.200:21 127.160.6.129:51748 SYN_RECV - tcp 0 0 10.100.0.200:21 230.220.13.25:47393 SYN_RECV - tcp 0 0 10.100.0.200:21 227.200.204.182:60427 SYN_RECV - tcp 0 0 10.100.0.200:21 232.115.18.38:278 SYN_RECV - tcp 0 0 10.100.0.200:21 229.116.95.96:5122 SYN_RECV - tcp 0 0 10.100.0.200:21 236.219.139.207:49162 SYN_RECV - tcp 0 0 10.100.0.200:21 238.100.72.228:37899 SYN_RECV - لو قمنا بإرسال طلبات SYN كثيرة للسيرفر فإنها كافية لعمل flood لملأ ال backlog مما يشكل هجوم DOS بحيث لايستطيع السيرفر إستقبال أي إتصال حقيقي جديد . حيث أن عمليات syn attack في الحقيقة ليست three way handshaking والتي تسمى أيضا ب full-open tcp/ip connection , وإنما هجوم syn يعتمد على أن لانكمل الإتصال الحقيقي الكامل وأن لانرد على syn_ack المرسلة من السيرفر أساسا . إن لم يصل للسيرفر رد على syn_ack التي قام بإرسالها لل client برد ack صحيح يتم حذف مدخل syn من السيرفر بعد مرور 3 دقائق " في سيرفرات linux - بشكل إفتراضي" حيث سيحاول فيها أن يعاود إرسال syn_ack خمس مرات لل client عسى أن يجد رد ack لإكمال الإتصال . الآن syn_flood سهل التحقيق ونحتاج أن نعرف شيء واحد إضافي , ماحجم ال backlog ؟ القيمة الإفراضية ل backlog في linux هي 1024 مما يعني تخزين 1024 جلسة إتصال غير مكتملة وبعدها سيبدأ السيرفر بعمل DORP لكل syn إضافي قادم ! بالتالي لتشكيل هجوم syn flood يجب أن نقوم بعمل ip spoofing وإرسال كمية syn packets كبيرة لتشكيل الإتصال الأولي , و syn packet يتم إنشاءها بالطبع بشكل إفتراضي من جميع البرامج التي تعمل على بروتكول tcp/ip بدأ من المتصفحات وكل البرامج التي تعتمد على الإنترنت وغيرها الكثير . syn packet يتم إنشاءها بعمل set ل syn flag في TCP Header وتوجد 8 flags كما هو واضح في الصورة : Resized to 63% (was 1039 x 446) - Click image to enlarge توجد عدة أدوات في open source تنفذ أمور كثيرة جدا وإحدى الأدوات التي من خلالها تستطيع إنشاء packet بالشكل الذي تريده وبكل التفاصيل في كل six layers هي الأداة hping مثلا : CONSOLE hping -S 10.10.10.1 --fast -p DEST_PORT هنا -S تعني إعمل على syn flag و --fast أرسل 10 packets في الثانية , -p المنفذ البعيد لعمل إتصال معه , ووجب أن أذكر أن hping لايقوم بالإتصال بشكل رئيسي ك ICMP وإنما بال TCP/IP بشكل إفتراضي مالم نحدد ذلك . للوقاية من هذا النوع من الهجمات يوجد طريقين : الأول : زيادة حجم backlog و تقليل الزمن اللازم لحذف مدخل syn من ال backlog . لزيادة حجم backlog وعدد syn connections اليتيمة في لنكس يتم الأمر عن طريق sysctl كالتالي : CONSOLE sysctl -w net.ipv4.tcp_max_syn_backlog = "2048" ولتقليل الزمن اللازم لحذف طلب الإتصال syn سنحوله من 3 دقائق ليصبح 45 ثانية ويمكن تقليله ل 21 أو 9 ثواني بتعديل القيمة net.ipv4.tcp_synack_retries كالتالي : CONSOLE sysctl -w net.ipv4.tcp_synack_retries =3 القيم: 1 = 9 ثواني 2 = 21 ثانية 3 = 45 ثانية 5 = 3 دقائق الآن يمكن للسيرفر أن يتحمل عدد طلبات أكبر وأن ينظف ال backlog بشكل أسرع مما ينعكس على أداء السيرفر أيضا بشكل عام . الحل الثاني (وهو أبسط) : ويسمى بال syn_cookies syn_cookies عبارة عن آلية عن طريقها نستطيع أن لانضيف مداخل لل backlog وأن لا نتعامل مع TCP/IP stack إلا لو تحقق full open connection بتحقق : (syn-->syn_ack-->ack) لكن هنا السؤال المهم , كيف سنعرف أن ack القادم من client هو رد حقيقي valid ل syn_ack الذي أرسله السيرفر لي ؟ بمعنى آخر كيف أميز ال ack الحقيقي من الآخر spoofed ؟ لمعرفة ذلك يجب أن نراجع نقطة مهمة : عندما أقول ack valid أو أقول syn_ack valid فهذا يعتمد على قيمتين موجودتين في packet المرسلة تحديدا في بارامتري ACK و sequence ولتحقيق إتصال full حقيقي يجب أن يكون كالتالي : 1. أرسل syn للسيرفر وقيمة عشوائية في sequence نرمز لها ب بحجم لايزيد عن بايتين 2. السيرفر يرد ب syn_ack ويضع قيمة عشوائية أيضا في sequence ويضع في خانة acknowledgement قيمة sequence المرسلة في syn الأول + 1 3. يرد ال client ب قيمة sequence تستسخدم لاحقا في تحديد بقية ال packets في حالة حدوث fragmentation لو كان حجم ال window أكبر منMMS وهو1460 , وأيضا والأهم يضع في ack قيمة seq من ال syn_ack المستلمة + 1 هكذا تكون الجلسة قد بدأت ويمكن بعدها أن يتم تبادل البيانات , الآن من الكلام السابق يمكن وبدون أي تعديل على tcp/ip scheme وبدون أي متابعة ل syn الجديدة وبدون تخزينها في backlog أن نتأكد من صحة ack الأخير القادم بوضع قيمة محسوبة مسبقا في ack عند إرسال syn_ack كالتالي : عرف : t = أول 5 بت من ack عداد يزيد واحد كل 64 ثانية m = الثلاث بت التالية قيمة mms المستلمة من syn packet s = بقية ال 24 بت من قيمة seq التي ستجهز وترسل ل client ك syn_ack الآن هذه البارامترات أرسلت في 32bit في خانة seq لل client بالتالي هو سيرد ب ack = seq + 1 أيضا كما تم الإتفاق عليه في ack المرسل الأخير . ومن هنا يمكن أن نقوم بطرح 1 من القيمة المستلمة في السيرفر وعمل decode للقيم والتحقق من أن الإتصال valid ببساطة وأنه تابع ل valid 3 way handshaking وليس مزور من الخارج . وبعدها يتم نقل البيانات بشكل طبيعي . كما تلاحظ بدون أن نحجز موارد ل syn وقت الإرسال "بعد إمتلاء backlog" فلن نحجز ونخصص الموارد إلا بعد أن نتأكد من أن المستخدم جاد ويريد تحقيق إتصال لنقل بيانات بالتالي فهجمات syn عقيمة تماما أمام هذا التعديل , ولتحقيقه في linux يكفي فقط وقت بدء تشغيل linux "الإقلاع" أن يتم التعديل على قيمة من قيم kernel وهي في الملف :etc/proc/sys/net/ipv4/tcp_syncookies بجعلها true أي 1 كالتالي : CONSOLE echo 1 > /etc/proc/sys/net/ipv4/tcp_syncookies وتضاف لسكربت يعمل وقت start up للسيرفر ك /etc/rc.sysinit أو /etc/rc.local لتكون القيمة الإفتراضية بشكل دائم . توجد حلول يدعي أصحابها أنها ممكنة التنفيذ بال firewall وتحديدا iptables في Linux لكني لست متأكد منها !