Webship שרת אינטרנט: הגדרות מאובטחות כברירת מחדל

# Webship שרת אינטרנט: הגדרות מאובטחות כברירת מחדל

שרת ווב מאובטח לא צריך להסתמך על כך שהמפעיל יזכור הגדרה נוספת בשעה 2 לפנות בוקר. הוא צריך להתחיל מבסיס מגן, לדחות תצורה לא בטוחה, ולדרוש בחירות מכוונות לפני שהוא חושף יכולות רגישות.

זהו הדגם שמאחורי Webship. הגדרות ברירת המחדל שלו מפעילות את ההגנות העיקריות על בקשות ותשובות, מגבילות את המשאבים שהתוקף יכול לצרוך ומשאירות ממשקי בקרה אופציונליים כבויים. ניתן לכוונן את ברירות המחדל האלה עבור יישום אמיתי, אך אין צורך לגלות כל הגנה לפני שהבקשה הראשונה מגיעה.

מאובטח כברירת מחדל אינו אומר מאובטח ללא הקשר. תעודות, אישורי הרשאה ליישומים, מדיניות רשת, סודות ותגובה לאירועים עדיין שייכים למפעיל. התפקיד של Webship הוא לעשות את נקודת ההתחלה הבטוחה ברורה—ולהקשות על ההחלשה בטעות.

ההגנות שמתחילות מופעלות

Webship מאפשר שישה שכבות בתצורה הבסיסית שלו:

| שכבה | התנהגות ברירת מחדל | מה היא מפחיתה | | --- | --- | --- | | הגנה על קבצי נקודה | מונע קטעי נתיב סטטיים המתחילים בנקודה | חשיפה מקרית של קבצי סביבה, מטא-נתוני מאגר וקונפיגורציה מקומית | | חומת אש לאפליקציות ווב | חוסמת דפוסי תקיפה ידועים | הזרקות SQL, סקריפטים חוצי-אתרים, מעבר קבצים, בדיקות נתיבים רגישים, הזרקת פקודות, הברחת כותרות וקידודים של בקשות שאינם נתמכים | | בקרות DDoS | פועל במצב רגיל עם מצב לקוח מוגבל | זרמי בקשות, מעקב בלתי מוגבל, ושחיקת משאבים שניתן להימנע ממנה | | אתגר בוט | משתמש בעוגיית אתגר חתומה | ניצול אוטומטי בעלות נמוכה וסריקה חוזרת | | כותרות אבטחת תגובה | מוסיף מדיניות דפדפן מגבילה | בלבול MIME, עיצוב מסגרת, דליפת מפנה, יכולות מסוכנות של דפדפן וטעינת תוכן רחבה | | מגן API | משתמש במצב חסימה ודוחה נתיבים לא מוכרים לאחר שהוגדר חוזה API | נקודות קצה צל, שיטות בלתי-מכוונות, סוגי תוכן בלתי צפויים, ודרישות הרשאה חסרות |

ה-WAF המוגדר כברירת מחדל גם מגדיר גבולות קשיחים לגבי מה שהוא בודק: 32 KiB של כותרות בקשה, נתיב של 2,048 בתים, וגוף בקשה של 1 MiB. אלו הם מגבלות אבטחה, ולא מתגים אקראיים של ביצועים. אם יישום צריך בצורה לגיטימית בקשות גדולות יותר, יש להעלות את המגבלה הרלוונטית לאותו יישום ולבדוק את התוצאה במקום לבטל את הבדיקה באופן גלובלי.

הגנה מפני DDoS מתחילה במצב רגיל ב-600 בקשות לדקה עם גמישות של 100 לפי מפתח לקוח. טבלת מצב הלקוח מוגבלת ל-65,536 ערכים. ערכים אלה הם קו בסיס, לא מודל תנועה אוניברסלי: API ציבורי, שירות הורדות ולוח ניהול פנימי לא צריכים לחלוק את אותם מגבלות ספציפיות ליישום.

הגנות דפדפן הן חלק מהקווים הבסיסיים

מדיניות כותרת התגובה של Webship מופעלת גם כאשר אפליקציה שוכחת להוסיף את שלה. ברירת המחדל כוללת:

• X-Content-Type-Options: nosniff;
• מדיניות מניעה של מסגרת;
• מדיניות-מתייחס: ללא-מתייחס;
• Strict-Transport-Security לשנה אחת, כולל תת-דומיינים;
• מדיניות אבטחת תוכן מוגבלת לתוכן מאותו מקור, עם הגבלות על פריימינג ו-Base-URI;
• מדיניות הרשאות שמבטלת גישה למיקום, למיקרופון ולמצלמה.

ברירות המחדל האלה מוגבלות בכוונה. בדוק את HSTS לפני יישומו על דומיין עם תת-דומיינים שאינם מוכנים באופן מלא ל-HTTPS. בדוק את מדיניות אבטחת התוכן (Content-Security-Policy) לפני שאפליקציה טוענת סקריפטים, סגנונות, גופנים, תמונות או חיבורים ממקורות אחרים. ברירת מחדל מאובטחת צריכה להיכשל בצורה נראית בעת הפריסה, ולא להיחלש בשקט בייצור.

משטחים אופציונליים נשארים סגורים

Webship לא חושף כל תכונה רק כי הבינארי מכיל אותה. פרוקסי הפוך, WebTransport, נקודות קצה לניטור, TLS אוטומטי, מקוריות תגובה, ונקודת הבקרה MCP מושבתים כברירת מחדל.

נקודת הקצה MCP מוגדרת לטווח לופבק כאשר היא מופעלת ודורשת קונפיגורציית אבטחה מפורשת. מדדים וסטטיסטיקות דורשים התקנת כלי ניתוח בצורה מכוונת. ניהול תעודות אוטומטי מחייב את המפעיל לבחור ספריית ACME, אנשי קשר, אחסון ותנאי שירות. זה מונע מתכונות תפעוליות להפוך למשטחי רשת מפתיעים.

המאזין הבסיסי גם נקשר ל-127.0.0.1. מפעיל חייב לבחור במפורש כתובת ציבורית. הבחירה היחידה הזו יוצרת נקודת בדיקה שימושית עבור חוקי חומת אש, הרשאות שירות, זהות TLS וטופולוגיית פריסה.

פרוקסי הפוך שומר על גבול האמון

כאשר הפקת פרוקסי הפוכה מופעלת, מעבר TLS נשאר כברירת מחדל. Webship מעביר תעבורה מוצפנת מבלי לקחת בעלות על הטקסט הפתוח של היישום או על מפתחות הסשן הפעילים. המקור נשאר אחראי ל-TLS ולפרוטוקול שנוסף.

אפשר סיום TLS רק כאשר Webship חייב לבדוק בקשות HTTP, לנתב לפי נתיב, להחיל מדיניות WAF ו-API, לשכתב כותרות או לאחסן תגובות בזיכרון מטמון. סיום אינו פחות מאובטח מטבעו; הוא מזיז את גבול האמון. ההחלטה החשובה היא איזו מכונה מורשית לראות טקסט רגיל ולמה.

מעבר חוצה (Pass-through) גם יש לו מגבלות פונקציונליות. ניתוב TCP מבוסס על ClientHello SNI מכיוון שבקשת ה-HTTP מוצפנת. HTTP/3 מעבר חוצה דורש שהנתיבים ישתפו מקור UDP אחד. אם אתה צריך אבטחה המודעת לתוכן בקצה, סיים את TLS שם והגן על הקפיצה מהקצה למקור בנפרד.

קו בסיס ייצור שאתה יכול לבדוק

הקטע הבא מציג את ברירות המחדל החשובות במפורש במקום להסתמך על השמטה:

listen = "0.0.0.0:443"
deny_dotfiles = true

[tls]
unknown_sni = "reject"

[ddos]
enabled = true
mode = "normal"
requests_per_minute = 600
burst = 100
block_seconds = 60
max_tracked_clients = 65536

[security]
enabled = true
rate_limit_max_entries = 65536

[security.waf]
enabled = true
mode = "block"
sqli = true
xss = true
traversal = true
sensitive_paths = true
header_abuse = true
max_header_bytes = 32768
max_path_bytes = 2048
max_body_bytes = 1048576

[security.response_headers]
enabled = true
nosniff = true
frame_deny = true
referrer_no_referrer = true
hsts = "max-age=31536000; includeSubDomains"
content_security_policy = "default-src 'self'; frame-ancestors 'none'; base-uri 'self'"
permissions_policy = "geolocation=(), microphone=(), camera=()"

במאזין רב-תחומי, unknown_sni = "reject" מונע משם מארח לא מוכר לקבל את התעודה הדיפולטיבית של המאזין. המאזינים עם TLS אוטומטי של Webship כבר דוחים שמות לא מוכרים עד שקיימת תעודה.

אימות הוא מנגנון אבטחה

Webship מאמתת את התצורה לפני שהיא מקשרת מאזינים. שדות בלתי ידועים, מגבלות לא חוקיות, זהויות לא completas, מאזינים מתנגשים ושילובי פרוטוקול בלתי נתמכים גורמים לכשל אתחול עם שגיאה ספציפית. אותה אימות מתבצע לפני התקנת תצורה פעילה. טעינה מחדש שנכשלת משאירה את התצורה הנוכחית פעילה.

נתיב הקונפיגורציה המאומת MCP מוסיף משמר נוסף: הוא מסרב לשינויים חיים שיכולים להשבית WAF פעיל, שכבת DDoS, API Shield, אתגר בוט, מדיניות edge-auth או שכבת כותרות תגובה. בדיקות גרסה מונעות ממנהל אחד להחליף תמונת מצב של קונפיגורציה חדשה יותר. הגדרות מוגבלות לתהליך עדיין דורשות הפעלה מחדש במקום להעמיד פנים ששינוי חי חלקי הצליח.

זו הבחנה מועילה. ברירות המחדל המאובטחות מגנות על הפריסה החדשה. אימות טרנזקציוני ועדכונים מוגנים מגנים על הפריסה הפועלת.

אילו מפעילים עדיין צריכים להחליט

לפני חשיפת Webship לאינטרנט:

1. הגדר זהות TLS מהימנה והגן על המפתח הפרטי.
2. הגדר טיפול ב-SNI לא ידוע למבנה המאזין.
3. אשר ש-HSTS ו-Content-Security-Policy מתאימים לכל יישום ותת-תחום.
4. הגדר נקודות קצה של API Shield, שיטות מקובלות, סוגי תוכן, ודרישות הרשאה.
5. הוסף הגבלות תעריף ספציפיות לנתיב במקום להסתמך רק על הקו הבסיסי הגלובלי.
6. אפשר אימות קצה עבור מארחים או מסלולים מוגנים והשתמש בטוקנים בעלי תוקף קצר.
7. שמור על MCP ומאזיני נצפות פרטיים, מאומתים ומופרדים מתעבורת הציבור.
8. הפעל את Webship עם חשבון ייעודי ללא הרשאות מנהל, שורש יישום לקריאה בלבד כאשר אפשר, ורק את יכולות מערכת ההפעלה שהוא צריך.
9. אמת את התצורה לפני ההשקה, ואז בדוק תנועה חסומה ומותרת בסביבת קנרי.
10. ניטור אירועי ביקורת אבטחה וחזרה על המעבר ממצב רגיל למצב תחת התקפה או נעילה.

ברירת מחדל בטוחה יותר היא התחלה, לא טענה

אין שרת אינטרנט שיכול להחליט אילו משתמשים צריכים לראות את החשבוניות שלך, אילו מקורות רשאים לקרוא ל-API שלך, או באיזו מהירות נקודת הקצה העסקית שלך צריכה לקבל בקשות. בקרות אלו דורשות ידע על היישום.

Webship מספק את השכבה הנמוכה: מפענחים מוגבלים, תצורה קפדנית, כותרות תגובה מגוננות, בדיקת בקשות, בקרות ניצול, וממשקים אופציונליים סגורים. התוצאה אינה 'אבטחה נפתרה.' זהו פער קטן יותר בין התקנת שרת והפעלתו באופן אחראי.

סקור את כל Webship התיעוד לפני פריסה בייצור. סכמת התצורה והקובץ הבינארי שרץ נשארים המקורות סמכותיים לגרסה המדויקת שבה אתה מפעיל.