באג קטן ב- DirectAdmin

אחרי הפסקה קצרה ובלי פוסטים חדשים (אבל הרבה כאבי ראש אחרים), יש לנו ילד חדש.

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

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

2 דפים שבהם זה אפשרי (יש עוד הרבה):
http://www.yourdomain.com:2222/HTM_EMAIL_POP_CREATE?DOMAIN=google.co.il
http://www.yourdomain.com:2222/HTM_PASSWD?domain=google.co.il

דף שבו זה לא אפשרי (גם כאן הוא לא היחיד):
http://www.yourdomain.com:2222/CMD_EMAIL_POP?domain=google.co.il

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

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

בחלק מהשרתים אתם יכולים ליצור סאב-דומיין תחת דומיין שקיים על השרת אך לא שייך לחשבון שלכם באמצעות הממשק ליצירת דומיין חדש פשוט באמצעות הזנת ערך בסגנון "xxx.anothersite.com".
אם לדוגמה אתם מאוחסנים באותו שרת שבו מאוחסן האתר "www.anothersite.com",
אתם יכולים ליצור את הדומיין "adir.example.com" ולעשות איתו מה שבא לכם.

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

מה חדש ב- PHP 5.4

מי שהספיק להתעדכן ומי שלא – כשמונה חודשים לאחר ששוחררה גרסת האלפא הראשונה,
אתמול (01/03/12) שוחררה הגרסה הרשמית והמלאה של PHP 5.4.0.
בפוסט זה אספק סקירה קצרה של השינויים, החידושים, מה כבר לא קיים, ממה יש להיזהר ולמה לשים לב במיוחד בגרסה החדשה. הפוסט מיועד בעיקר למפתחי PHP ולבעלי שרתים שמריצים PHP.

מה חדש?

  • traits – עבור מי מכם שמממש OOP, בוודאי תשמחו לדעת שכעת גם PHP תומכת ב- traits.
    מי שלא בטוח מה זה בדיוק המאכל הזה שרשמתי מקודם, זה די דומה להורשה, מושג שעשוי להיות קצת יותר מוכר לכם.
  • קידוד – קידוד ברירת המחדל השתנה מ- "ISO-8859-1" ל- "UTF-8". בנוסף לכך התווספה תמיכה כברירת מחדל ב- Multibyte.
  • הגדרת מערכים – זוכרים את המילה Array שרשמתם לפני כל הגדרה של מערך? לא עוד.
    מהיום תוכלו להגדיר מערכים בדרך קצרה יותר.

    $a = [1, 2, 3, 4];
    $a = ['one' => 1, 'two' => 2, 'three' => 3, 'four' => 4];

    אהבתם? גם אני.

  • פונקציות אנונימיות – אולי אתם מכירים את זה כ- Closures, בכל אופן עכשיו ניתן להשתמש ב- this$ גם בהן, אם במקרה זה היה חסר לכם.
  • short_open_tag – זוכרים את ההגדרה הזאת ב- php.ini?
    עכשיו אתם יכולים להשתמש בתגי פתיחה וסגירה מקוצרים גם בלעדיה, זה יפעל תמיד.
  • מד התקדמות – כעת גם אתם יכולים ליצור מד התקדמות במערכת העלאת הקבצים שלכם בלי להסתבך יותר מדי. בטח תשמחו גם לשמוע שזה פעיל כברירת מחדל. מי אמר אני ולא קיבל?
  • שרת אינטרנט מובנה – זה לא חלום, אפילו אחזור על זה למי שפספס – שרת אינטרנט מובנה!
    לא מדובר פה על משהו שמתיימר להחליף את Apache או Nginx בזמן הקרוב, האופציה הזאת קיימת להקלה ולנוחות בשלב הפיתוח בלבד. אבל בואו נודה באמת – בהחלט שימושי ומבורך.
  • מחלקות, פונקציות ושאר ירקות – יש גם לא מעט קבועים חדשים, מחלקות חדשות, שיטות חדשות ופונקציות חדשות, במקום לסקור את הכל פשוט אקשר אתכם לרשימות המלאות.
    קבועים חדשיםמחלקות חדשותפונקציות חדשותשיטות חדשות

מה ירד?

  • register_globals – הגדרה שנוייה במחלוקת שעלולה הייתה ליצור בעיות אבטחה רבות. כבר בעבר היא כובתה כברירת מחדל, כעת היא הוסרה לחלוטין.
  • magic_quotes – הגדרה נוספת שלא הייתה אהודה כל כך בקרב המפתחים, מטרתה הייתה לבצע הברחה אוטומטית (באמצעות התו "") על כל קלט שהתקבל. פעולה זו יצרה בעיות רבות שהעיקרית שבהן הייתה הברחה כפולה. בגרסה החדשה ההגדרה הזאת לא קיימת יותר.
  • safe_mode – הגדרה נוספת שאינה קיימת יותר, החברים ב- PHP החליטו שזה לא מתפקידה של השפה לפתור את בעיות האבטחה הללו. אתייחס לזה שוב בהמשך.
  • מצביעים – עד עכשיו ניתן היה להעביר לפונקציה "התייחסות" (מצביע) למשתנה כלשהו הן בעת הגדרתה והן בזמן הקריאה, כעת ניתן להגדיר פרמטר כמצביע אך ורק בעת הגדרת הפונקציה.
  • סיישנים – הפונקציות session_register, session_unregister ו- session_is_registered אינן קיימות יותר. ניתן להשתמש בהצבה באמצעות האופטור "=" ובפונקציות unset ו- isset למטרה זו.
  • mysqli – מגוון שמות נוספים (Alias) ששימשו לקיצור השמות הארוכים של חלק מהפונקציות במחלקה הזו הוסרו, להלן הרשימה המלאה לנוחיותכם (חלקן עדיין קיימות).

מה נשתנה הלילה הזה?

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

תמיכה ב- multibyte כסטנדרט, הגדרת מערכים בקלות, מד התקדמות מובנה ותגי פתיחה וסגירה מקוצרים – תוספות מצויינות שתורמות לשפה ללא ספק. אבל, אני חושב שהכתר מגיע דווקא לשרת האינטרנט המובנה. למרות שאת הביטוי "LAMP" אני בטוח שיכירו גם מחר, לדעתי זאת אופציה מצוינת.

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

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

מבוא ל- DHCP

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

DHCP (בעברית: פרוטוקול הגדרת מארחים דינמי):

DHCP, או בשמו המלא Dynamic Host Configuration Protocol, הוא פרוטוקול תקשורת המשמש להקצאה דינמית של כתובות IP למחשבים ברשת מקומית (LAN).
מנהל הרשת מגדיר לשרת ה- DHCP תחום כתובות וכל מחשב ברשת מוגדר לבקש את כתובת ה- IP שלו מהשרת ברגע שהוא מתחבר לרשת.
הכתובת מוקצית למחשב לזמן מוגבל, בסופו אם המחשב לא יבקש לחדש את הכתובת שניתנה לו הכתובת תחזור למאגר כתובות ה- IP הזמינות והשרת ייתן אותה למחשב הבא שירצה להתחבר לרשת.
(מתוך ויקיפדיה)

למה צריך DHCP:

בואו נתחיל בזה שלא חייב להשתמש ב- DHCP, ניתן להגדיר רשת גם בלעדיו, היא תעבוד והכל יהיה בסדר.
אז למה כן להשתמש ב- DHCP? בואו נדמיין מצב מסויים, רשת מסויימת, הרשת בסניף הקרוב של חברת הפלאפון שלכם.
נגיד שבאותו סניף יש 20 מחשבים, חלקם לשימוש אנשי המכירות, חלקם לשימוש אנשי התמיכה, חלקם בכלל בתוך המעבדה, אבל בסופו של דבר כולם שייכים לאותה רשת.
לכם, בתור מנהלי הרשת, יש 2 אופציות:
האופציה הראשונה: לעבור בין כל המחשבים, 20 מחשבים אמרנו, להגדיר להם כתובת IP, שרתי Subnet mask ,DNS, שער ברירת מחדל וכו'.
להגדיר בכולם את אותם הפרטים (פרט לכתובת ה- IP) – הרי אמרנו שהם שייכים לאותה רשת.
האופציה השנייה: להגדיר את כל הפרטים הללו במקום אחד, בשרת ה- DHCP.
כל מחשב שירצה לקבל את הפרטים הללו, שהם חיוניים עבור התקשורת שלו ברשת, יפנה לשרת הזה ויבקש ממנו אותם.

מה יותר פשוט? מה יותר נוח? במה תבחרו? אני מניח שברוב המקרים באופציה השנייה – בשרת DHCP.

איך מגדירים שרת DHCP:

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

הגדרת שרת DHCP

הסבר קצר על כל הגדרה:
DHCP Pool Name – השם של המאגר (לא קריטי).
DHCP Pool Network – כתובת הרשת.
Subnet mask – ה- subnet mask של הרשת.
Starting IP – כתובת ה- IP הראשונה בטווח הכתובות שהשרת יחלק.
Ending IP – כתובת ה- IP האחרונה בטווח הכתובות שהשרת יחלק.
Lease Length – זמן ההשאלה, כמה זמן כתובת שהוקצתה עבור מחשב מסויים צריכה להישמר עבורו.
DHCP Options – כל הפרטים שכבר הזכרנו (שרתי DNS, שרתי WINS, שער ברירת מחדל וכו').

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

איך זה עובד:

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

הפעולה הראשונה – אותה מבצע המחשב – היא DHCP Discovery.
המחשב שולח בקשה ברשת, בקשה שמגיעה לכל מי שמחובר לרשת,
ובשפה פשוטה, הוא שואל: "שלום, אני חדש פה, האם יש פה איזה שרת DHCP שמוכן בבקשה לטפל בי?".

הפעולה השנייה – אותה מבצע השרת – היא DHCP Lease Offer.
שרת ה- DHCP מקבל את ההודעה ששלח המחשב, שומר בצד כתובת IP עבורו (עדיין לא מקצה לו אותה),
ועונה לו: "שלום לך, אני שרת DHCP, אני יכול להקצות עבורך את הכתובת 1.2.3.4 ולספק לך את שאר הפרטים שאתה צריך, מעוניין?".

הפעולה השלישית – אותה מבצע המחשב – היא DHCP Request.
המחשב מקבל את ההודעה שהחזיר לו השרת, הוא ממש שמח שהוא מצא שרת DHCP,
ועונה לו: "כן, אשמח לקבל את הכתובת הזאת ואת שאר הפרטים, תוכל בבקשה לתת לי אותם?".

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

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

יתרונות וחסרונות בעבודה עם שרת DHCP:

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

Basic IP Addressing & Subnetting

במאמר זה אלמד לעבוד עם בינארי, אסביר מהי כתובת IP (תוך התייחסות ל- IPv4 בלבד), מהי Subnet Mask ומהו Default Gateway, אסקור את ההבדלים בין כתובות פרטיות לכתובות ציבוריות ואסביר בקצרה כיצד מגדירים רשת.
המאמר מיועד לקהל יעד בעל הבנה מינימלית-בסיסית במחשבים וברשתות תקשורת.

עבודה עם בינארי:

כדי להבין את המאמר, נצטרך לדעת לעבוד עם ערכים בינארים ולהמיר ערך דצימלי לערך בינארי ולהיפך.
נעבוד עם 8 סיביות בצורה הבאה (כל מספר מייצג ביט): 1 2 4 8 16 32 64 128
נתחיל מהערך הגדול (128) לקטן (1), עבור כל סיבית שהערך שלה נכנס במספר שברצוננו להמיר נסמן 1 ונפחית את הערך שלה מהמספר הנתון, במידה וערך הסיבית גדול מהמספר הנתון נסמן 0 ונמשיך הלאה לסיבית הבאה עד שנגיע ל- 0, אם הגענו ל- 0 לפני הסוף נסמן 0 בכל הסיביות שנשארו.
לדוגמה – נמיר את המספר 100 לבינארי.

מכאן הבנו שהערך הבינארי של 100 הוא 01100100, תרגלו בעצמכם המרה של כמה מספרים מבסיס אחד לשני, חשוב להבין את זה כדי להמשיך הלאה.
בהמרה עם 8 ביטים בצורה הזאת, ניתן להמיר מספרים בין 0 (00000000) ל- 255 (11111111).

IP Address (בעברית: כתובת IP):

כתובת IP הינה מזהה ייחודי הניתן למכשירים (מחשבים, נתבים וכד') ברשת IP על מנת שיוכלו לתקשר ביניהם. הכתובת מורכבת מ- 32 סיביות המחולקים ל- 4 חלקים של 8 סיביות כל אחד (נקראים גם octets) המופרדים ביניהם בנקודה (.). נהוג להמיר את הכתובת לערך דצימלי, כך שכל אחד מארבעת חלקי הכתובת מכיל מספר בטווח 0-255.
כתובת IP לדוגמה: 74.125.230.83 (בבינארי: 01001010.01111101.11100110.01010011).

בנוסף, ניתן לחלק את כתובות ה- IP ל- 5 מחלקות/ רשתות, A-E, אנו נתייחס לרשתות A-C בלבד היות והן הרשתות שבהן נעשה השימוש העיקרי כיום.
את המחלקה/ הרשת של כתובת ה- IP ניתן לזהות על פי ה- octet (החלק) הראשון בכתובת:
רשת A מכילה את הכתובות שבהן ה- octet הראשון הינו בטווח 1-127.
רשת B מכילה את הכתובות שבהן ה- octet הראשון הינו בטווח 128-191.
רשת C מכילה את הכתובות שבהן ה- octet הראשון הינו בטווח 192-223.

Subnet Mask (בעברית: מסכת רשת משנה):

subnet mask הינה הגדרה בעלת מבנה זהה לזה של כתובת IP הבאה במטרה להגדיר איזה חלק מהכתובת מסמל את הרשת ואיזה חלק מסמל את המכשיר (לדוג': מחשב).
בעזרת subnet masks ניתן לחלק כל אחת מן הרשתות המוזכרות לעיל לתת-רשתות וכך בעצם ניתן ליצור מספר רשתות גדול יותר בצורה משמעותית לעומת כמות הרשתות שיכולנו ליצור בשימוש ברשתות הקיימות במחלקות A-C בלבד.
כשמגדירים subnet mask חובה לשמור על רצף של 1 (המשמש לציון הרשת) ולאחר מכן רצף של 0 (המשמש לציון הרכיבים), רצוי לכתוב את ה- subnet mask בבינארי לפני שהופכים אותו לדצימלי בכדי לוודא את תקינות ההגדרה.

כאשר לא נגדיר subnet mask, יעשה שימוש בהגדרת ברירת המחדל שהוגדרה עבור הרשת (A-C) של הכתובת בה השתמשנו –
ברשת A ברירת המחדל היא 255.0.0.0 11111111.00000000.00000000.00000000,
הרשת מוגדרת ע"י ה- octet הראשון בכתובת (8 bits), הרכיבים ע"י שלושת האחרים (24 bits).
ברשת B ברירת המחדל היא 255.255.0.0 11111111.11111111.00000000.00000000,
הרשת מוגדרת ע"י שני ה- octets הראשונים בכתובת (16 bits), הרכיבים ע"י שני האחרים (16 bits).
ברשת C ברירת המחדל היא 255.255.255.0 11111111.11111111.11111111.00000000,
הרשת מוגדרת ע"י שלושת ה- octets הראשונים בכתובת (24 bits), הרכיבים ע"י האחרון (8 bits).

דוגמאות:
subnet mask תקין – 255.255.255.224 11111111.11111111.11111111.11100000 (קיים רצף תקין של 1 ו- 0).
subnet mask לא תקין – 255.255.255.153 11111111.11111111.11111111.10011001 (לא קיים רצף תקין של 1 ו- 0).

Default Gateway (בעברית: שער ברירת מחדל):

default gateway הינו כינוי לרכיב ברשת שתפקידו לאפשר ולנתב תקשורת בין הרשת הפנימית לרשתות אחרות, לרוב נשתמש בראוטר (שזה תפקידו העיקרי) בתור שער ברירת מחדל.
כשנגדיר רשת ונרצה להגדיר שרת ברירת מחדל, נפנה אליו באמצעות כתובת ה- IP שלו.

כתובות ציבוריות וכתובות פרטיות:

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

ישנם מספר טווחים שהוקצו לטובת כתובות פרטיות –
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

Subnetting:

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

ב- 2 ההדגמות נשתמש בכתובת הרשת הבאה: 192.168.0.0

נתחיל עם הגדרה על פי כמות רשתות רצויה:

שלב ראשון – הגדרת כמות הרשתות הרצויה, המרת המספר לבינארי ומציאת כמות הביטים הדרושה לייצוג אותו מספר, לצורך הדגמה נצטרך 5 רשתות.
לאחר שנמיר את המספר 5 לבינארי נקבל 00000101, כמו שניתן לראות השתמשנו ב- 3 ביטים (00000101) כדי להגדיר את כמות הרשתות.

שלב שני – הצבת כמות הביטים הנחוצה ב- subnet mask ותחימת הטווחים ברשת.
כפי שניתן לראות אנו משתמשים בכתובת IP מרשת C (ה- octet הראשון הינו 192),
אנו יודעים שה- subnet mask ברירת המחדל של רשת זו הינה 255.255.255.0, או 11111111.11111111.11111111.00000000 בייצוג בינארי.
הסברנו שאנו משתמשים ב- 1 להגדרת הרשת וב- 0 להגדרת הרכיבים, לכן נגדיר 3 ביטים (כמות הביטים הדרושה לייצוג כמות הרשתות הרצויה) עבור הרשת ו- 5 ביטים עבור הרכיבים ונקבל: 11111111.11111111.11111111.11100000.
נמיר את ה- subnet mask שהתקבל לערכים דצימלים ונקבל: 255.255.255.224.

כדי לתחום את הטווחים ברשת נבצע את הפעולה הבאה –
מצאנו שצריך 3 ביטים כדי להגדיר 5 רשתות והצבנו אותם בצורה הבאה: 11100000,
נבחר את ערכו של הביט הנמוך ביותר בו אנו משתמשים, במקרה הזה זה יהיה הביט השלישי משמאל (הראשון משמאל הוא 128, השני הוא 64, השלישי הוא 32 וכך הלאה),
הערך הנמוך ביותר הינו 32 וזה ישמש אותנו לתחימת הרשת בצורה הבאה:
192.168.0.0 – 192.168.0.31
192.168.0.32 – 192.168.0.63
192.168.0.64 – 192.168.0.95
192.168.0.96 – 192.168.0.127
192.168.0.128 – 192.168.0.159

עכשיו נעבור להגדרה על פי כמות הרכיבים הרצויה בכל רשת:

שלב ראשון – הגדרת כמות הרכיבים המירבית בכל רשת, המרת המספר לבינארי ומציאת כמות הביטים הדרושה לייצוג אותו מספר, לצורך הדגמה נצטרך 30 רכיבים בכל רשת.
לאחר שנמיר את המספר 30 לבינארי נקבל 00011110, כמו שניתן לראות השתמשנו ב- 5 ביטים (00011110) כדי להגדיר את כמות הרכיבים.

שלב שני – הצבת כמות הביטים הנחוצה ב- subnet mask, מציאת כמות הרכיבים המירבית בכל רשת ותחימת הטווחים ברשת.
כפי שניתן לראות אנו משתמשים בכתובת IP מרשת C (ה- octet הראשון הינו 192),
אנו יודעים שה- subnet mask ברירת המחדל של רשת זו הינה 255.255.255.0, או 11111111.11111111.11111111.00000000 בייצוג בינארי.
הסברנו שאנו משתמשים ב- 0 להגדרת הרכיבים וב- 1 להגדרת הרשת לכן נגדיר 5 ביטים (כמות הביטים הדרושה לייצוג כמות הרכיבים הרצויה) עבור הרכיבים ו- 3 ביטים עבור הרשת ונקבל: 11111111.11111111.11111111.11100000.
נמיר את ה- subnet mask שהתקבל לערכים דצימלים ונקבל: 255.255.255.224.

כדי לתחום את הטווחים ברשת נבצע את הפעולה הבאה –
מצאנו שצריך 5 ביטים כדי להגדיר 30 רכיבים בכל רשת והצבנו אותם בצורה הבאה: 11100000,
נבחר את ערכו של הביט הנמוך ביותר בו אנו משתמשים, במקרה הזה זה יהיה הביט השלישי משמאל (הראשון משמאל הוא 128, השני הוא 64, השלישי הוא 32 וכך הלאה),
הערך הנמוך ביותר הינו 32 וזה ישמש אותנו לתחימת הרשת בצורה הבאה:
192.168.0.0 – 192.168.0.31
192.168.0.32 – 192.168.0.63
192.168.0.64 – 192.168.0.95
192.168.0.96 – 192.168.0.127
192.168.0.128 – 192.168.0.159

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

חשוב לדעת!
לכל רכיב ברשת IP חובה להגדיר IP address כדי שנוכל לתקשר איתו,
לכל רשת IP חובה שתהיה subnet mask כדי לתחום את טווח הכתובות שלה,
הגדרת default gateway אינה בגדר חובה והיא דרושה רק במידה ורוצים לתקשר אל מחוץ לרשת המקומית.

הגדרת רשת לדוגמה:
הגדרת רשת לדוגמה

רוצים לפתוח חשבון ב- PayPal? אני מוכן לעשות זאת עבורכם

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

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

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

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

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

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

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

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

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

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

אז מה באתי להגיד בכל הפוסט הזה?
למה גרמתי לכם לבזבז דקות ארוכות בקריאת עוד פוסט משעמם אם בסוף הסיפור זה בכלל אני אשם?

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

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

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