היכן הגנת ה-VPN מסתיימת בדרך לשרת FTP
VPN מכסה את הנתיב עד לשער שלו, לא את הקטע שאחריו. הפרידו בין FTP פשוט, FTPS ו-SFTP, ואז אמתו את ערוץ הנתונים ואת זהות הצד השני.
VPN מגן על נתיב, ולכל נתיב יש סוף. כאשר המנהרה מסתיימת בשער של חברה, העברת הקבצים ממשיכה משם תחת ההגנה שהפרוטוקול שלה עצמו מספק. ההבחנה הזו קובעת אם העברה מוגנת מקצה לקצה או רק עד השער. מחוון Connected לא אומר דבר על אף אחד מהשניים.
שני מיקומים, שני נתיבים שנותרו
קחו מחשב נייד שמצטרף ל-VPN של החברה ואז פותח הפעלת FTP לשרת פנימי נפרד. המנהרה נעצרת בשער, והקטע מהשער לשרת הזה נמצא מחוצה לה.
FTP פשוט לא מקבל הצפנה משום שהחבילות שלו הגיעו דרך מנהרה. בקטע שנותר הזה, הפקודות, פרטי ההתחברות ותוכן הקבצים עוברים בדיוק כפי שהפרוטוקול מגדיר, כלומר בגלוי. האם זה חשוב תלוי בטופולוגיה ובמה עוד מגן על הקטע, וקריאה לכתובת פרטית אינה עונה על השאלה. אותו היגיון חל גם בכיוון ההפוך כאשר השרת נמצא ברשת ענן שהשער מגיע אליה דרך קפיצה נוספת.
הניחו את נקודת הקצה של ה-VPN ואת שירות ה-FTP על מכונה אחת, ואין קטע נוסף לדאוג לגביו. זהו מיקום אחר, ולא הוכחה שהתהליכים, הקבצים ופרטי ההתחברות של המארח בטוחים.
FTP פשוט, FTPS ו-SFTP הם שלוש החלטות
FTP פשוט אינו מצפין דבר, כולל הסיסמה. FTPS מוסיף TLS ל-FTP, כך שערוץ הבקרה, וכאשר מנהלים על כך משא ומתן, ערוץ הנתונים מוגנים. SFTP הוא פרוטוקול אחר שנישא בתוך SSH, והוא אינו איות אחר של FTPS.
השרת חייב לתמוך בבחירה הזו, כי לקוח אינו יכול להמציא מאזין שאינו קיים. בחירת SFTP אינה הופכת שירות FTP בלבד לנקודת קצה SSH, ושינוי שם של סימנייה או שינוי פורט אינם מוכיחים דבר על מה שסוכם. אמתו את הפרוטוקול גם מצד השרת וגם מצד הלקוח. מנעול במנהל קבצים הוא טענה על ההפעלה, לא על המאזין שמאחוריה.
| Protocol | Usual port | What it protects | Identity check |
|---|---|---|---|
| FTP | 21 | Nothing on the wire | None beyond the login |
| FTPS | 21 or 990 | Control channel, data channel when required | TLS server certificate |
| SFTP | 22 | The whole session inside SSH | SSH host key |
קראו את העמודה האחרונה כשההעברה חשובה, כי שם מופיע שינוי זהות בלתי צפוי.
חיבור הנתונים הוא חיבור שני
FTP פותח חיבור בקרה ואז חיבורי נתונים נפרדים לרישומים ולהעברות. התחברות מוגנת אינה אומרת דבר על החיבורים המאוחרים האלה, אלא אם הפריסה דורשת הגנה גם עבורם.
ב-FTPS הלקוח מבקש ערוץ נתונים מוגן באמצעות פקודה מסוימת, ומדיניות השרת יכולה לסרב לחלופה הגלויה. אמתו שהמדיניות דורשת זאת במקום להניח שברירת המחדל של הלקוח מספיקה. מצב פסיבי מוסיף סיבוך שני, כי השרת מפרסם כתובת ופורט לחיבור הנתונים. חומת אש או התקן NAT שמשכתב או חוסם את הפרסום הזה יוצר הפעלה שמאמתת ואז נתקעת ברישום הראשון.
curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'הפקודה השנייה מראה מה השרת מציג בערוץ הבקרה לפני שנוגעים בקובץ כלשהו. השלישית מראה אם חיבור נתונים בכלל נוצר, וזה ההבדל בין כשל אימות לכשל במצב פסיבי.
בדיקות הזהות שורדות את המנהרה
לקוח FTPS מאמת זהות של שרת TLS, ולקוח SFTP מאמת מפתח מארח של SSH. שתי הבדיקות שייכות לפרוטוקול העברת הקבצים, ואף אחת מהן אינה מתבצעת על ידי ה-VPN.
ההפרדה הזו חשובה כשמשהו באמצע רוצה לבדוק את ההפעלה. כיבוי TLS כדי שהתקן רשת יוכל לקרוא את הפקודות משנה את מודל ההגנה במקום להשלים אותו, וכך גם קבלת מפתח מארח בלתי מוסבר משום שהמנהרה עלתה. שמרו על תצורת האמון המיועדת והשיגו את החומר הנכון מהמפעיל. מנהרה שמאמתת אינה אומרת דבר על השרת בקצה הרחוק שלה.
חומר המפתח הפרטי והתעודה עבור הפרוטוקולים האלה הוא סוד שלישי נוסף, נפרד מפרטי ההתחברות של ה-VPN.
רשמו מה באמת אימתתם
בחרו קובץ בלתי מזיק שמורשה לכם להעביר, ורשמו ארבע עובדות על הניסיון: איזה פרוטוקול רץ, איזו זהות של הצד השני נבדקה, איזה נתיב היה מיועד, והאם ההעברה הסתיימה.
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]רישום תיקייה, התחברות למנהרה והעברה שהסתיימה הם שלושה תצפיות נפרדות, ורק האחרונה אומרת שהנתיב עובד לקבצים. אם התכנון מסתמך רק על ה-VPN לסודיות בקפיצה שנותרה, כתבו זאת כהחלטה שהיא. הערת קבלה שמציינת את הקפיצה ואת הנחת האמון שלה שווה יותר מצילום מסך של לקוח מחובר.