פורט 5432: PostgreSQL

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

הדלת היחידה

כשPostgreSQL מתחיל, הוא נקשר לפורט 5432 וממתין. מספר הפורט עצמו הוא שרירותי — הוקצה על ידי IANA, ניתן לשינוי ב-postgresql.conf — אבל הוא אוניברסלי כמעט בכל ההתקנות. האוניברסליות הזאת הופכת אותו למטרה ידועה. כל מי שסורק רשת יודע בדיוק היכן לחפש.

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

מקומי לעומת מרוחק: שני עולמות שונים

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

חיבורים מקומיים — כשהלקוח רץ על אותה מכונה כמו מסד הנתונים — יכולים לעקוף את TCP לחלוטין. שקעי Unix domain מאפשרים לאפליקציות לדבר עם PostgreSQL מבלי לגעת בערימת הרשת. מהיר יותר, ומשטח תקיפה אחד פחות.

חיבורים מרוחקים חייבים להשתמש ב-TCP/IP. כברירת מחדל, PostgreSQL דוחה אותם לחלוטין. צריך לפתוח את הדלת באופן מפורש.

פתיחת הדלת דורשת שני שינויים:

1. postgresql.conf: הגדירו את listen_addresses כדי לציין על אילו ממשקים PostgreSQL מאזין. ברירת המחדל ('localhost') מקבלת רק חיבורים מקומיים. הגדרתה ל-'*' גורמת לו להאזין על כל הממשקים.

2. pg_hba.conf: הגדירו מי יכול להתחבר, למה, וכיצד הם מוכיחים שהם מורשים.

השינוי הראשון קובע האם PostgreSQL יכול לשמוע חיבורים מרוחקים. השני קובע האם הוא מאפשר להם להיכנס.

pg_hba.conf: השומר בדלת

הקובץ pg_hba.conf הוא רשימת בקרת הגישה של PostgreSQL. כל שורה היא כלל: סוג חיבור, מסד נתונים, משתמש, כתובת לקוח, שיטת אימות. PostgreSQL קורא את הכללים האלה מלמעלה למטה, ועוצר בהתאמה הראשונה.

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

ערך טיפוסי נראה כך:

hostssl  production  app_user  10.0.1.0/24  scram-sha-256

זה אומר: חיבורי SSL למסד הנתונים production מרשת 10.0.1.0/24, מאומתים כ-app_user עם scram-sha-256, מותרים.

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

• trust: ללא אימות. מסד הנתונים מאמין לכל מי שטוען שהוא מתחבר. לפיתוח בלבד.
• scram-sha-256: אימות סיסמה מודרני. הסיסמה לעולם לא עוברת בצורה שניתן לשחזר.
• cert: הלקוח מוכיח זהות עם תעודת SSL. אין סיסמה לגנוב, אין אישורים לפישינג.
• peer: לחיבורים מקומיים, מתאים את שם המשתמש של מערכת ההפעלה לשם המשתמש במסד הנתונים. אם מערכת ההפעלה אומרת שאתה "postgres", מסד הנתונים מאמין לה.

לסביבת ייצור, scram-sha-256 הוא המינימום. אימות תעודות עדיף כשאפשר לנהל את ה-PKI.

SSL/TLS: הצפנת הצינור

ללא SSL, כל מה שעובר על פורט 5432 עובר בטקסט פשוט. סיסמאות, שאילתות, תוצאות — קריאים לכל מי שיכול לראות את התעבורה.

הפעלת SSL דורשת תעודה ומפתח פרטי. חתום עצמי מתאים לפיתוח; ייצור צריך תעודות מרשות מהימנה.

הקובץ pg_hba.conf שולט בדרישות SSL דרך סוגי חיבורים:

• hostssl: דורש SSL. חיבורים לא מוצפנים נדחים.
• hostnossl: אוסר SSL. לעיתים נדירות שימושי.
• host: מקבל כל אחד מהשניים.

לחיבורים מרוחקים על כל רשת שאינכם שולטים בה לחלוטין, השתמשו ב-hostssl בלבד.

גם הלקוחות חייבים להיות מוגדרים. הפרמטר sslmode שולט במה שהלקוח דורש:

• disable: לעולם אל תשתמש ב-SSL.
• require: השתמש ב-SSL, אבל אל תאמת את התעודה.
• verify-full: השתמש ב-SSL, אמת שהתעודה מהימנה ותואמת לשם המארח של השרת.

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

הגנה לעומק

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

בידוד רשת: הציבו מסדי נתונים ברשתות פרטיות. גשו אליהם דרך VPN, מנהרות SSH, או שרתי מעבר. חומות האש צריכות לאפשר כתובות IP ספציפיות בלבד, לא טווחים.

אימות חזק: scram-sha-256 כמינימום, תעודות כשאפשר. לעולם אל תשמרו אישורי סופר-משתמש בקובצי התצורה של אפליקציות.

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

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

הגבלת קצב: חומות אש או כלים כמו fail2ban יכולים לחסום כתובות IP לאחר ניסיונות כושלים חוזרים. מתקפות brute-force נגד פורט 5432 נפוצות; הפכו אותן לחסרות תועלת.

מאגר חיבורים: PgBouncer

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

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

שלושה מצבי מאגר:

• Session: חיבור PostgreSQL אחד לכל סשן לקוח. תאימות מקסימלית, תועלת מאגר מינימלית.
• Transaction: חיבורים חוזרים למאגר אחרי כל טרנזקציה. יותר לקוחות משתפים פחות חיבורים, אבל תכונות ברמת סשן נשברות.
• Statement: חיבורים חוזרים אחרי כל פקודה. אגרסיבי אבל לא תואם עם טרנזקציות.

מצב Transaction הוא נקודת האיזון לרוב האפליקציות.

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

שאלות נפוצות על פורט 5432

האם אפשר לשנות את פורט ברירת המחדל של PostgreSQL?

כן, על ידי הגדרת port ב-postgresql.conf. כמה מנהלי מערכת עושים זאת בתור אבטחה על ידי הסתרה, אבל זה מספק הגנה מינימלית — סורקי פורטים מוצאים אותו ממילא. התמקדו באבטחה אמיתית: בידוד רשת, אימות חזק והצפנה.

מדוע PostgreSQL דוחה את החיבורים המרוחקים שלי?

שני מקומות לבדוק: listen_addresses ב-postgresql.conf חייב לכלול את הממשק שאתם מתחברים אליו (או '*' לכולם), וב-pg_hba.conf חייב להיות כלל התואם לסוג החיבור, מסד הנתונים, המשתמש וכתובת ה-IP המקורית. בדקו את שניהם, בסדר הזה.

האם להשתמש ב-md5 או ב-scram-sha-256 לאימות סיסמה?

scram-sha-256, תמיד. לאימות MD5 יש חולשות ידועות והוא נחשב מיושן. scram-sha-256 לעולם לא חושף את הסיסמה בצורה שניתן לשחזר, אפילו לא למי שמקליט את חילופי האימות.

האם SSL נחוץ לחיבורים מקומיים?

לא לחיבורי שקע Unix, שלעולם לא נוגעים ברשת. לחיבורי TCP ל-localhost, SSL אינו נחוץ מבחינה טכנית אבל לא פוגע. הדאגה האמיתית היא חיבורים מרוחקים, שם SSL חיוני.

מה ההבדל בין PgBouncer לבין מגבלות החיבור המובנות של PostgreSQL?

max_connections של PostgreSQL מגביל את סך החיבורים אבל לא יוצר מאגר — כל חיבור עדיין צורך משאבי שרת. PgBouncer מפחית את השימוש במשאבים על ידי שיתוף פחות חיבורי PostgreSQL אמיתיים בין לקוחות רבים. הם פותרים בעיות שונות ולעיתים קרובות עובדים יחד.