כיצד להגן על אפליקציית אינטרנט עם Authelia מבלי לשנות אותה

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

Authelia מאפשרת לך למקם מחסום אימות מול אפליקציה מבלי לשנות את הקוד שלו. כאשר מישהו מנסה לפתוח אותו, ה-reverse proxy מבצע תחילה שאילתה לאותליה. רק לאחר אימות שם המשתמש, הסיסמה, ואם רלוונטי, הגורם השני, הבקשה ממשיכה לשירות.

מדריך זה מניח ש-Authelia וה-reverse proxy כבר פועלים. אם עדיין עליך להגדיר את התשתית הזו, עליך תחילה... הגדר את Authelia עם מנהל הפרוקסי של Nginx ולוודא ששני המכולות יכולים לתקשר.

מה המשמעות של הגנה על אפליקציה עם Authelia?

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

הזרימה עובדת כך:

1. המשתמש פותח את תחום האפליקציה.
2. הפרוקסי שולח שאילתה פנימית לאותליה.
3. אוטליה בודקת את מדיניות הגישה וההפעלה.
4. אם חסר אימות, הפנה את המשתמש לפורטל שלך.
5. לאחר האישור, נציג הכוח מוסר את הבקשה המבוקשת.

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

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

מה שצריך לפני הגנה על האפליקציה

לפני שאתם מתחילים, ודאו שיש לכם:

• מופע פונקציונלי של אוטליה.
• פרוקסי הפוך תואם המשולב כראוי עם Authelia.
• דומיין או תת-דומיין עבור האפליקציה.
• תעודת HTTPS בתוקף.
• משתמש או קבוצה מורשים בקצה האחורי של הזהויות.
• גישה לקובץ configuration.yml מאוטליה.
• שליטה על קובץ Docker Compose או על חומת האש של האפליקציה.

התחום הציבורי של האפליקציה חייב להשתמש ב-HTTPS. כמו כן, היא חייבת להיכלל באחד מהדומיינים המוצהרים ב- session.cookiesלדוגמה, קובץ Cookie מוגדר ל example.com ניתן להשתמש עם app.example.com y auth.example.com.

אין להשתמש בדומיינים ציבוריים משותפים שלמים, כגון duckdns.org, כדומיין העוגיות. עליך להשתמש בתת-דומיין משלך, כגון miservidor.duckdns.org.

כיצד לסגור את קיצור הדרך של פורט היישום

ההגנה של Authelia מאבדת הרבה מהשימושיות שלה אם מישהו יכול לעקוף את הפרוקסי על ידי גישה אליו ישירות דרך כתובת כמו:

http://IP_DEL_SERVIDOR:8080

אם היישום פועל ב-Docker, הסר את המקטע ports שמפרסם את הפורט שלו על המארח:

services:
  mi-aplicacion:
    image: imagen/de/la-aplicacion:version
    container_name: mi-aplicacion
    restart: unless-stopped
    networks:
      - proxy
    expose:
      - "8080"

networks:
  proxy:
    external: true

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

הדבר החשוב באמת הוא לא להשתמש במשימה כמו:

ports:
  - "8080:8080"

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

אם היישום פועל בשרת אחר ועליך להשאיר את הפורט פתוח, השתמש בחומת האש כדי לאפשר חיבורים רק מכתובת ה-IP של ה-reverse proxy.

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

האפליקציה, Authelia והפרוקסי חייבים לשתף לפחות רשת אחת. ראשית, בדקו אם כבר קיימת אחת:

docker network inspect proxy

אם עדיין לא יצרת אותו:

docker network create proxy

הוסף את הרשת כרשת חיצונית בקובץ Compose של היישום:

networks:
  proxy:
    external: true

לאחר מכן, צור מחדש את השירות:

docker compose up -d

מאותו רגע ואילך, הפרוקסי יוכל לאתר את האפליקציה באמצעות שם השירות או המכולה שלה:

http://mi-aplicacion:8080

אל תשתמש בכתובת ה-IP הפנימית שהוקצתה על ידי Docker מכיוון שהיא עשויה להשתנות בכל פעם שהקונטיינר נוצר מחדש.

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

כיצד ליצור מדיניות גישה של האפליקציה

המדיניות מוגדרת במקטע access_control מהקובץ configuration.ymlכדי לדרוש 2FA מכל המשתמשים הרשומים:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      policy: 'two_factor'

אם רק קבוצה אחת תורשה להיכנס:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      policy: 'two_factor'
      subject:
        - 'group:usuarios_app'

ניתן גם להגדיר רמות שונות:

• לְהַכּחִישׁ: חוסם גישה.
• לַעֲקוֹף: זה מאפשר גישה ללא צורך באימות.
• גורם_אחד: זה דורש שם משתמש וסיסמה.
• שני_גורמים: זה מוסיף גורם שני.

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

לְדוּגמָה:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      policy: 'two_factor'
      subject:
        - 'group:admins'

    - domain: '*.example.com'
      policy: 'one_factor'

במקרה זה, הפאנל דורש 2FA עבור מנהלים, והכלל הכללי מוחל לאחר מכן על שאר תת-הדומיינים.

אתה לא צריך להכריז על הפורטל. auth.example.com כְּמוֹ bypass אם מארח הפרוקסי שלך אינו משתמש באימות Authelia, אבטחת הפורטל באמצעות הרשאה משלך עלולה ליצור לולאת הפניה.

כיצד לבדוק את הגדרות Authelia

לפני הפעלה מחדש של השירות, יש לאמת את הקובץ:

docker exec authelia authelia config validate --config /config/configuration.yml

אם לא מופיעות שגיאות, הפעל מחדש את Authelia:

docker restart authelia

לאחר מכן, בדוק את הרישומים שלך:

docker logs --tail=200 authelia

שגיאות הזחה ב-YAML נפוצות. השתמשו ברווחים במקום בטאבים וודאו ש domain, policy y subject נמצאים בתוך אותו כלל.

כיצד לחבר את האפליקציה לפרוקסי ההפוך

ב-Nginx Proxy Manager, צור Proxy Host המצביע לשם הפנימי של המכולה:

• שמות דומיין: app.example.com
• תָכְנִית: http
• שם מארח/IP העברת קוד: mi-aplicacion
• יציאה קדימה: 8080
• תעודת SSL: תעודה תקפה עבור הדומיין
• כפיית SSL: מוּפעָל

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

include /snippets/authelia-location.conf;

location / {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://$server:$port;
}

קטע הקוד הנוכחי מבצע שאילתה על נקודת הקצה /api/authz/auth-requestאין לעשות שימוש חוזר בדוגמאות ישנות המבוססות על /api/verify.

אם עדיין לא הכנתם את הקבצים הללו, עיינו במדריך המלא עבור שלב את Authelia עם מנהל הפרוקסי של Nginx.

מה קורה עם פרטי ההתחברות של האפליקציה עצמה?

Forward Auth מחליט אם בקשה יכולה להגיע לאפליקציה, אך לא יוצר אוטומטית סשן בתוכה. לכן, שלושה מצבים יכולים להתרחש:

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

אם היישום תומך ב-OpenID Connect, בדרך כלל עדיף להשתמש באינטגרציה זו כדי להשיג כניסה יחידה אמיתיתאימות קדמי (Forward Auth) נותר שימושי עבור יישומים מדור קודם, לוחות מחוונים פשוטים או שירותים שאינם תומכים בספקי זהויות.

לדוגמה, ניתן להשתמש במערכת זו כדי הגן על Open WebUI באמצעות סיסמהעם זאת, האינטגרציה המתאימה ביותר תהיה תלויה בתכונות האימות הזמינות בגרסה המותקנת.

כיצד לעבוד עם ממשקי API, אפליקציות מובייל ו-WebSockets

ייתכן שאפליקציות מובייל וחלק מלקוחות שולחן העבודה לא יוכלו להציג את פורטל Authelia או לעקוב נכון אחר ההפניות שלו. במקרים אלה, אבטחת ה-API כולו באמצעות Forward Auth עלולה למנוע מהלקוח להתחבר.

האפשרויות הבטוחות ביותר הן:

• לְהִשְׁתַמֵשׁ OpenID Connect אם האפליקציה והלקוח מאפשרים זאת.
• שמור על אימות API מקורי.
• צור חריג המוגבל לנתיב ספציפי שיש לו הגנה משלו.
• השתמש ב-VPN כדי לגשת לשירות מבלי לפרסם אותו ישירות.

אל תכלול API שלם רק כדי להפעיל אפליקציה לנייד. אם עליך לאפשר webhook או בדיקת תקינות, הגבל את הכלל באמצעות... resources:

- domain: 'app.example.com'
  policy: 'bypass'
  resources:
    - '^/api/webhook/receive$'

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

אם האפליקציה משתמשת ב-WebSockets, הוסיפו אותה בתוך הבלוק שלכם. location:

include /snippets/websocket.conf;

בעת כתיבת בלוק location ייתכן שהפעלה ידנית של מתג תמיכת Websockets בכרטיסייה מתקדם של מנהל הפרוקסי של Nginx לא תשפיע.

למה כדאי להיזהר מעקיפת כתובות IP

ייתכן ש-Authelia יחיל מדיניות שונה בהתאם לרשת שממנה מגיע המשתמש. עם זאת, כללים אלה תלויים בכתובת הכלולה ב- X-Forwarded-For.

על הפרוקסי להסיר כל ערך שנשלח ישירות על ידי הלקוח ולהחליף אותו בכתובת האמיתית. אחרת, תוקף עלול... לזייף את כתובת ה-IP המקורית שלך כדי להתאים לרשת מורשית.

אל תגדיר גישה לא מאומתת עבור כל הרשת הביתית שלך עד שתאמת את הפעולות הבאות:

• רק פרוקסי מהימנים יכולים לשנות כותרות שהועברו.
• מנהל הפרוקסי של Nginx מזהה נכון את כתובת ה-IP האמיתית.
• Cloudflare או פרוקסי ביניים אחרים מוכרזים כאמינים.
• כותרת שמועברת מהאינטרנט אינה מפעילה את מדיניות העקיפה.

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

כיצד לוודא שהאפליקציה אכן מוגנת

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

ראשית, בדוק את הפורטים שפורסמו:

docker ps --format 'table {{.Names}}\t{{.Ports}}'

המכולה המוגנת לא אמורה להציג מיפוי כזה. 0.0.0.0:8080->8080/tcp.

לאחר מכן, בצעו את הבדיקות הבאות:

1. התנתק מ-Authelia או השתמש בחלון פרטי.
2. לִפְתוֹחַ https://app.example.com.
3. ודא שהדפדפן שלך מפנה אותך לפורטל.
4. ודא שהוא מבקש את רמת האימות שתצורתה נקבעה.
5. נסה עם משתמש שאינו שייך לקבוצה המורשית.
6. נסה לגשת אליו ישירות באמצעות כתובת ה-IP והפורט הישן.
7. סקירת מסלולים מותאמים אישית, ממשקי API, webhooks וחיבורי WebSocket.

ניתן גם לבדוק את התגובה מבלי להתחבר:

curl -I https://app.example.com

אתה אמור לקבל הפניה לפורטל Authelia, בדרך כלל באמצעות קוד HTTP 302.

חזור על בדיקות אלה לאחר עדכון Authelia, שינוי ה-proxy, שינוי מדיניות או הוספת מיקום מותאם אישית.

טעויות נפוצות בעת הגנה על אפליקציה עם Authelia

האפליקציה נשארת נגישה דרך כתובת IP.

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

מופיעה שגיאת 502 Bad Gateway

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

Authelia מציגה "גישה נדחתה" לאחר הכניסה

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

הדפדפן נכנס ללולאת הפניה

בדוק את השימוש ב-HTTPS, את דומיין העוגיות, authelia_url והכותרות המועברות על ידי הפרוקסי. כמו כן, בדוק שהפורטל אינו מוגן על ידי שלו auth_request.

האפליקציה מבקשת שוב שם משתמש וסיסמה.

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

האתר עובד, אבל האפליקציה לנייד לא מתחברת

סביר להניח שהלקוח אינו מסוגל לעקוב אחר ההפניה אל Authelia. בדוק אם הוא תומך ב-OIDC או שומר על אימות API מקורי מבלי להחיל חריגים רחבים מדי.

חלק מהפונקציות בזמן אמת מפסיקות להגיב

היישום משתמש ב-WebSockets, והפרוקסי אינו שומר את הכותרות הדרושות. זה כולל websocket.conf בתוך אותו בלוק מוגן.

מסלול מותאם אישית מאפשר כניסה ללא אימות.

מיקומים שנוצרו ממיקומים מותאמים אישית לא יורשים הרשאה. יש להצהיר עליהם בהגדרות מתקדמות ולכלול במפורש authelia-authrequest.conf.

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

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