ציטוט:
נכתב במקור על ידי TelecarT
באיזה רמה המערכת עובדת? ברמת האפליקציה או התקשורת?
(או במילים אחרות, אם המערכת כתובה למשל בPHP.. אז היא פחות יעילה, כי בשביל להפעול thred של php השרת צריך להקצות זכרון ומעבד על מנת לפתוח את הprocess ובנוסף.. אתה יכול רק להגיב לאחר שההתקפה הגיעה לשרת ופגעה בו)
זמן הפעולה שהצגת כאן, האם מדדת את הזמן גם כשהמערכת עמוסה עקב התקפה?
ההתקפות האלו מבוססות על יצירת תנועה מדומה לאתר ועל כך.. ניצול משאבי השרת עד תום - או במילים אחרות, למה אתה חושב שהSQL שלך לא יקרוס (או יעבוד לאט) כאשר (לדוגמא) הזכרון הפיזי בשרת יגמר והמערכת תשתמש בSWAP?
השאלות הם פשוט לאחר נסיון עשיר במערכת כאלו (או במילים אחרות, אל תפגע  ) תראה בשאלות כהצעות פרקטיות לשיפור. |
המערכת אכן כתובה ב-PHP כדי למנוע תלות של לקוח בבעל השרת. זה לא הפתרון האולטימטיבי אך בעזרת זאת כל אחד יכול להשתמש בזה.
זמן הפעולה נמדד כאשר המערכת אינה עמוסה עקב התקפה. בבדיקות של כ-100 חיבורים לשניה הזמן משתנה אך לא עובר את ה-0.01 זמן עיבוד למערכת.
המערכת מייצג cache (מטמון) של קובץ PHP בעל 2 פקודות בלבד שמטרתו, בעזרת מינימום משאבים, לחסום התקפות שכבר זוהו. בתוך הקובץ שמור מערך שמתעדכן במשך הזמן עם IPים חסומים. זה מייצג מבחינתי את ה"SWAP". למרות שבסופו של דבר מערך נשמר על הזיכרון הפיזי, אני יוצא מתוך נקודת הנחה שמערכת שלא פועלת כאפליקציה על השרת לא תוכל אף פעם להתמודד עם מצב
לאחר שנגמר הזכרון. המערכת אמורה למנוע התקפה (או לפחות להאט אותה). התקפות מכוונות בסדר גודל גדול - אף מערכת ב-PHP (וכנראה גם אף מערכת שעל השרת עצמו) לא תוכל לחסום.
יש במערכת כבר תשתית לשילוב חסימה בקובץ ה-htaccess (מתוך הנחה שאם זה לא יחסם שם, המצב "אבוד") אך הבעייה היא שברגע שאני אתעסק עם הקובץ הזה, יש יותר סיכוי ל-corruption במידה והעדכון של החסימה מתבצע ב-realtime. ובמידה ואכן נוצר corruption (מצטער, לא מצאתי מונח מתאים בעברית) - הוא יכול לגרום לשיתוק האתר. לכן אני לא מעוניין להיכנס לזה.
אני מודה לך על תגובתך וחס וחלילה לא נפגע.
מכיוון שיש לך ניסיון עשיר, אשמח לדעת האם אוכל להתכתב איתך בה"פ למטרת הרחבת יעילות המערכת בזיהוי וחסימה של הצפות.