מבוא:

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

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

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

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

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

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

המשמעות היא שאם השרת שלנו נמצא במקום שבו תשתית החשמל רעועה – אי אפשר לצפות שהוא יהיה זמין יותר מזמינות החשמל אליו.

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

כמובן שזהו אינו חלק מהסקופ של מסמך זה ולכן, נניח שהתנאים הסביבתיים שבהם "חי" השרת שלנו, טובים.

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

קיימים שלושה יסודות שנרצה לקיים – וזאת  עוד לפני שאנו דנים בעצם השירות :

1. מי יגיע לקבצים שהשרת שלנו מספק / מי יגיע לשירות שהשרת שלנו מספק – או במילים אחרות: סודיות המידע שמצוי על השרת שלנו. אנו נרצה כי רק מי שאנו נתיר לו יגיע ויקבל את השירות – אפשר לתאר זאת כ"סודיות המידע" .

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

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

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

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

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

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

הליך ההתקנה

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

ההתקנה במערכת לינוקס יכולה להתבצע במספר שיטות שונות וממספר מקורות שונים .

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

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

על מנת לוודא שאכן התקליטור שבידינו ואלידי, נצטרך להשוות את ה MD5 המסופק ע"י המפיץ / יצרן ל MD5 שנפיק מהתקליטור , או שיותר נכון מקובץ ה ISO שלו .

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

מן הסתם על מערכת windows יש כלים לביצוע של פרוצדורה דומה, אולם מכיון שאנו עוסקים בלינוקס (ואלי בעיקר בגלל שהכותב משתמש רק בלינוקס) , נעשה זאת על מערכת לינוקס .

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

על מנת להפוך תקליטור או DVD לקובץ ISO , פשוט נוודא שיש לנו מספיק מקום בתיקיה שבה אנו רוצים (או במחיצה) לבצע את ההליך, המקום הנדרש הינו כגודל המידע על התקליטור. נהפוך את התקליטור ל ISO image בצורה הבאה (בעזרת הפקודה dd ) :

dd if=/dev/cdrom of=/path/to/file.iso

במרבית המחשבים / שרתים , הקובץ cdrom או dvd תחת התיקיה dev הינו לינק סימבולי לשם ההתקן האמיתי.

בשלב הזה יהיה בידינו קובץ ה ISO של התקליטור ומה נצטרך לעשות עתה הוא להוציא ממנו את ה MD5 שלו בצורה הבאה (התהלך לוקח מעט זמן ):

md5sum file.iso

לדוגמה:

$ md5sum /data/cp.iso

f46c515aae576121934bd2a58537a49c /data/cp.iso

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

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

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

שלבי ההתקנה.

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

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

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

בתהליך ההתקנה כדאי להקפיד על מספר דברים :

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

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

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

/proc/sys/net/ipv4/ip_forwared

יכיל את הסיפרה "0” יש לוודא מייד לאחר ההתקנה שאכן הקובץ מכיל את הסיפרה "0”. בעיקר אם אנו מתקינים הפצה לא מוכרת ועל אחת כמה וכמה אם יש על המערכת שלנו יותר מכרטיס רשת יחיד (בהמשך ולאחר שנבין מה ההגדרה הזו עושה נוכל לשים בקובץ ערך אחר).

2. הגדרת סיסמה לחשבון root – החשבון root במערכות Unix/Linux הינו חשבון ללא שום הגבלה.      יש האומרים שהוא מקביל לחשבון Administrator בסביבת Microsoft windows , הדבר אינו נכון. חשבון Administrator בסביבת windows הוא חשבון מוגבל. הוא אינו יכול לעשות "הכל" במערכת. מצד שני החשבון root אינו חשבון מוגבל והוא יכול לעשות הכל במערכת. לכן, קיימת חשיבות גדולה בהגנה על חשבון זה ואנו נצטרך להגדיר לו סיסמה איכותית ולא סתם מילה או סיסמה קלה אחרת לניחוש. יש להקפיד שהסיסמה תהיה לכל הפחות באורך של 8 תווים ותערבב בתוכה את כל סוגי התווים, ללא ציון תאריכים, ללא שמות, ואקראית .

3. הגדרת מחיצות- בעולם של מערכות windows תהיה בדרך כלל מחיצה אחת, אשר תאופיין ע"י האות "C” , העולם ה Unix/Linux , לאורך שנים, דגלו בשימוש במספר מחיצות, חלקן כתוצאה מצורך ואילוץ וחלקן כתוצאה מרצון.

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

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

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

במערכות Linux , מחיצה הינה שטח שמוקצה על הדיסק. אותו שטח מבצע mount לתיקיה (בדרך כלל ריקה) במערכת, כך שלמעשה כאשר אנו נכנסים אל אותה תיקיה, אנו בעצם עוברים למחיצה אחרת.

בצורה הזו, לינוקס בעצם מציגה למשתמש "עץ ספריות יחיד", גם כאשר יש במערכת מספר רב של מחיצות (בשונה ממערכות windows לדוגמה שבהן כל מחיצה מאופיינת ע"י אות כונן .. C,D וכן הלאה) .

מחיצות זמניות, או מערכות קבצים זמניות, נוהגות באותה צורה ממש באופן כזה שאנו נראה תחת התיקיה media (בעבר היה שימוש ב mnt ) תתי תקיות היכולות להכיל מערכות קבצים זמניות (Disk on key , תקליטורים , או שיתופי רשת ),אבל מעבר לתיקיה media ניתן לחלק את המערכת עצמה למחיצות.

כך לדוגמה, אם נתקין שרת עם שני מחיצות, המחיצה הראשית תבצע mount בתיקיה הראשית (כלומר / ) והמחיצה השניה תבצע mount תחת התיקייה /boot . המשמעות היא שעל המחיצה הראשית תהיה התיקיה boot בתור תיקיה ריקה ובעת האיתחול יתבצע mount של המחיצה השניה לתיקיה boot וכאשר אנו נעבור אל התיקיה boot תוך כדי עבודה, אנו למעשה נעבור למחיצה אחרת. כמובן שמדובר רק בדוגמה, אך בפועל, ניתן להקים בצורה הזו מערכת עם מספר רב של מחיצות (ולא מחיצה אחת ) .

בדרך כלל המחיצה הראשית (שאינה חייבת להיות המחיצה הגדולה) תופיעה בתור המחיצה / .

מחיצה נוספת הינה ה swap partition , מחיצה אשר משמשת כ virtual memory ומסייעת לפעילות הזיכרון (מחיצה זו אינה מבצעת mount אל תוך המערכת ) .

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

התיקיה boot יכולה להיות על מחיצה משל עצמה, התיקיה home יכולה להיות במחיצה משל עצמה, כך גם התיקיות /usr , /usr/local , /var, /tmp, /opt והמחיצה /srv (במידה וקיימת בהפצה שאנו מתקינים) .

לא נוכל לשים את התיקיות /bin, /sbin, /etc,/dev, /lib,/proc ו - /sys על מחיצות אחרות .

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

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

בדרך כל ניתן להפעיל קובץ בינארי או סקריפט מכל מחיצה, אולם ייתכן שלא נרצה שמשתמשים יורידו ויפעילו קבצים בינאריים או סקריפטים ממקומות "זרים" ונוסיף את המאפיין noexec למחיצות home ו- tmp , למעשה קובץ שיש לו הרשאת הרצה ונמצא על מחיצות אלו, לא יוכל להיות מורץ .

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

עד עתה לא עסקנו כלל בשאלה "מה השרת הזה אמור לעשות? “ ויש סיבות טובות להתחיל לשאול את השאלה הזו. אם אנו לא יודעים את התשובה עליה, אחת הסיבות היא שהסכמה של המחיצות עשויה להיות שונה משרת אחד לשני, כלומר: אם אנו מקימים שרת web יכול להיות שיש חשיבות מסויימת לבנות את המחיצה שבה ישנם הקבצים הציבוריים (או שהגולשים רואים) בצורה מסויימת ואם מצד שני אנו בונים שרת קבצים, ייתכן שיש חשיבות לקיומה של מחיצה אחרת כלשהיא.

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

ככל שמקל הוא קצר יותר – כך גם קשה יותר לשבור אותו (או מנגד ככל שמקל ארוך יותר, יש עליו יותר נקודות שבירה) .

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

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

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

למעשה (וכרגע אני מתייחס להפצות הלינוקס המבוססות על Red Hat ו- SuSE , כלומר Red Hat, Centos, Fedora, Oracle, SuSE, OpenSuSE ו- OES ) בחירת חבילות התוכנה מחולקת ל"משפחות" של חבילות , לדוגמה המשפחה "Servers “ כוללת בתוכה שרתים שונים, המשפחה " Gnome “ כוללת בתוכה חבילות שונות השייכות ל Gnome (סביבת Desktop ), כאשר אנו בוחרים בהתקנה של "משפחת חבילות מסויימת" תהליך ההתקנה מסמן לעצמו את כל חבילות הבסיס השייכות לאותה משפחה ומאפשר לנו לבחור בעוד כמה עשרות חבילות שהינן "אופציונאליות" באותה משפחת חבילות.

למעשה, אפשר ישר לקצר את כל העיניין להגיע לשורה התחתונה. עלינו להסיר את הסימונים מכל המשפחות של החבילות על מנת שתותקן המערכת המינימאלית האפשרית (בגרסאות בעבר ובחלק מההפצות כיום יש אופציה לבחור minimal installation – אם אופציה זו קיימת, אפשר לבחור בה. אם היא אינה קיימת בהפצה שלכם, יש להסיר את הסימון מכל המשפחות של החבילות ).

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

ובכל זאת, גם אחרי שוויתרנו על כל מה שאפשרי בתהליך ההתקנה, עדיין נמצ את עצמנו עם מערכת שיש בה כ 400-500 חבילות תוכנה בסיסיות (כמו שהגדיר המפיץ ), יש שוני מהפצה להפצה, אך זה בערך סכום החבילות .

בדרך כלל בתהליך ההתקנה לא נוכל להוריד יותר חבילות, אולם אחד הדברים הראשונים שנעשה לאחר ההתקנה – הוא להוריד את כמות החבילות מ 400-500 עד ל 100-150 ..

יודגש : יש להסיר את כל ה"משפחות חבילות" ובוודאי משפחות כגון Software Development השרת שלנו אינו "מכונת פיתוח" ואין שום סיבה שבעולם שחבילות פיתוח ו/או כלי פיתוח יותקנו עליו (נהפוך הוא ), גם אם אנו יודעים שהשרת שלנו הולך להיות שרת Web אנחנו נסיר את הסימונים על משפחת החבילות " Web Server “. אם אכן נצטרך אותן נוכל להתקין אותן מאוחר יותר ובצורה אחראית יותר.

חשוב לזכור , המוטו שלנו בשלב הזה הוא שככל שמקל הוא קצר יותר – יהיה קשה יותר לשבור אותו .

לאחר ההתקנה

first boot - לאחר ביצוע ההתקנה מייד תעלה המערכת במצב של first boot (הדבר נכון להפצות ממשפחת Red Hat ). במצב זה המערכת תסייע לנו להגדיר ולכוון מספר דברים בסיסיים ולאחר שנגדיר אותם המערכת תבצע שוב reboot .

במצב של First Boot , המערכת תשאל אותנו לגביי נושא של Firewall . במערכת לינוקס קיים בצורה מובנת Firewall הקרוי NetFilter והינו חלק אינטגרלי מה kernel של המערכת. את החוקים ניתן לקבוע בעזרת הפקודה iptables וזה בדיוק מה שכרגע רץ ברקע .

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

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

הדבר השני שבו נעצר הוא המסך של SELinux . קצרה היריעה מלהתחיל להסביר במסמך זה מהו Selinux ואת ההבדלים בין DAC ל- MAC . על רגל אחת ניתן לומר ש SELinux “שובר" את מבנה בקרת הגישה למידע בתוך מערכת ההפעלה ומאפשר בקרת גישה מבוקרת יותר. בעברית פשוטה ניתן לומר שמכניזם שכזה, “שובר" את מה שאנו מכירים מההרשאות הסטנדרטיות ומאפשר בניה של מערכת בקרת גישה עם בקרה ומניעת גישה ברמות גבוהות יותר (רמות הנדרשות במערכות צבאיות או מערכות ממשל סודיות).

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

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

מסך של Kdump – הגדרה של שרת שניתן לעבוד מולו על מנת לבצע dump של המערכת (נדרש בעיתות של תקלות מסובכות ) .

הגדרת Software Update – הגדרה של שרת שמולו אנו עושים את ה update למערכת שלנו .

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

הפסקת קפה :

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

סגירה / הקשחה של איתחול המערכת :

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

חלק מהגנה פיסית זו, היא הגנה על תהליך איתחול המערכת .

למעשה, במערכת שלא בוצעה בה הגנה שכזו, ניתן יהיה לאתחל את המערכת למערכת העובדת מ live cd ולבצע mount אליה , של המחיצות על הכונן הקשיח – במצב שכזה המידע הקיים על הכונן יהיה זמין וניתן יהיה לשנותו.

ולכן, על מנת להגן על איתחול המערכת, יש מספר דברים שעלינו לעשות :

1. הגנה על ה BIOS . נקבע שמבחינת ה BIOS ההתקן ממנו מתבצע האיתחול של המערכת הוא הכונן הקשיח בלבד, כמו כן נשתמש בסיסמה על מנת להגן על ה BIOS .
2. הגנה על ה boot loader. מנהל האיתחול, הוא זה המספק לנו תפריט בחירה באיתחול המערכת. כיום משתמשים ב Grub כמנהל איתחול. למעשה אפשרי להעביר בתוך ה grub פרמטרים שונים לאיתחול ובכך לעקוף את האיתחול הסטנדרטי של המערכת. על מנת למנוע "עקיפה" שכזו נשתמש במנהל איתחול מוגן סיסמה, כך שאם מישהו ירצה להכניס פרמטרים כלשהם למנהל האיתחול הוא יצטרך קודם לכן להקיש את הסיסמה הנכונה. על מנת לעשות זאת נשתמש בפקודה grub-md5-crypt בצורה הבאה:

$ grub-md5-crypt

Password:

Retype password:

$1$Iaxe4/$COUO6bzlntgtaQadI6tai1

את התוצאה נעתיק. ונדביק לתוך הקובץ boot/grub/menu.lst (או /boot/grub/grub.conf שזה אותו קובץ) . ונוסיף לפני ההדבקה את ההגדרה:

password –md5 <string>

במקום הערך <string> נכניס את הפלט של הפקודה grub-md5-crypt .

3. בשלב השלישי, נגן על תהליך ה init , ע"י הוספה בקובץ /etc/inittab של הפעלת suloging (תוכנית) ברמות הריצה שאינן רמות הריצה שבברירת המחדל של המערכת שלנו .

לדוגמה : במערכת לינוקס ניתן לבצע local login במצב שנקרא single user , מצב זה נועד על מנת לתקן בעיות שונות במערכת. למעשה במצב הזה, אנו עוקפים את מנגנון האיתחול הסטנדרטי(ברירת המחדל של init ) כך שאפילו ה PAM (שמספק את תהליך האוטנטיקציה) אינו פעיל, כך שלמעשה אנחנו מקבלים גישת root למערכת ללא צורך בשום סיסמה (המצב הזה אפשרי רק אם נמצאים פיסית על השרת ואינו אפשרי דרך הרשת – ולכן חשיבות גדולה על ההגנה הפיסית של השרת) .

על מנת למנוע מצב זה (ויש לחשוב לפני האם כדאי או לא כדאי) , ניתן להוסיף לקובץ inittab את השורה הבאה:

~~:S:wait:/sbin/sulogin

הסרה של חבילות שאינן הכרחיות:

כמו שכבר כתבתי, יש עתה במערכת כ 400-500 חבילות לערך. הפקודה rpm -qa|wc -l תציג לכם את מספר החבילות הקיימות.

בעזרת הפקודה rpm -qa נוכל לראות את רשימת החבילות, כאשר על כל חבילה נוכל להריץ את הפקודה rpm -e package_name על מנת להסירה.

אולם כדי שלא להסיר חביות בסיס הכרחיות, נצטרך להריץ את הפקודה rpm -qi package_name על מנת לקבל מידע על החבילה, ו – rpm -ql package_name על מנת לראות את הקבצים השייכים לה .

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

** הנספח בסוף מדריך זה מראה רשימה לדוגמה של חבילות שאפשר להשאיר על שרת. רשימת בסיס זו היא בערך מה שצריך להגיע אליו.

עידכון חבילות:

עכשיו נשארו במערכת רק החבילות ההכרחיותץ בשלב הזה נחבר את הרשת (אם לא עשינו זאת עד עתה) ונפעיל את שרותי העידכון .

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

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

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

על מנת לייבא את המפתח נוכל להשתמש בפקודה rpm –import /path/to/the/PGP-KEY

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

יש חשיבות גדולה מאד על שמירה של עדכניות השרת .

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

במערכות מבוססות דביאן ניתן לעשות זאת עם apt במערכות מבוססות Red Hat ניתן לעשות זאת עם yum ובמערכות מבוססות SuSE ניתן לעשות זאת עם YaST .

בדיקת שרותי רשת :

בשלב הזה נוכל לבדוק איזה שרותים רצים במערכת ע"י הפקודה chkconfig –list (או פקודה מקבילה בהפצות אחרות ). אמורים להיות מספר שרותים מקומיים פעילים .

מצד שני נוכל לבדוק את הפלט של netstat -Na או netstat -Nap . לא אמורים להיות שרותי רשת שהמערכת מאזינה להם, למעט ssh אם בחרתם כבר להתקין שירות זה .

הקשחת מערכת הקבצים /טיפול במחיצות:

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

את המידע הקיים, מבחינת המחיצות הקיימות, ניתן לראות באמצעות הפקודה mount והמקום לשנות את הפרמטרים השונים והמאפיינים השונים הוא באמצעות שינוי של הקובץ fstab המצוי ב etc .

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

ההגדרה defaults מגדירה (בהפצות מבוססות Red Hat ) את המאפיינים הבאים : auto, nouser, async, rw, suid, dev, exec בדרך כלל נרצה להוסיף או לשנות את exec לערך noexec . המשמעות היא שבמחיצה שבה מופעל noexec לא ניתן להריץ קבצים בינאריים או קבצי הרצה. במחיצות אחרות נרצה להפעיל את המאפיין nodev . המשמעות היא שלא ניתן להחזיק על אותה מחיצה device files (בעיקרון device files אמורים להיות רק בתיקיה dev. הימצאות שלהם בתיקיות אחרות יכולה להתפרש כנסיון "עקיפה" של מנגנוני בקרת הגישה להתקנים הקיימים במערכת ). הגדרה אחרת שייתכן ונרצה להפעיל הינה nosuid . הכוונה היא שבמחיצה שבה מופעל מאפיין זה, לא ניתן יהיה להפעיל קבצים בהרשאות המיוחדות suid /sgid (מסמך זה לא עוסק במשמעות של הרשאות אלו ואם אינך מכיר אותם , אנא חפש מידע על כך). מאפיין אחר שאולי נרצה להשתמש בו הינו acl . מאפיין אפשר יפעיל את מה שקרוי posix access control list ויאפשר באותה מחיצה בה הוא קיים העמקה של נושא הרשאות הגישה לקבצים .

שינוי הרשאות:

באמצעות הפקודה find נמצא את כל הקבצים הקיימים במערכת ואשר מופעלת עליהם ההרשאות SUID , SGID והרשאת W (כתיבה) ל other. נשנה ככל האפשר את ההרשאות הללו בהתאם לפונקציות אותן נרצה במערכת.

הקשחה של הטיפול ברשת:

במערכת קיימים מכניזמים שונים היכולים לספק הגנה “רב שיכבתית”. מכניזמים כגון Selinux , iptables ו- tcp wrappers (במימוש של אפליקציות שרת העובדות דרל system V או דרך xinetd ).
על מנת להגן על המערכת נשתמש במערכות ACL אלו כמערכות כלליות.
בנוסף לכך קיימים שרותים אשר מפעילים מנגנוני בקרת גישה בצורה עצמאית. דוגמה לכך היא שרת apache ומנגנוני בקרת הגישה שלו לתיקיות - גם בשרותים אלו נפעיל מנגנוני בקרת גישה.
הדבר השלישי שניתן לומר בהקשר זה הוא מנגנוני בקרת גישה דרך מימוש של policy באמצעות PAM - נפעיל מנגנונים אלו.
הרחבות על מנגנונים אלו ניתן לראות במדריכים הרלוונטיים באתר.

טיפול זה מתבצע במספר שלבים:

1. כיוונון והקשחה של ה TCP/IP stack – למעשה התקשורת מטופלת ע"י ה kernel את הכיוונון הנוכחי של ההתנהגות של פרוטוקול IP נוכל לראות בתת התיקיה /proc/sys/net/ipv4 . תיקיה זו מכילה קבצים המגדירים את הפעילות של פרוטוקול ה IP. לדוגמה: האם לאפשר forward של מידע בין כרטיסי רשת, מהו הזיכרון המוקצה ל TCP, האם להגיב לקריאות בפרוטוקול icmp , או igmp , האם להגיב לקריאות broadcast וכיוצ"ב .

הקבצים עצמם מכילים בדרך כלל ערכים מספריים והכיוונון שלהם יכול להתבצע באמצעות echo או באמצעות הפקודה sysctl . אולם בצורה זו המידע לא יישמר לאחר איתחול. במידה ונרצה לשמור את המידע לאחר ביצוע איתחול (את ההגדרות), עלינו להגדיר אותן בקובץ sysctl.conf אשר נמצא תחת etc (או ect/sysconfig בחלק מההפצות) .

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

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

יש לזכור שמבחינת פרוטוקול OSI , השימוש ב iptables מטפל ברמת ה network של הפרוטוקול.

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

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

על מנת לכוונן מנגנון זה קיימים שני קבצים הראשון הוא hosts.allow והשני hosts.deny . שני הקבצים מצויים בתיקיה etc .

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

לדוגמה: אם אנחנו רוצים לאפשר ssh לכל העולם, פשוט נתקין את השירות של ה ssh. מצד שני, אם אנו רוצים למנוע מאנשים שמגיעים מהרשת של מייקרוסופט גישה אל השירות שלנו, נוכל לרשום את הרשת בתוך hosts.deny (על פי כתובת IP , כתובת רשת , או שם domain ). אם מתוך מייקרוסופט, כן נרצה לתת למכונה מסויימת להגיע, או לקבוצה מסויימת של כתובות IP להגיע לשירות שלנו, נרשום את אותה תת-קבוצה תבוך hosts.allow (על פי כתובת IP, כתובת רשת, או שם domain ).

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

לשרותים שאינם עצמאיים (שרותי system V ) אלא שרותים שעובדים תחת xinetd , נוכל להשתמש במנגנון בקרת גישה דומה המצוי ב xinetd (ההגדרות only_from ו- no_access ) .

ראוי להדגיש שטיפולים אלו הינם כלליים בעיקרם ובשרותים שונים (כמו לדוגמה apache ), נצטרך לטפל בנושא של מגבלת גישה לתיקיות בתוך קובצי ההגדרה של השירות (httpd.conf ) .

הגבלת הגישה למשתמש root :

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

למעשה מערכת ה PAM העוסקת בין השאר בזיהוי המשתמשים, מאפשרת ביצוע של מגבלה שכזו .

בצורה הבסיסית ביותר עלינו לערוך את הקובץ securetty ונשאיר בו רק את הטרמינלים שמהם אנו מוכנים ש root ייכנס אל המערכת. כך לדוגמה אנו נותיר בו רק את השורה tty1 המשתמש root יוכל לעשות login למערכת רק כאשר הוא מגיע מטרמינל מספר 1 (שניתן להגיע אליו ע"י לחיצה על המקשים Alt+Ctrl+F1 ) .

כמו כן נכניס אל שרת ה ssh בקובץ הקונפיגורציה שלו (sshd_config )את הערך PermitRootLogin no , כך שהמשתמש הזה לא יוכל לבצע login מרחוק אל המערכת .

טיפול בשרת ה ssh :

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

מי שמגיע אל המסמך הזה ומתכנן שימוש בו או שימוש בלינוקס כשרת, שישכח מעכשיו משימוש בtelnet server ו/או שרותי “r” למינהם (rlogin, rsh, rexec ). אם יש חיבור מרחוק הוא מתבצע רק בעזרת ssh !
כנ”ל שימוש בפרוטוקול FTP . הפרוטוקול הינו מיותר ואין סיבה מהותית להשתמש בו. ניתן היה להשתמש בו אם הוא לא היה פגיע, הבעיה - שהוא פגיע.

כחלופה ניתן להשתמש ב subsystem של ssh - הכוונה היא ל sftp .

במידה ומתכוונים להשתמש ב ssh כדאי לזכור את הדברים הבאים:

1.         בקובץ הקונפיגורציה של השרת יש הגדרה PermitRootLogin yes יש להעביר אותה ל no על מנת למנוע גישה ישירה לחשבון של . root מנסיוני בכל יום בו שרת מחובר לרשת מתבצעות עשרות (ואף מאות) נסיונות גישה לא מורשים לחשבון root. ביטול של גישה שכזו יקשה על הפורץ להיכנס אל המחשב (כי הוא יצטרך לנחש גם את שם המשתמש שלכם וגם את הסיסמה).

2.         שימוש בפרוטוקול 2 , בקובץ הקונפ' האמור, קיימת האופציה להגדיר באיזה פרוטוקול השרת יעבוד version 1, הכוונה היא ל rsa או version 2 , הכוונה היא ל dsa . יש להשאיר בשורת ההגדרה הזו רק את protocol 2 (בחלק מההפצות השורה לא פעילה כלומר השרת עובד בברירת המחדל ב 2 הפרוטוקולים).

3.         שימוש בהגדרה AllowUsers עם שמות המשתמשים שמותר להם להיכנס לשרת, אם מדובר בכמות של משתמשים ניתן להשתמש בהגדרה AllowGroups עם שם של קבוצה שאליה נשייך את המשתמשים שאנו מתירים להם להיכנס למערכת.

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

טיפול במערכת ה PAM :

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

עם זאת, חלק מההגדרות למודולים הגדולים של PAM נמצאות בתיקיה /etc/secutity , כך שנוכל לכוון ישירות בקובצי ההגדרה הללו התנהגויות שונות. לדוגמה, הקובץ limits.conf מגדיר מגבלות על שימוש בזיכרון, או בזמן CPU או בדרכים אחרים במערכת (בדומה לביצוע quota על דיסק קשיח) כך שניתן לתחום פעילות של משתמשים / קבוצות / שרותים , ביחס לפעילותם במערכת .

מצד שני הקובץ time.conf מגדיר מתי משתמשים או קבוצות יכולים להיכנס אל המערכת , access.conf מגדיר מהיכן הם יכולים לפתוח sessions מול המערכת ועוד. כל אלו בעצם משתמשים ב PAM על מנת להקשות ולהקשיח את הגישה למערכת (וזה עודל לפני העיסוק ב PAM עצמו ) .

** ניתן למצוא מדריך אחר שכתבתי בעבר ונוגע בנושא של PAM בכתובת :

http://www.ofek.biz/WiKi/doku.php

פרמטרים וקונפיגורציה ל kernel

אחד הממשקים החשובים בלינוקס הוא proc המספק לנו גישה לממשק אל ה kernel בזמן הריצה שלו.
ליתר דיוק אפשר לדבר על proc/sys המאפשר לקבוע פרמטרים קבועים או זמניים ל kernel . מעבר לגישה הישירה לקבצים בתוך התיקיה, ניתן להשתמש ב sysctl (הפקודה sysctl -a תציג את הסטטוסים הקיימים כרגע).
בזמן עליית המערכת, קובץ הקונפיגורציה /etc/sysctl.conf נכנס לפעילות (מי שמפעיל אותו הוא הסקריפט /etc/rc.d/rc.sysint כאמור כחלק מהליך האיתחול).
ניתן לפיכך לקבע את ההגדרות בקובץ /etc/sysctl.conf

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookkies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirect = 0
net.ipv4.conf.lo.accept_redirect = 0
net.ipv4.conf.eth0.accept_redirect = 0
net.ipv4.conf.eth1.accept_redirect = 0
net.ipv4.conf.default.accept_redirect = 0
net.ipv4.icmp_echo_ignore_all = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_messages = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.lo.log_martians = 1
net.ipv4.conf.eth0.log_martians = 1
net.ipv4.conf.eth1.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_window_scaling = 0
kernel.exec-shield = 1
kernel.randomize_va_space=1

אופציונאלי:

kernel.core_uses_pid = 1
kernel.sysrq = 0
kernel.core_uses_pid = 1

סיכום:

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

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

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

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

רשיון:

מסמך זה מופץ תחת רשיון CC ייחוס-שיתוף-זהה (את הרשיון ניתן למצוא כאן: http://creativecommons.org/licenses/by-nc-sa/2.5/il/ )

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

הערות, הצעות ותגובות:

במידה ונפלה טעות במסמך, או שאתם חושבים שיש דבר מה לתקן בו , ניתן לפנות אליי בכתובת "> כתובת דוא"ל זו מוגנת מפני spambots, יש לאפשר JavaScript על-מנת לראות את הכתובת

נספח 1: רשימת חבילות RPM כדוגמה לרשימת חבילות על שרת בסיסי

bash-3.1# rpm -qa|wc -l

135

-bash-3.1# rpm -qa

gpg-pubkey-443e1821-421f218f

gpg-pubkey-e8562897-459f07a4

chkconfig-1.3.30.1-1

elfutils-libelf-0.125-3.el5

setup-2.5.58-1.el5

cyrus-sasl-lib-2.1.22-4

expat-1.95.8-8.2.1

db4-4.3.29-9.fc6

libattr-2.4.32-1.1

ethtool-5-1.el5

libtermcap-2.0.8-46.1

ncurses-5.5-24.20060715

grep-2.5.1-54.2.el5

sed-4.1.5-5.fc6

gzip-1.3.5-9.el5.centos

sqlite-3.3.6-2

diffutils-2.8.1-15.2.2

groff-1.18.1.1-11.1

procps-3.2.7-8.1.el5

iproute-2.6.18-4.el5

elfutils-0.125-3.el5

libusb-0.1.12-5.1

python-sqlite-1.1.7-1.2.1

basesystem-8.0-5.1.1.el5.centos

shadow-utils-4.0.17-12.el5

findutils-4.2.27-4.1

psmisc-22.2-5

man-1.6d-1.1

coreutils-5.97-12.1.el5

python-2.4.3-19.el5

cyrus-sasl-2.1.22-4

m2crypto-0.16-6.el5.1

openssl-0.9.8b-8.3.el5_0.2

tar-1.15.1-23.0.1.el5

libgcc-4.1.2-14.el5

centos-release-5-1.0.el5.centos.1

glibc-2.5-18.el5_1.1

popt-1.10.2-47.el5

openldap-2.3.27-8

tcp_wrappers-7.6-40.4.el5

nss-3.11.7-1.3.el5.centos

cracklib-dicts-2.8.9-3.3

audit-libs-python-1.5.5-7.el5

libsysfs-2.0.0-6

keyutils-libs-1.2-1.el5

audit-1.5.5-7.el5

binutils-2.17.50.0.6-5.el5

device-mapper-1.02.20-1.el5

pam-0.99.6.2-3.26.el5

udev-095-14.9.el5

initscripts-8.45.17.EL-1.el5.centos.1

rpm-4.4.2-47.el5

lvm2-2.02.26-3.el5

device-mapper-multipath-0.4.7-12.el5

openssh-clients-4.3p2-24.el5

sysklogd-1.4.1-40.el5

mkinitrd-5.1.19.6-19

libxml2-2.6.26-2.1.2.1

tzdata-2007k-1.el5

mcstrans-0.2.6-1.el5_1.1

vim-minimal-7.0.109-3.el5.3

postgresql-libs-8.1.11-1.el5_1.1

file-4.17-9.0.1.el5

httpd-2.2.3-11.el5.centos

curl-7.15.5-2.el5

perl-5.8.8-10.el5_0.2

php-cli-5.1.6-15.el5

aspell-en-6.0-2.1

zlib-1.2.3-3

mktemp-1.5-23.2.2

bzip2-libs-1.0.3-3

glib2-2.12.3-2.fc6

beecrypt-4.1.2-10.1.1

filesystem-2.4.0-1.el5.centos

gdbm-1.8.0-26.2.1

elfutils-libs-0.125-3.el5

gmp-4.1.4-10.el5

mingetty-1.07-5.2.2

termcap-5.5-1.20060701.1

bash-3.1-16.1

info-4.8-14.el5

libsepol-1.15.2-1.el5

less-394-5.el5

readline-5.1-1.1

gawk-3.1.5-14.el5

cpio-2.6-20

iputils-20020927-43.el5

bzip2-1.0.3-3

compat-db-4.2.52-5.1

libcap-1.10-26

nano-1.3.12-1.1

net-tools-1.60-73

python-elementtree-1.2.6-5

nmap-4.11-1.1

MAKEDEV-3.23-1.2

SysVinit-2.86-14

usbutils-0.71-2.1

cyrus-sasl-md5-2.1.22-4

python-urlgrabber-3.1.0-2

passwd-0.73-1

wget-1.10.2-7.el5

centos-release-notes-5.1.0-2

glibc-common-2.5-18.el5_1.1

audit-libs-1.5.5-7.el5

module-init-tools-3.3-0.pre3.1.34.el5

libstdc++-4.1.2-14.el5

nspr-4.6.5-3.el5

cracklib-2.8.9-3.3

pcre-6.6-2.el5_1.7

libacl-2.2.39-2.1.el5

yum-metadata-parser-1.0-8.fc6

nash-5.1.19.6-19

hwdata-0.211-1

libselinux-1.33.4-4.el5

krb5-libs-1.6.1-17.el5

util-linux-2.13-0.45.el5_1.1

rpm-libs-4.4.2-47.el5

kpartx-0.4.7-12.el5

dmraid-1.0.0.rc13-4.el5

rpm-python-4.4.2-47.el5

openssh-4.3p2-24.el5

libuser-0.54.7-2.el5.2

dhclient-3.0.5-7.el5

openssh-server-4.3p2-24.el5

yum-3.0.5-1.el5.centos.5

e2fsprogs-libs-1.39-10.el5_1.1

libxml2-python-2.6.26-2.1.2.1

e2fsprogs-1.39-10.el5_1.1

apr-1.2.7-11

apr-util-1.2.7-6

mailcap-2.1.23-1.fc6

libidn-0.6.5-1.1

php-common-5.1.6-15.el5

aspell-0.60.3-7.1

php-5.1.6-15.el5

-bash-3.1#