הגדרת iptables - חלק 1
/var/www/html בפורט 80. המרצה בודק את מצב השירות ואת הפורטים שהוא מאזין להם.iptables -L -v.iptables -L -v מציג את החוקים עם פרטים נוספים, כולל כתובות ואינטרפייסים./etc/sysconfig/iptables שומר את החוקים, ו-service iptables reload טוען אותם מחדש.מבנה ושמות דיסקים ומחיצות בלינוקס:
הוכן ע"י התלמיד המצטיין: אברהים אבו שיכה
פרקי ההרצאה: הגדרת iptables - חלק 1
תמלול ההרצאה: הגדרת iptables - חלק 1
הטקסט המלא של הדקות הראשונות בהרצאה «הגדרת iptables - חלק 1» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום וברוכים הבאים לסרטון בנושא Firewall ולינוס. ה-Firewall הוא למעשה משמש את החזית של השרת מול הרשת החיצונית. מטרת ה-Firewall הוא לאפשר רק לתעבורה רצויה להיכנס ולצאת מהשרת.
היות שמדובר בעניינים של אבטחת מידע, ידע והבנה מעמיקים נדרשים מכל מנהל מערכת בתחום. הבנה מעמיקה בנושא ה-Firewall היא דרך טובה להראות את הידע וההבנה שלכם במערכת בגלל זה מרבים לשאול על הנושא הזה במבחנים ורעיונות.
בסרטון הקרוב שאנחנו הולכים לראות אנחנו נלמד על אופן הפעולה של הפיירוול על ההגדרה של הפיירוול נסרוק את ההגדרות הברירות מחדל במערכת נראה איך משנים את ההגדרה וגם נבחן את השינויים שאנחנו עושים אוקיי אז אז אם אין לפניכם דוגמה אני כרגע נמצא בשרת סרבר 1, והכנתי קובץ html פשוט אשר נמצא בעצם ב-httpd
בשרת וב של המערכת אשר מגישה את המסמכים האלה בפורט 80 כמו שאנחנו למעשה רגילים באינטרנט. נעשה עליו ls var www html קובץ קוראים index html אוקיי נעשה עליו cut יש בתוכו למעשה תוכן של אינטרנל אינפורמיישן.
הנתיב var www html / index html זהו הנתיב ברירת מחדל שבו המערכת שומרת את הקבצים שהשרת HTTPD מנגיש אוקיי. עכשיו אני הולך לבדוק את הסטטוס של השרת ServiceHTTPDStatus אוקיי.
הוא בעצם אומר לי שהשרת HTTPD רץ וה-PID שלו זה 2872. מעולה. אני הולך לבדוק בעזרת פקודת נטסטאט שהשרת אכן מאזין על פורט 80. פקודת נטסטאט מאפשרת לראות איזה אפליקציות מאזינות ומוכנות לקבל חיבורים ועל איזה פורטים.
כמו כן היא גם מאפשרת לראות איזה קונקשנים פתוחים באותו הרגע. כרגע אני הולך לבדוק על איזה פורטים מאזינות האפליקציות. אני מריץ נטסטאט מינוס t לתי סי פי אל ליסן n בשביל לראות את מספרי הפורטים וp שיציג גם את הפרוגרם את התוכנה שמאזינה והנה כאן אני יכול לראות שהHTTPD מאזין על הפורט עכשיו אני הולך לבדוק
את המצב של הפיירוול מה שמספק את שירותי הפיירוול בלינוקס זוהי בעצם טכנולוגיה שנקראת IPTables שהיא מובנית בתוך המערכת. אני אריץ Service IPTables Status וכרגע הפיירוול איננו מאופשר.
עכשיו אני הולך להיכנס בעזרת דפדפן האינטרנט אל הכתובת של השרת. אני אבדוק רגע את הכתובת של השרת ifconfig כתובת של השרת היא 192 168 1 5. אני פותח את הבראוזר ונכנס לכתובת הזאתי 192 178 1 5 ואני רואה את התוכן של הקובץ index.html כרגע התוכן הזה בעצם נגיש לכולם כל מי שיחבר לשרת יוכל לראות אותו.
אוקיי, כרגע אני הולך להפעיל את ה-IPTables, where this IPTables star, אוקיי, בעצם הוא טען את החוקים של ה-firewall, כרגע החוקים של ה-firewall אינם מאפשרים לראות את התוכן הזה, ועכשיו אני הולך בעצם להיכנס, לנסות להיכנס עוד פעם, אני רואה כאן שהוא מנסה להתחבר ולא מצליח ואם אני אפתח מחדש את הדפדפן ונקבל טוב את
זאת. פה אני אראה שהוא לא מצליח להתחבר וגם התוכן לא יוצג. הסיבה לכך היא למעשה שהfirewall הוא חסם את הגישה שלי לשרת ה-HTTP.
אוקיי, בעצם, ולא מאפשר לתעבורה בפורט 80 לעבור. אוקיי, עכשיו אני יכול לראות את הסטטוס של הפיירוול, ופה הוא בעצם מציג לי את מה שהולך בפיירוול.
אבל לפני זה, בואו נסביר רגע איך הפיירוול בלינוקס מתפקד, אוקיי? מה שקורה זה שבעצם מגיע פאקט לשרת, הנה הפאקט שלנו.
עכשיו, איך שהוא מגיע לתוך המנגנון של הפיירוול הוא עובר בעצם מספר בדיקות אחת אחרי השנייה. את הבדיקות אנחנו קובעים. למשל הוא יכול לעבור בדיקה האם מדובר בפרוטוקול של SSH זהו בעצם סקיור של שדרכו אנחנו מתחברים למערכת בפורט 22 הוא עובד.
האם בעצם מדובר בפרוטוקול של Web של HTTP שעובר בפורט 80 או האם לצורך העניין מדובר בפרוטוקול של FTP שעובר בפורט 21. כל בדיקה כזאת במידה והפאקט מתאים לבדיקה יכולה להיות לה תוצאה שהתוצאה יכולה להיות בעצם בשלב הזה.
נסביר על שתי תוצאות אפשריות, יכולה להיות או בעצם קבלת הפאקט, כן, או לצורך העניין זריקת הפאקט מהמערכת מחיקה. עכשיו, הבדיקות האלה מסודרות בשרשרת, כלומר הן נבדקות אחת אחרי השנייה, ולסט של הבדיקות האלה קוראים צ'יין.
אז בעצם מה שקורה זה שהפאקט שלנו עובר את הבדיקות האלה. כאשר הפאקט מתקבל, אז הוא מתקבל למערכת ומגיע פנימה.
גם אם בבדיקות אחרות הוא היה נכשל, כלומר נגיד אם זה הפאקט של SSH והתנאי אומר שאם הפאקט הוא פאקט של SSH אז קבל אותו למערכת, אז הפאקט היה מתקבל למערכת גם אם לצורך העניין פה אנחנו בודקים אם הוא HTTP או FTP או לצורך העניין אם הפאקט היה מגיע בעצם למערכת וכתוצאה
של בדיקת HTTP הוא היה מתאים ל-HTTP והיה בעצם נזרק מהמערכת. אז גם אם לצורך העניין פה בבדיקה הבאה אני כן הפאקט היה עובר אותה נגיד שפה בהמשך יש לנו עוד בדיקה שדווקא מתייחסת למקור של הפאקט יש לנו פה בדיקה שמתייחסת למקור של הפאקט האם הפאקט הגיע מהרשת הפנימית נגיד ואת הבדיקה הזאתי הפאקט של ה-HTTP כן היה עובר.
ונזרק כתוצאה מזה שהוא עבר את הבדיקה הזאתי, כן, אז הוא אפילו לא יגיע להמשך השרשרת לבדיקות נוספות. כלומר, המסלול שהפאקט יעשה בתוך השרשרת הוא בעצם כזה ויזרק.
אם הייתי רוצה לקבל את כל הפאקטים שמגיעים מהתעבורה הפנימית, הייתי צריך לשים את הבדיקה של מקור הפאקט למעשה בתחילת השרשרת כאן. טוב, אבל די עם התיאוריה, בואו נעבור לפרקטיקה, נראה תכלס איך זה מיושם בהגדרות ושם הנושא הזה מובן הרבה יותר.
אז ברגע שאני בעצם מעביר את הפקודה של Service IP Table Status, אני מקבל את הסטטוס של השירות וכאן יש לי מספר צ'יינים, מספר שרשרות בדיקה.
זהו האינפוט צ'יין, כלומר פאקטים שמגיעים לשרת, פאקטים שמגיעים לשרת מבחוץ, מהאינטרנט, מהרשת, מכל מקום אחר.
זהו ה-output צ'יין. ה-output chain זה בעצם התעבורה שיוצאת מהשרת. אתם תשאלו מתי שימושי להשתמש בחוקים ב-output chain ואני אגיד לכם למשל אם אתם רוצים שהשירותים שעל השרת בעצם יאפשרו רק לצאת לשירות של HTTP או רק לשירות של FTP, למשל אתם רוצים להגביל את היוזרים של
לצאת החוצה רק בשירותים מסוימים, אפשר להוסיף חוקים גם ל-output chain ולחסום יציאה של פאקטים השרתים. וה-forward chain הוא למעשה נועד למקרים כאלה שהשרת שלנו משמש כראוטר ועושה הפניה של פאקטים עבור שרתים אחרים אז למשל אני רוצה להגביל שירות מסוים שלא יעבור דרך השרת שלי או להגביל מקורות
מסוימים שלא יעברו דרך השרת שלי אז אני יכול לעשות את זה בעזרת הוספת חוקים ל-forward chain. אז בואו נבחן בעצם מה יש לנו בתוך הטבלה הזאתי יש לנו את המספר של החוק יש לנו את מה שיקרה אם החוק יענה על הבדיקה הזאתי יש לנו את הפרוטוקול זה כל הפרוטוקולים tcp udp icmp וכדומה יש לנו את
הסורס מאיפה הגיע הפאקט ולאיפה הוא מיועד האפס אפס אפס סלאש אפס היא בעצם תבנית שמתאימה לכל המקרים. בואו נבחן איזה חוקים כרגע מופעלים לנו בפיירוול.
חוק מספר ראשון אומר אקספט לקבל את כל הפרוטוקולים מכל מקור וכל יעד. עכשיו בתנאי שהקונקשן הוא או established, כלומר ה-Connection הוא כבר פעיל, למשל אם יש לי חיבור פעיל ב-SSH ואנחנו תכף נדבר ונעמיק במקרה הזה, אם החיבור כבר נוצר אז אני אמשיך להעביר את הפקטות של אותו חיבור.
או Related, ה-Related למשל קשור לתעבורת UDP כמו DNS שלמשל אני אני שולח request ומקבל רספונס ב- UDP אוקיי ב- UDP אין לנו בעצם קונקשן של לינק התקשורת היא לא דו-כיוונית בכל רגע נתון אלא התקשורת היא חד-כיוונית כלומר שצד אחד שולח ב- UDP אחרי זה צד שני שולח בחזרה ופה בעצם נכנס לתמונה ה-related כלומר אם התשדורת המתקבלת היא
באה כתגובה לתשדורת שיצאה מהשארה. אז בעצם החוק הראשון אומר שאם כבר קיים קונקשן אז אל תתערב תקבל אותו.
החוק השני אומר תקבל את כל תעבורת ICMP. החוק השלישי אומר קבל את כל התעבורה מכל הכתובות לכל הכתובות. עכשיו פה בעצם אומרים אוקיי אז למה למה החוק הזה טוב ופה למעשה בדף הזה לא מוצג כל המידע ואם אני בעצם מבקש מהמערכת מידע יותר מפורט על ידי הפקודה IP IP tables -l -v, אוקיי?
אז אני אראה בעצם שהחוק הזה השלישי של לקבל מידע מכל מקום לכל מקום הוא בעצם מוגבל רק לכרטיס רשת המקומי ללופבק אינטרפייס. הלופבק אינטרפייס הוא בעצם אינטרפייס שמשמש לתקשורת הפנימית של האפליקציות בתוך השרת יש לו כתובת IP קבועה פנימית של 127.001 שזאתי בעצם הכתובת הקבועה בכל שרת לתקשורת הפנימית שלו.
אז מה שהחוק הזה אומר זה שבעצם הפיירוול לא יסנן את התקשורת הפנימית. אוקיי? עכשיו כאן יש לי חוק שאומר בעצם accept תקבל תעבורת tcp מכל מקום לכל מקום עכשיו כאן אומר בתנאי שהתעבורה היא חדשה כלומר יצירה של קונקשן מסוג tcp בפרוטוקול ssh כלומר פורט 22. כלומר התנאי הזה הוא יאפשר לחיבור חדש של SSH להיווצר ואחרי שהחיבור הזה ייווצר התנאי הראשון יפעל שכל קונקשן
שהוא כבר קיים ופתוח הוא בעצם ימשיך לעבוד. ויש לנו פה את התנאי האחרון שאומר בעצם כזה דבר, שאומר תדחה כל בקשה מכל מקום לכל מקום עם הודעה של אסור להתחבר ICMP רהיבטד אומר שהחיבור אסור.
אז בואו נבחן למעשה בצורה גרפית את ההגדרות שיש לנו אוקיי אז ככה מגיע אלינו פאקט למערכת הנה הפאקט שלנו אז קודם כל אנחנו בודקים אם מדובר בתקשורת שהיא כבר קיימת אקזיסטינג אם מדובר בתקשורת שהיא כבר קיימת כן כמו למשל קונקשן של ssh שהוא פתוח אוקיי אז במקרה הזה אני מאפשר
לתקשורת להתקיים והפאקט עובר אל ייעודו בשלב, אוקיי? שלב שני שאני בודק, האם מדובר בתעבורת ICMP, ואם מדובר בתעבורת ICMP, אני גם כן מקבל את הפאקט הזה ומאפשר לו להגיע על השרת חוק השלישי אומר בעצם תקבל הכל מכרטיס
רשת מקומי מהלובק אינטרפייס ותאפשר לו להגיע אל יהודו והחוק השני וגם הוא מאפשר לפאקט להגיע החוק הרביעי אומר כזה דבר שאם נוצר קונקשן חדש של SSH אז תאפשר ליצור את הקונקשן הזה והוא הולך חדש פלוס SH. והתוצאה הולכת להיות שהקונקשן יתקבל במקרה הזה ולמעשה יש לי גם תנאי אחרון שהוא אומר כל השאר מכל המקומות, נעשה פה all ומה שיקרה פה הוא בעצם יזרוק
את כל הפקטות שהגיעו לשלב הזה בבדיקה. אז ככה נראה ה-chain שלי. בואו נראה מה קורה כשאני מנסה להתחבר כרגע בדרך הבראוזר בפרוטוקול של HTTP. הפאקט של ה-HTTP מגיע.
האם מדובר בתקשורת קיימת? לא, לא מדובר בתקשורת קיימת, לכן הפאקט ממשיך הלאה בתוך ה-chain. האם מדובר בתקשורת ICMP?
לא, הפאקט ממשיך הלאה. האם מדובר בתקשורת שבאה מהלובבק אינטרפייס? גם לא, הפאקט ממשיך הלאה. אם מדובר בקונקשן חדש כן, קונקשן חדש של SSH לא, אז הפאקט ממשיך הלאה ולמעשה הפאקט הזה של ה-HTTP יעבור דרך כל השרשרת ובסוף ימצא את עצמו בתוך הפח ולא יגיע למערכת.
עכשיו, מה אני צריך לעשות בשביל שהפאקט הזה של ה-HTTP יתקבל? אני צריך להוסיף כאן בעצם עוד תנאי, שאומר שאם הפאקט הזה הוא של HTTP אז אני מקבל אותו.
שימו לב שאם אני אוסיף את התנאי הזה בצורה שגויה, אם אני אוסיף אותו בסוף השרשרת אז לא משנה מה התנאי של כל הפאקטים האחרון הוא יזרוק את כל התעבורה לפח ולא משנה כבר מה יהיה אחריו.
אז בואו נבחן את קובץ ההגדרות כפי שהוא כפי שהוא קיים במערכת. אוקיי? בי איי טי סי פיס קונפיק איי פי טייבלס אוקיי?
כאן כאן בעצם אנחנו רואים את ההגדרות את ההגדרות של הצ'יינים שלנו של אינפוט פורוורד ואוטפוט כאשר הדיפולט פוליסים, כלומר ברת המחדל שלהם, הם ריקים ואין בהם שום תנאים מ-Accept, כלומר אם אני לא אייאש את הצ'יין הזה, את השרשרת הזאתי, למעשה הצ'יין מוגדר לקבל את הפקטות, וכאן אני רואה את
ההגדרות שכרגע פעילות בשרת. למשל כאן יש את ההגדרה שמאפשרת לתעבורה שהיא כבר קיימת, זאת בעצם ההגדרה שמאפשרת תעבורה ל-ICMP. מה זה אומר בעצם? מינוס A זה אומר שאני מוסיף הגדרה, מוסיף בדיקה כזאת.
אחרי זה הולך בעצם שם השרשרת, שם ה-chain. אחרי זה P, בעצם זה עבור הפטלו, פרוטוקול. ו-J אומר מה לעשות במידה והתנאי הזה מתגשם, כלומר, אני מוסיף לצ'יין של אינפוט כל מה שהוא בפרוטוקול ICMP תקבל אותו אוקיי כאן באותה דוגמא רק שכאן בעצם משתמשים באות I קיצור של אינטרפייס LO מסמן לופבק באותה מידה זה אחר היה להיות גם
נגיד תרוצה לקבל את כל מה שמגיע מכרטיס רשת מסוים הייתי רושם פה את השם של הכרטיס רשת ETH0 ETH1 וכדומה וגם מה לעשות אקסלט אוקיי עכשיו כאן יש לנו תנאי מעניין input M זה אומר match תתאים לפי state לפי המצב של החיבור אם הstate הוא new כלומר מנסים ליצור חיבור חדש וגם match מתאים לtcp בפרוטוקול tcp עם דיסטניישן פורט די פורט
דיזר שטו של דיסטניישן 22 שזה הפורט של ssh אז בעצם אני קופץ jjump ל-accept ומקבל את הפקטה אוקיי עכשיו יש לנו פה את התנאי האחרון