טיפים חיוניים לאבטחת Docker לאירוח עצמי

הגן על השירותים המארחים שלך, מהגנה ועד ניטור!

© 2025 Dan Levy

תוכן עניינים

• 🧗‍♀️ לנועזים
• 🔄 ריקוד :latest
• 🔐 ניהול סודות: הדרך הנכונה
• 🌐 סכנת רשת
• 🛡️ בקרות גישה
• 🔍 מעקב ואימות
• ⏰ טיפים שנשכחים לעיתים קרובות
• 🚀 רשימת בדיקה לייצור
• 📚 קריאה נוספת

🧗‍♀️ לנועזים

אם אתה מארח שירותי Docker בעצמך, האבטחה היא באחריותך מהקצה לקצה — אין ספקן ענן שיגן עליך מסריקות פורטים או תצורה רשלנית. בין אם אתה מריץ אפליקציות ברשת הביתית שלך או שוכר VPSים מספקים כמו Vultr, DigitalOcean, Linode, AWS, Azure או Google Cloud, תצטרך לנעול את המערכת – ולאמת שעשית זאת נכון.

במדריך זה נעבור על אבטחת Docker — מטכניקות „פחות מוכרות” ועד ל„קשות ליישום”; נחקור אסימוני קנרי, נפחים לקריאה בלבד, חוקים לחומת אש, סגמנטציית רשת והקשחתה, הוספת פרוקסי מאומת ועוד.

נשווה גם רשתות ביתיות לסביבות ענן ציבוריות ונראה איך להקים פרוקסי בסיסי עם אימות ב‑Nginx. בסיום יהיו לך כמה אפשרויות לשמור על האזור שלך מפני זבל (חברים, משפחה, ולפעמים אפילו אתה עצמו…)

זה הרבה חומר! אבל רובו קשור, ותוכל לבחור מה שהכי רלוונטי למערכת שלך. 🍀

🔄 ריקוד :latest

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

הדרך הבטוחה לעדכן

שלב פקודות עדכון עם pull או build כך שתרענן תמונות במודע, ואז תאתחל בחלון שבו תוכל לתפוס תקלות.

#!/bin/bash
docker compose pull && \
  docker compose up -d

הצמדת גרסאות מול latest

בחירת גרסה להצמדה היא איזון בין יציבות לאבטחה. הנה כמה אסטרטגיות נפוצות:

# ...
  # הצמדת גרסה מדויקת, הטובה ביותר לשירותים קריטיים
  image: postgres:17.2

  # הצמדת גרסת תיקון, מתאימה לשירותים לא קריטיים
  image: postgres:17.2

  # הצמדת גרסה ראשית, מושלמת לפרויקטים תחביביים
  image: postgres:17

  # יולו, יש להימנע אם אפשר
  image: postgres:latest

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

ספר לי על הכלים האהובים עליך לשמירה על עדכניות תמונות Docker!

🔐 ניהול סודות

• יצירת סודות חזקים
• טוקני קנרי
• שדרוג מ‑.env ל‑Keychain של macOS

ישנן דרכים רבות לנהל סודות, אך אחד הכללים החשובים ביותר הוא: לעולם אל תכתבו סודות בקוד של תמונות Docker או תתחייבו אליהם ב‑git. זו אחת הטעויות האבטחתיות הנפוצות ביותר, היא יוצרת סיכון ארוך‑טווח, ותיקונה כואב.

אחסון סודות בצורה מאובטחת הוא נושא רחב עם אפשרויות רבות, מקבצי .env, Docker secrets, 1Password/Bitwarden, או מנהל סודות כמו HashiCorp Vault או AWS Secrets Manager.

תצטרך לבחור את רמת המאמץ והאבטחה „הנכונה” למקרה השימוש שלך.

יצירת סודות חזקים

הנה סקריפט קטן ליצירת סודות חדשים לקובץ .env:

#!/bin/bash
generate_secret() {
    local length=${1:-30}
    local generate_length=$((length + 4))
    openssl rand -base64 "$generate_length" | tr -d '+=/\n' | cut -c1-"$length"
}

[ -f .env ] && { echo ".env file already exists!"; exit 1; }

cat > .env << EOL
POSTGRES_PASSWORD=$(generate_secret)
JWT_SECRET=$(generate_secret 64)
SESSION_KEY=$(generate_secret 24)
REDIS_PASSWORD=$(generate_secret 20)
UNSAFE_PLACEHOLDER=__WARNING_REPLACE_RANDOM_TEXT__
EOL

echo "New .env file generated with secure random values!"

אסימוני קנרי

Canary Tokens הם דרך מצוינת לגלות אם הסודות שלכם נחשפו (ונשמשו). הם כמו חוט מוקרן שניתן להוסיף לכל קובץ רגיש, URL או אסימון.

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

קיימים סוגים רבים של “אסימוני קנרי”, החל מאסימוני AWS, מספרי כרטיסי אשראי זויפים (ראו המאמר), קבצי Excel ו‑Word, קבצי Kubeconfig, אישורי VPN, ואף קבצי dump של SQL יכולים להכיל חוט מוקרן!

best practices לאסימוני קנרי

• הצבה בכל מקום: בכל קובץ .env, צינור CI/CD, ובכל “מנהל סודות” שיכול לעלות על דעתכם.
  • הניחו קובץ passwords.xlsx או passwords.docx בתיקיית הבית.
  • הוסיפו פרופיל AWS billing_prod עם אסימון קנרי כסוד.
  • צרו קובץ private.key לתיקיית ~/.ssh.
  • צרו dump של SQL בשם all_credit_cards.sql בתיקיית ~/backups.
• מעקב: קבעו כללי אימייל/התראות שיתפסו כאשר אסימון קנרי נטרל.

שדרוג מ‑.env ל‑Keychain של macOS

למשתמשי macOS, אחת האפשרויות הפשוטות היא להשתמש ב‑Keychain.

הנה דרך קלה לאוטומציה של טעינת סודות מ‑Keychain של macOS, תומכת ב‑TouchID, והיא בטוחה במקצת יותר מקבצי .env.

Original credit: Brian Hetfield and Jan Schaumann.

### פונקציות להגדרת וקבלת משתני סביבה מ‑Keychain של macOS ###
### מותאם מ‑: https://www.netmeister.org/blog/keychain-passwords.html ו‑
Original credit: [Brian Hetfield](https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbee4404fd) and [Jan Schaumann](https://www.netmeister.org/).

# שימוש: get-keychain-secret SECRET_ENV_VAR
function get-keychain-secret () {
    security find-generic-password -w -a ${USER} -D "environment variable" -s "${1}"
}

# שימוש: set-keychain-secret SECRET_ENV_VAR
# תתבקשו להכניס את ערך הסוד!
function set-keychain-secret () {
    [ -n "$1" ] || print "Missing environment variable name"

    # בקשת סוד מהמשתמש
    echo -n "Enter secret for ${1}"
    read secret
    [ -n "$secret" ] || return 1

    ( [ -n "$1" ] || [ -n "$secret" ] ) || return 1
    security add-generic-password -U -a ${USER} -D "environment variable" -s "${1}" -w "${secret}"
}

source ~/keychain-secrets.sh

# טעינת משתני סביבה למעטפת הנוכחית
export AWS_ACCESS_KEY_ID=$(get-keychain-secret AWS_ACCESS_KEY_ID);
export AWS_SECRET_ACCESS_KEY=$(get-keychain-secret AWS_SECRET_ACCESS_KEY);
# הערה: אם תוקף מצליח להריץ `env` במעטפת שלכם, הסודות עלולים להיחשף!

#!/usr/bin/env bash
source ~/keychain-secrets.sh

# ציון כל הסודות לפרויקט הזה
AWS_ACCESS_KEY_ID=$(get-keychain-secret AWS_ACCESS_KEY_ID) \
AWS_SECRET_ACCESS_KEY=$(get-keychain-secret AWS_SECRET_ACCESS_KEY) \
  "$@"

# הערה: עטיפת מעטפת מסייעת למנוע שהסודות יישארו
# במשתני הסביבה. וזה בטוח למחויבות.

# שימוש:
# ./scripts/env-run.sh docker compose up -d
# ./scripts/env-run.sh docker run -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY ...

🌐 סכנת רשת

רשתות מותאמות אישית ויציאות פנימיות

בידוד שירותים באמצעות רשתות Docker הוא דרך משמעותית להפחתת שטח ההתקפה.

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

בברירת מחדל, שירותים ברשת LAN פרטית לא יחשפו לאינטרנט — צריך להגדיר במפורש העברת פורטים מהנתב.

Docker ב‑LAN

בין אם אתם מפתחים שמריצים שרתי פיתוח מקומיים, או שמארחים שירותים מהרשת הביתית, הנחות לגבי מודל הרשת של Docker עלולות לגרום לבעיות.

מפתחים מופתעים לגלות שהשיטות “המסורתיות” לאבטחת שרתי לינוקס (iptables, הגבלת אפשרויות sysctl של tcp/ip) יכולות לכשל בשקט במכונות Docker! זה קורה במיוחד ב‑הארחה עצמית או ברשת ביתית טיפוסית. (לאנשים שבקצה: זה יכול לאפשר גישה למכולות פיתוח במקבוק שלכם!!!)

⚠️ אזהרה #1: פתיחת פורטים על‑ידי Docker יכולה לעקוף את חוקי חומת האש שחשבת שהם מגנים על המארח, במיוחד עם UFW ב‑Ubuntu/Debian. זה לא מבטל את כל חוקי חומת האש, אבל משמעותו ש„UFW אומר deny“ אינו הוכחה. ראו נושא #690: Docker עוקף חוקים של ufw firewall.

⚠️ אזהרה #2: קשירת פורטים לכתובות IP מקומיות (למשל, -p 127.0.0.1:8080:80) היא ברירת המחדל הנכונה, אך גרסאות של Docker Engine לפני 28.0.0 כללו מקרים שבהם מארחים באותה רשת L2 יכלו עדיין להגיע לפורטים שפורסמו ל‑localhost. Docker מתעד את המגבלה במדריך פרסום הפורטים שלו, וההרגל של אימות עם nmap שמופיע למטה עדיין רלוונטי.

אם זה הפתיע אותך, אתה לא לבד!

קישור ל‑IP מקומי עדיין נוהל טוב ויש לו השפעה משמעותית בסביבות ענן מנוהלות ורשתות שמוגדרות במיוחד.

דוגמת Docker Compose

הנה קובץ docker-compose.yml לדוגמה שמקשר את שירות app ל‑127.0.0.1:8080 ומחבר את שני המכולות לרשת המותאמת backend.

networks:
  backend:

services:
  app:
    networks:
      - backend
    ports:
      # Bind to localhost if possible
      - "127.0.0.1:8080:8080"
    # ... other settings
  database:
    image: postgres:17.1
    # No ports needed; accessible inside backend network.
    networks:
      - backend

שיטות עבודה מומלצות ברשת

• 🏆 אל תפרסם אף פורט לאחרונה גיליתי שזה יותר מועיל ממה שציפיתי! כשמשתמשים ברשת ממוסמת (bridge) בשם, למכולות יש גישה בלתי מסוננת אחת לשנייה. הן פועלות כאילו הן מאחורי רשת מקומית (שער NAT).
  • למרות שלא תמיד אפשרי, זה עשוי להיות שימושי למכולות שמריצות משימות אצווה, או שנגישות בעיקר דרך attach או exec.
• 🥇 השתמש ברשתות Docker כדי לבודד ולשלוט באילו מכולות מותר לתקשר.
• 🥉 קשר ל‑localhost: למרות שהיא לא מושלמת, בדרך כלל עדיף לקשר פורטים לכתובת לולאה (למשל, 127.0.0.1:8080:80). רק ודא שאתה מאמת את ההגדרה שלך.

🛡️ בקרות גישה

בקרות גישה הן חלק קריטי באבטחת שירותי Docker שלך. זה כולל הגבלת יכולות וההרשאות של המכולות, הגבלת גישה לשקע Docker, ועוד.

• הגבלת יכולות מכולה
• גישה לשקע Docker
• חסימת מדינה!
• הקשחת מארח פרוקסי CloudFlare

הגבלת יכולות מכולה

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

מהן יכולות? הרשאות או יכולות מוגדרות בליבת לינוקס, בעלות שם. (דף ה‑man capabilities מכיל רשימה מלאה.) הן כוללות למשל CAP_CHOWN (שינוי בעלות קובץ), CAP_NET_ADMIN (קונפיגורציית ממשקי רשת), CAP_KILL (חיסול כל תהליך), ועוד רבים.

שתי הדרכים לקבוע אילו יכולות נדרשות:

1. נסיון וטעייה: שיטה איטית אך יעילה שמתחילה ללא יכולות, ואז מוסיפה אותן אחת אחרי השנייה עד שהאפליקציה עובדת.
2. חיפוש עבודה קודמת: חפש “project-name cap_drop Dockerfile” או “project-name cap_drop docker-compose.yml” כדי לראות אם אחרים כבר טיפלו בזה. מודל שפה גדול יכול להציע נקודת התחלה, אך יש להתייחס אליו כהשערה עד לבדיקת המכולה וקריאת תיעוד התמונה.

שיטות עבודה מומלצות ליכולות

• הפלת כל היכולות: השתמש ב‑cap_drop: [ ALL ] כדי להסיר את כל היכולות הלינוקסיות מהמכולה.
• אין הרשאות חדשות: השתמש ב‑security_opt: [ no-new-privileges=true ] כדי למנוע מהמכולה לקבל הרשאות חדשות.

services:
  database:
    image: postgres:17.1
    networks: [ db-network ]
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - DAC_READ_SEARCH
      - FOWNER
      - SETGID
      - SETUID
  db-admin:
    image: dpage/pgadmin4:4.1
    networks: [ db-network ]
    ports:
      - "8081:80"
    # ... other settings
networks:
  db-network:

כעת השירותים שלך יכולים לתקשר זה עם זה דרך רשת db-network. Docker Compose ייצור רשת זו אוטומטית.

השתמש באופציה --external/external: כדי להצטרף ל‑רשת קיימת. השאר ריק כדי ליצור רשת חדשה.

גישה לשקע Docker

⚠️ אזהרה: docker.sock הוא בעצם גישה מנהלית למארח

⚠️ אפשרות :ro לא משפיעה על קלט/פלט שנשלח דרך השקע!

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

שיטה מומלצת לשקע

• 🥇 הימנע מהתקנת שקע Docker, סביר להניח שיש חלופה טובה יותר.
• 🫣 אם אין ברירה, הציב פרוקסי מצומצם לפניו והתר רק את נקודות הקצה של ה‑API שהאפליקציה באמת צריכה. עיין בפרויקט docker-socket-proxy שמקורו ב‑Tecnativa, docker-socket-proxy. לאחר מכן וודא שהקריאות שנדחו אכן נדחו.
• 🤢 אולי, בסביבה של אמון גבוה, סיכון נמוך ניתן לשתף אותו לצורך בדיקות.

חסימת מדינה!

לפעמים שימושי, אך אינו גבול אבטחה ממשי.

מדברים על הישות הגיאופוליטית, לא על המוזיקה…

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

הסתכל על הסקריפט הזה לחסימת כל התנועה מסין:

curl -fsSL https://www.ipdeny.com/ipblocks/data/countries/cn.zone | \
  while read line; do ufw deny from $line to any; done

באופן דומה, אפשר לאפשר רק תנועה מארה״ב:

curl -fsSL https://www.ipdeny.com/ipblocks/data/countries/us.zone | \
  while read line; do ufw allow from $line to any; done

חיזוק פרוקסי של CloudFlare

אם השרת הבית שלך מוגן מאחורי IP של CloudFlare (פרוקסי), אפשר להגביל גישה רק ל‑IP‑ים של CloudFlare ולרשת המקומית שלך.

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

ufw default deny incoming # חסום את כל התעבורה הנכנסת!!!
ufw default allow outgoing # אפשר את כל התעבורה היוצאת
ufw allow ssh # אפשר SSH

# אפשר גישה לתת‑רשת המקומית (עדיף DMZ/VLAN ייעודית לשירותים המארחים)
ufw allow from 10.0.0.0/8 to any port 443

# אפשר IP‑ים של CloudFlare
curl -fsSL https://www.cloudflare.com/ips-v4 | \
  while read line; do ufw allow from $line to any port 443; done
# הוספת תמיכה ב‑IPv6
# curl -fsSL https://www.cloudflare.com/ips-v6 | \
#   while read line; do ufw allow from $line to any port 443; done

כדי לבדוק שינויים מבוססי‑גאוגרפיה, ניתן להשתמש ב‑VPN עם מיקומים במדינה הרצויה. מידע נוסף בקטע Monitoring & Verification.

אבטחת שכבת היישום

לאחר שה‑רשת והשרת הקשיחים, ייתכן שתגלו שיש עוד משימות לביצוע.

עכשיו עלינו לחשוב על שכבת ה‑“יישום” של השירותים עצמם.

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

הדרך היחידה לדעת זאת היא לבדוק. במקרה זה, התחילו עם קובץ README וקבצים מרכזיים אחרים כמו docker-compose.yml, Dockerfile, ו‑.env.*. גם בפרויקט עצמו וגם, באופן אידיאלי, בשירותים התומכים שלו (למשל Postgres, Redis, וכדומה).

פרוקסי הפוך

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

location /admin {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://internal_admin:80;
    proxy_set_header X-Real-IP $remote_addr;
}

יצירת אישורים:

htpasswd -c /etc/nginx/.htpasswd admin

עם פרוקסי אימות בסיסי, לתוקפים יש מכשול נוסף — שם משתמש וסיסמה — לפני שהם מגיעים לשירות הפנימי שלכם.

אפשרות נוספת היא להשתמש בשירות כמו Traefik או Caddy שיכול לאוטומט את ניהול ה‑HTTPS והאימות הבסיסי עבורכם.

אם אתה רוצה לנהל הרבה דומיינים ושירותים עם ממשק גרפי, אני ממליץ על Nginx Proxy Manager.

🔍 ניטור ואימות

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

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

בנוסף, ידיעת כמה פקודות בסיסיות – או היכן לחפש אותן – יכולה להיות ההבדל במניעת פריצה. התחושה של להיות האקר היא רק בונוס. (לפרטים ולדוגמאות, קפוץ קדימה לקטע ניטור ואימות.)

אל תסמוך, אמת פעמיים

בדוק את הפורטים שלך

⚠️ חשוב: אל תסרוק מארחים שאינם בבעלותך.

בין אם אתה ברשת ביתית או ב‑VPS, תרצה לדעת אילו פורטים פתוחים לעולם.

יש 2 דרכים לעשות זאת:

• לבדוק את הרשת (nmap, masscan)
• לשאול את מערכת ההפעלה (lsof, netstat, ss)

בדיקה מחוץ לרשת שלך

תצטרך את ה‑IP הציבורי הנוכחי שלך, בקלות עם שירותים כמו ifconfig.me: curl https://ifconfig.me. או לבדוק זאת בלוח הבקרה של ספק האירוח שלך.

curl -fsSL https://ifconfig.me
# --> CURRENT PUBLIC IP

לאחר שיש לך את ה‑IP הציבורי, עכשיו עליך להתחבר מרשת חיצונית. אפשר להשתמש במחשב של חבר, בטלפון/חיבור 5G, או במארח שרת ייעודי.

target_host="$(curl -fsSL https://ifconfig.me)"

הערה: ודא ש‑target_host הוא ה‑IP הרצוי

סריקת פורטים ספציפיים:

nmap -A -p 80,443,8080 —open —reason $target_host

100 הפורטים המובילים:

nmap -A —top-ports 100 —open —reason $target_host

כל הפורטים

nmap -A -p1-65535 —open —reason $target_host

#### בדיקה ברשת הפנימית שלך

תרגל שימוש ב‑`nmap`, סרוק את הרשת המקומית שלך או אחד השרתים, בדוק את הנתב, המדפסת, המקרר החכם.

{/* בעוד שסקרי פורטים הם עובדה קבועה בחיי היום‑יום, הם עלולים להוות הפרה של חוק ה‑CFAA (Computer Fraud and Abuse Act) בארה״ב. לכן, סרוק רק משאבים שבבעלותך. */}

#### דוגמאות לפקודות סריקה

```bash

# סרוק את הלוקאלהוסט שלך לכל הפורטים הפתוחים
nmap -sT localhost

# סרוק את ה‑IP הפרטי של המכונה שלך לשירותים
nmap -sV 192.168.1.10

# מצא פרטי שירותים ברשת שלך
nmap -sn 192.168.0.0/24
nmap -sn 10.0.0.0/24
# או ברשת Docker 172.18.0.1/16
nmap -sn 172.18.0.1/16

% nmap -A --open --reason 192.168.0.87

Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-06 13:51 MST
Nmap scan report for dev02.local (192.168.0.87)
Host is up, received syn-ack (0.0067s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT     STATE SERVICE     REASON  VERSION
22/tcp   open  ssh         syn-ack OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|_  256 {FINGERPRINT} (ED25519)
80/tcp   open  http        syn-ack Caddy httpd
|_http-server-header: Caddy
|_http-title: Dev02.DanLevy.net
443/tcp  open  ssl/https   syn-ack
|_http-title: Dev02.DanLevy.net
1234/tcp open  http        syn-ack Node.js Express framework
|_http-cors: GET POST PUT DELETE PATCH
|_http-title: Dev02.DanLevy.net (application/json; charset=utf-8).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.36 seconds

צפייה בפורטים פתוחים

היכרות עם lsof – הוא זמין ב‑MacOS וב‑Linux. הוא מציג מצב רשת מדויק ופעילות דיסק.

# ניטור פורט ספציפי
sudo lsof -i:80 -Pn

# ניטור חיבורים במצב ESTABLISHED
sudo lsof -i -Pn | grep ESTABLISHED
# צפייה ב‑LISTEN
sudo lsof -i -Pn | grep LISTEN

# להצגת שמות רשת במקום כתובות IP (יכול להיות איטי מאוד עקב חיפושי DNS הפוכים)
sudo lsof -i -P | grep LISTEN

ניטור כל החיבורים ברשת

sudo watch -n1 “lsof -i -Pn”

#### פלט לדוגמה

![nmap scan for listeners](../lsof-scan-listen.webp)

### ניטור קבצים

כדי לזהות אילו **תהליכים** צורכים את רוב **רוחב הפס של הדיסק**, אפשר להשתמש ב‑`iotop`:

```bash

sudo iotop

כדי לראות שינויים בקבצים באופן פרטני, ניתן להשתמש ב‑inotifywait בלינוקס או ב‑fswatch ב‑MacOS:

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

# ניטור כל השינויים בקבצים בתיקייה
sudo inotifywait -m /path/to/directory

ב‑MacOS אפשר להשתמש ב‑fswatch:

התקנה עם brew install fswatch

fswatch -r /path/to/directory

⏰ טיפים שנשכחים לעיתים קרובות

1. הגבלת קצב לניסיונות אימות ולכל נקודות קצה מרכזיות אחרות. בין אם דרך מודול limit_req של Nginx או fail2ban לגישה ל‑SSH, האטת brute‑force היא כנראה רעיון טוב. אני אומר כנראה כי בעידן IPv6 והבוטנטים הזולים, המצב כבר לא כמו פעם.

2. השתמשו בנפחים קריאה‑רק ככל האפשר:

services: webapp: volumes:

• ./config:/config:ro

   בשילוב עם שאר שיטות הטובה (משתמשים לא‑root, הרשאות תיקייה מינימליות), אפשרות ההרכבה `:ro` מוסיפה הגנה נוספת מפני שינויים בטעות ומניסיונות כתיבה מהקונטיינר. היא לא מגנה על המארח מפני תהליך שכבר בעל הרשאות רחבות יותר.

3. **בצעו ביקורת גישה לקונטיינרים** באופן קבוע. אם קונטיינר לא צריך סוד, פתחה או mount, הסירו אותם!

4. **היזהרו מרעשי WiFi**
   בטח שלא תתנו את סיסמת ה‑WiFi שלכם לכל אחד, במיוחד ל‑weirdos, נכון? חוץ מכמה חברים… אולי גם משפחה. אף אחד לא יודע אילו אפליקציות יש להם ואילו מהן עשויות לשתף את ה‑SSID והסיסמה שלכם עם העולם.

### רשת ביתית vs. ספק ציבורי vs. טונלינג

1. **בידוד וירטואלי/DMZ**: עבור שרתי בית, העבירו אותם ל‑VLAN או DMZ נפרד אם אפשר. זה שומר על המכשירים הפנימיים שלכם מחוץ להישג יד של פגיעה פוטנציאלית מהצד של השרת.
   - השתמשו בנתב נפרד או VLAN לשרת הבית שלכם.
   - השתמשו ברשת WiFi נפרדת לשרת הבית שלכם.
   - השתמשו בתת‑רשת נפרדת לשרת הבית שלכם.

2. **ספקי ענן**: Hetzner, Vultr, DigitalOcean, Linode, AWS, Azure, ו‑Google Cloud כולם מציעים תכונות חומת אש שונות.
   - חלק מהספקים והשירותים חוסמים פורטים כברירת מחדל. חלקם מציעים אפשרויות בחירה או תוספות. בדקו את תיעוד ספק השירות שלכם.
   - ספקים רבים מציעים שירותי ניטור מתקדמים וזיהוי אי‑איום.

3. **VPNים & חיבורי תעלה**: שקלו להשתמש באפשרות דמו‑VPN או שירות תעלה כדי לחבר שירותים בצורה מאובטחת דרך האינטרנט מבלי לחשוף אותם לאינטרנט הציבורי.
   - TailScale, ngrok, ZeroTier.
   - WireGuard, OpenVPN.

{/* 3. **Hardening Against Internal/Lateral Attacks**: One infected device can compromise an entire network. Segmenting Docker services on custom networks, using hardware, UFW rules, and blocking unneeded ports can all help reduce risk (when properly configured.) */}

## 🚀 רשימת בדיקה לייצור

- [ ] **סודות**: כל הסודות נוצרו רנדומלית ונשמרו בצורה מאובטחת
- [ ] **עדכונים**: אסטרטגיית עדכון קונטיינרים מתועדת ומאוטומטת. (זה בסדר אם מדובר בכמה פקודות בקובץ טקסט.)
- [ ] **רשת**: רק הפורטים הדרושים נחשפים, רשתות פנימיות מוגדרות.
- [ ] **כללי חומת אש**: ברירת מחדל של חסימה, הרשאות מפורשות, חסימות לפי מדינה אם נדרש.
- [ ] **פרוקסי הפוך**: Nginx, Caddy או Traefik יכולים להוסיף שכבת אימות בסיסי.
- [ ] **טוקנים קנריים**: מקמו אותם ליד הקבצים הרגישים והאישורים שהייתם בודקים בפועל אם נגעו בהם.
- [ ] **ניטור**: הכירו את המערכות שלכם עם `nmap`, `lsof`, `inotifywait`, `glances` וכו'.
- [ ] **אסטרטגיית גיבוי**: נבדקה, רצוי אוטומטית, וממוקמת מחוץ לאתר.
- [ ] **מינימום הרשאות**: משתמשי קונטיינר ללא root, נפחים במצב קריאה‑כתיבה בלבד.

## 📚 קריאה נוספת

- [Docker Security Best Practices](https://docs.docker.com/develop/security-best-practices/)
- [OWASP Docker Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html)
- [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker)
- [Canarytokens.org for Canary Tokens](https://canarytokens.org/)

## תודה

קרדיט למספר רדיטורנים ערניים:

- <em className="cite">[u/JCBird1012](https://www.reddit.com/user/JCBird1012/) - [thread](https://www.reddit.com/r/selfhosted/comments/1hv8jn6/comment/m5rvlzi/).</em>
- <em className="cite">[u/Salzig](https://www.reddit.com/user/Salzig/)</em>
- <em className="cite">[u/Myelrond](https://www.reddit.com/user/myelrond/)</em>
- <em className="cite">[u/shrimpdiddle](https://www.reddit.com/user/shrimpdiddle/)</em>
- <em className="cite">[u/troeberry](https://www.reddit.com/user/troeberry/)</em>

תודה על הקריאה! מקווה שהמדריך היה מועיל. אם יש לכם שאלות או הצעות, אתם מוזמנים ליצור קשר ברשתות החברתיות שלי למטה, או ללחוץ על הקישור `Edit on GitHub` כדי לפתוח בקשת משיכה! ❤️