Tarpits הגנתיים:ללכוד בוטים של brute-force, באופן חוקי

בוט מציף את עמוד ההתחברות שלכם בזוגות שם-משתמש-וסיסמה גנובים. התשובה המפתה — זו שמסתובבת בפורומי אבטחה — היא לירות בחזרה «פצצת טאבים»: עמוד שמריץ בלולאה את window.open() עד שהדפדפן או המכונה של התוקף קורסים. אל תעשו זאת. זה לא חוקי אפילו כשהוא מכוון נגד תוקף, זה עלול להקפיא לקוח אמיתי שפשוט שגה בהקלדת הסיסמה, וחוסם חלונות קופצים מנטרל את התרגיל תוך אלפיות שנייה. המהלך שבאמת מתיש תוקף שקט יותר ולגאלי לחלוטין: לזהות את ההתעללות, להסיט אותה למלכודת-דבש (honeypot), ולתרפת (tarpit) את החיבור כך שכל בקשה תיתקע לנצח בזמן שאתם מתעדים הכול. זהו tarpit הגנתי.

הגדרהמהו tarpit הגנתי באמת

tarpit עונה ללקוחות פוגעניים לאט ככל שהוא יכול, ומחזיק את החיבור שלהם פתוח וחסר תועלת במקום לסגור אותו. חומת אש אומרת «לא» תוך אלפית שנייה ומשחררת את התוקף ליעד הבא; tarpit אומר «כמעט…» ללא הגבלה, ומרתק את ה-sockets, ה-threads והסבלנות של הבוט אליכם. «הסטה בעת כשל אימות» היא פשוט tarpit המחובר לתהליך ההתחברות שלכם: ברגע ש-IP חוצה סף, בקשותיו מנותבות בשקט מנקודת הקצה האמיתית אל המלכודת, והוא לעולם לא מקבל שוב תשובה נקייה.

המיתוסמדוע «להפיל את התוקף» מתפוצץ לכם בפנים

שליחת payload שנועד להפיל את הלקוח היא «hacking back», והיא נכשלת בשלוש חזיתות בבת אחת:

• זה פשע. פגיעה בתפקוד מחשב של מישהו אחר — כן, אפילו של תוקף — היא גישה לא מורשית לפי חוקים כמו ה-Computer Fraud and Abuse Act האמריקאי, ה-Computer Misuse Act הבריטי ומקביליהם בעולם. אתם מעניקים לצד השני קורבן: אתם.
• אתם יורים בעיוורון. כתובת ה-IP המקורית היא בדרך כלל צומת בוטנט, פרוקסי משותף, יציאת VPN או מכשיר שנפרץ ושייך למישהו חף מפשע לחלוטין. payload הרסני פוגע במי שבמקרה נמצא מאחוריה.
• זה פשוט לא עובד. דפדפנים מגבילים וחוסמים window.open() משתולל, וכל תוקף מיומן מפעיל לקוח headless מתוך קונטיינר חד-פעמי שאף פצצת טאבים אינה יכולה להגיע אליו.

מנגנוןכיצד פועלת הסטה בעת כשל אימות

מתחת למכסה המנוע זהו כלל זיהוי אחד המזין כלל ניתוב אחד. כאשר IP חוצה סף התנהגותי, ה-reverse proxy שלכם מפסיק להעביר אותו ל-backend האמיתי ומתחיל להעביר אותו אל מלכודת שכל תפקידה הוא להיראות אותנטית בעודה איטית ומאובזרת היטב. האסטרטגיה שתבחרו למלכודת קובעת כמה היא תעלה לתוקף:

tarpit של חיבור הוא הבחירה הבטוחה ובדוקת-הזמן: קבלו את הבקשה, ואז טפטפו את התגובה בייט אחר בייט, תוך החזקת ה-socket פתוח כל עוד הלקוח מוכן לחכות. כלים ייעודיים עושים בדיוק זאת שנים — endlessh עבור SSH, ו-SMTP tarpits קלאסיים נגד ספאם. אותו רעיון נכנס בכמה שורות כמסלול מלכודת, ושימו לב שכל ההשהיה מושקעת בהחזקת התגובה שלכם עצמכם פתוחה:

// Express honeypot: divert flagged IPs here, then trickle a response
// out slowly. All latency is on OUR server — nothing touches the client
// machine. Pair with a hard cap on concurrent tarpit sockets.
const tarpit = new Set();

app.use((req, res, next) => {
  if (flaggedIps.has(req.ip)) return res.redirect(307, "/trap");
  next();
});

app.all("/trap", (req, res) => {
  // Log the full attack signature for blacklisting + threat intel.
  logger.warn("tarpit", { ip: req.ip, ua: req.get("user-agent"), body: req.body });
  res.setHeader("Content-Type", "text/html");
  tarpit.add(res);
  // Drip one harmless byte every 10s; the bot's socket stays stuck on us.
  const drip = setInterval(() => res.write(" "), 10_000);
  req.on("close", () => { clearInterval(drip); tarpit.delete(res); });
});

ארכיטקטורהמחסנית ה-blue team סביב המלכודת

ה-tarpit הוא רק ה-payload; דווקא הזיהוי והבידוד העוטפים אותו הם שהופכים אותו לבטוח ושימושי כאחד. פריסה מלאה כוללת ארבע שכבות:

1. זיהוי — WAF או IDS המשגיח על הנתיבים החשובים (/admin, /login) עם סף נוקשה, נאמר 5 כשלי התחברות תוך 10 שניות, המופעל רק לאחר ש-rate-limiting ו-CAPTCHA כבר סיננו את הרעש הרגיל.
2. הסטה — כלל reverse proxy ששולח, ברגע ש-IP מסומן, את כל התעבורה העתידית שלו אל מארח המלכודת במקום ל-backend האמיתי.
3. המלכודת — מלכודת-דבש מבודדת (לעולם לא שרת הייצור שלכם) המריצה tarpit של חיבור, התחברות מזויפת המתעדת כל אישור שנוסה, או שניהם.
4. תיעוד ותגובה — שמרו את ה-IP, ה-User-Agent וחתימת המתקפה, הזרימו אותם למשהו כמו fail2ban כדי להרחיב ולהאריך חסימות, ודחפו אינדיקטורים מאומתים אל רשימות החסימה שלכם.

אמצעי זהירותכיצד לפרוס זאת מבלי לפגוע במשתמשים אמיתיים

• בידוד אינו ניתן למשא ומתן. הריצו את המלכודת על שרת סטטי ומבודד. ללוגיקת הגנה אקטיבית אין מקום ביישום הייצור הראשי שלכם.
• תחילה rate-limiting ו-CAPTCHA. סננו ספאם רגיל וטעויות כנות לפני שמשהו בכלל מסומן, כך שהמלכודת תפגוש רק אוטומציה מאומתת.
• העדיפו דיוק על פני כיסוי. תוצאה חיובית-שגויה מקפיאה לקוח אמיתי ששכח את סיסמתו — הטו את הספים לכיוון הוודאות ותנו למשתמשים לגיטימיים מסלול שחזור ברור ומהיר.
• שִמרו כל אפקט בצד שלכם של הכבל. תגובות איטיות, עמודים מזויפים ותיעוד ניתנים להגנה; כל דבר שנבנה כדי לרוץ על מכונת הלקוח או לפגוע בה — לא. אל תשחררו אותו.