מכללת טרביצקי| פרק רביעי - הזדהות פנים ארגונית

שוב שלום לכולם,

היום אני הולך לדבר על ״הזדהות״ בשפה העממתי , או ״אימות זהות״ בשפה האקדמית. לי יותר נוח ״הזדהות״, סילחו לי על כך. נושא הזדהות הוא נושא דו מקיף ואני מעדיף לחלק אותו למס׳ חלקים:

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

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

אז בוא נתחיל. ראשית, חשוב להבין מה ההגדרה של הזדהות.בהגדרה, הזדהות היא דרך או שיטה לזהות את הישות (שיכולים להיות משתמש או מחשב) שמנסה לגשת למערכת. בנוסף, שיטת הזדהות צריכה לכלול מנגנונים שימנעו התחזות לאחר, שכפול והתקפה של Man in the Middle. בפועל, המצב לא כזה וורוד, אני אראה לכם בהמשך. בתקשורת מחשבים יש מושג שראשי תיבות שלו באנגלית AAA - Authentication Authorization Accounting. למעשה המושג הזה בא לאחד את כל התהליך מרגע ההתחברות לרשת ועד לקבלת גישה באמצעות הזדהות. התהליך כולל הזדהות, מתן הרשאות (אוטוריזציה) וניהול רישום של ההזדהות מתחילת החיבור ועד סופו (בד״כ לצורך חיוב או תיעוד).
היום אני הולך לדבר על טכנולוגיות הזדהות שנועדו בעיקר לשימוש בתוך הארגון, זאת אומרת ברשתות הפנימיות שלו. בגדול, חלוקה כזאת לא קיימת, אני המצאתי אותה כאן על מנת איכשהו לחלק את כל שיטות ההזדהות, ויש הרבה, יש שיטות להזדהות של משתמש בתחנה, יש שיטות הזדהות של התחנה עצמה, לפני שהמשתמש בכלל פתח אותה, יש התחבות ורשתות אלחוט, יש חיבור מהבית, שעון נוכחות ואיפלו תלושי ארוחת צהריים צריכים הזדהות. וזאת רק ההתחלה. כפי שאתם רואים, כשלמודים את כל הדברים האלה בבת אחת, או שהולכים לעשות CCIE, או שהולכים לאשפוז, לכן החלטתי לחלק את הטכנולוגיות לפי הטופולוגיה הארגונית (למתקשים, לפי מיקומו של מי שצריך להזדהות). כשאני אומר פנים ארגוני, אני מתכוון למצבים בהם משתמש או מכונה שנמצאים בתוך הרשת הארגונית מנסים להזדהות מול המערכת ולקבל גישה או משאב. תרחיש נוסף הוא שציוד proxy שולח הזדהות בשם משתמש או מחשב שנמצא מחוץ לרשתות פנימיות. זה מצב שכיח בהתחברות מרחוק או בהתחברות בwifi. בפוסט הזה אנו נתיחס רק לחלק שבין הproxy לבין הישות המזהה, זאת אומרת לתעבורה שעוברת בתוך הארגון. באזורים האלה של הרשת בדרך כלל שולטים הפרוטוקולים הבאים:

• RADIUS או +TACACS
• LDAP
• KERBEROS
• SQL שלא כלכך נחשב לפרוטוקול הזדהות, אך קשור להזדהות בweb application. אני אתיחס בקצרה גם אליו.

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

RADIUS או +TACACS

הסיבה ששמתי אותם ביחד היא בגלל שהם בסופו של דבר שני גישות שונות לאותה בעיה.
מדובר בשני פרוטוקולים הכי ״טפישיים״ מבין כל אלה שאנו סוקרים היום. למה ״טיפשיים״, משום שכל תפקידם הוא לשלוח בקשת הזדהות לשרת ולקבל תשובה ממנו. הפרוטוקולים הללו לא מגדירים בסיס נתונים של משתמשים או קבוצות או מידור. לרוב, שרת RADIUS מחזיק רשימת משתמשים מקומית או מתחבר לשרתי משתמשים חיצוניים כגון LDAP או Active Directory. מה שכן, הפרוטוקולים הללו ״גמישים״ וניתן, בנוסף לתשובה ״מורשה״ או ״לא מורשה״ להוסיף תוכן או הרשאות בעזרת attributes שזה בעצם שדות שנשלחים בתוך הפאקטים של הפרוטוקול. למשל, אם נדרש לאחר ההזדהות, למקם את המשתמש בvlan מסויים, אז אחרי שליחת בקשת הזדהות (ע״י בקר אלחוטי למשל) השרת מחזיר בתשובה שלו את מס׳ הvlan והבקר ממקם את המשתמש בהתאם לattribute הזה. הפרוטוקולים הללו נמצאים בד״כ בשימוש ע״י מה שנקרה authenticators. אלו הם proxies של הזדהות כגון RASים, מתגים, נתבים, בקרי אלחוט ובקרי גישה מרחוק. משתמשים בד״כ לא פונים ישירות לשרתים הללו.
אז מה ההבדלים בין RADUIS לTACACS - בעצם אין כל כך הרבה,

• RADIUS הינו תקן פתוח וTACACS שייך לחברת סיסקו . 
• RADIUS מצפין רק את הססמאות (MD5 hash לא בדיוק הצפנה), כשהTACACS מצפין את כל התעבורה שלו.
• RADIUS עבור על פרוטוקול UDP ודורש שני פורטים - אחד עבור ההזדהות ואחד עבוד הרישום - accounting, כאשר TACACS עובד על TCP פורט 49.

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

LDAP

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

על אף שהפרוטוקול עצמו בינרי, המבנה של העץ נהוג להציג בפרומט LDIF שנראה כך:

 dn: cn=John Doe,dc=example,dc=com

 cn: John Doe

 givenName: John

 sn: Doe

 telephoneNumber: +1 888 555 6789

 telephoneNumber: +1 888 555 1232

 mail: john@example.com

 manager: cn=Barbara Doe,dc=example,dc=com

 objectClass: inetOrgPerson

 objectClass: organizationalPerson

 objectClass: person

 objectClass: top

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

• LDAP מעביר ססמאות בתווך, בצורה מוצפנת או לא מוצפנת. OpenLDAP תומך בSHA1,MD5 וcrypt. מיקרוספוט תומכים בNT hash. בכל מקרה, להעביר ססמאות על גבי הרשת זה רעיון לא כל כך טוב.
• LDAP תומך רק בהזדהות בשם משתשמש וססמה. גם אם אתם מזדהים עם תעודה, בסופו של דבר, הauthenticator יחלץ מתוך התעודה את שם המשתמש ויזדהה איתו.
• LDAP לא מודע לשכובות שמתחתיו, מה שחושף אותו להתקפות מסוג replay.
• LDAP לא מספק SSO. אם רוצים להפעיל SSO, יש צורך להעזר בספקי הSSO, אשר משתשמש בשאילתות LDAP.
• LDAP לא תומך באצילת סמכויות (delegation). זאת אומרת שמשתמש או מכונה מסויים יכולים להזדהות בשם משתמש אחר.
• לLDAP אין תוקף להזדהות מוצלחת. LDAP לא באמת יודע מה עושים ולכמה זמן עם התשובה החיובית שהוא החזיר לauthenticator.

רגע, כל כך הרבה חורים! אז למה ממשיכים להשתמש בו ? התשובה היא שההתממשקות מול LDAP פשוט יחסית והסיבה השנייה - ״זה עובד!״ . ל LDAP יש שלושה סוגי התממשקות להזדהות:

• anonymous - כל בקשה תקבל שתובה.
• simple - בנוסף לקשה, נדרש לספק פרטי משתמש bind. זאת צורת עבודה מקובלת ברוב המקרים.
• SASL - הזדהות יותר חזקה בעזרת challenge מאובטח.בד״כ נמצא בשימוש ע״י Kerberos לצורך שאילתות.

בתצורת simple אנו בד״כ נכניס את כתובת שרת LDAP, פורט שהוא מאזין (389tcp/udp לLDAP ו636 לLDAPS) , נאפשר SSL, ניתן שם משתמש bind וססמתו וגמרנו את ההגדרות. בשונה משרתי RADIUS/TACACS שבהם נדרש להגדיר את כתובות הauthenticatorים וססמאותיהם, כאן לא נדרש לבצע כל שינוי בצד השרת.

ואם אני רוצה יותר security ? יותר אופציות ? יותר נוחות ??? - בשביל זה יש לי את Kerberos !!!

Kerberos

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

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

• בקרברוס סיסמת הגורם המאומת אף בעם לא עוברת בתווך. למעשה הקליינט מצפין את שאילתת הבקשה עם הססמה שלו, והשרת מחזיר את התשובה שכוללת את כל מאפייני המשתמש מוצפנת עם הססמה של הקליינט. אם הקליינט הצליח לפענח את התשובה, אזהי הססמה תקינה וההזדהות עברה בצורה תקינה, אחרת הקלייט מניח שהססמה שגויה.לאחר התחברות מוצלחת הקליינט מקבל מהשרת session key שמוצפן בעזרת סיסמת המשתמש, בעזרתו הקליינט יצפין את התעבורה של אותו session. 
• אחרי שהגורם המאומת קיבל אישר חיובי עבור ההזדהות, נפתח עבורו ״כרטיס״ ובו פרטי המשתשמ שכוללים כתובת המשתמש - client network address, שם משתמש - client ID, תאריך התחברות ותוקף הכרטיס, כלומר כל הזדהות בקרברוס יש תוקף. בחלונות, למשל תוקף כרטיס משתמש הוא 10 שעות. הערה: למעשה, לקרברוס יש שני סוגי תוקף כרטיס - תוקף הכרטיס, ticket lifetime, ותוקף החידוש, renewal lifetime. כאשר נגמר תוקף הכרטיס, המשתמש או האפליקצייה יכולות לבקש משרת הקרברוס להאריך את תוקף הכרטיס ובמידה ותוקף החידוש לא פג, השרת יאריך את תוקף שכרכיס. בחלונות, ברירת המחדל לתוקף החידוש הינו 7 ימים, כלומר כעבור 10 שעות אחרי ההתחברות, המשתמש יכול לבקש להאריך את הsession שלו כל פעם בעוד 10 שעות ולעשות זאת למשך שבוע. במידה והקליינט לא ביקש הערכה, הכרטיס פג תוקף ונדרשת הזדהות מחדש.   
• יש הזדהות הדדית בין השרת לקליינט, כלומר השרת מוודא שהוא עובד מול משתמש נכון, אך גם הקליינט יודע לוודא כי הוא עובד מול השרת הנכון. בLDAP, למשל, אין יכולת כזאת.
• יכולת לעבוד עם אצילת סמכויות. Constrained delegation או KCD נמצאה כתכונה מאוד שימושית בקרב אנשי החלונות, ולא רק הם.למשל, constrained delegation מאפשרת לשרת ווב שנמצא באיזור אחר ברשת, לבצע אימות מול שרת הActive Directory (שזה בעצם LDAP) בפרוטוקול קרברוס בשם המשתמש שמנסה להתחבר לשרת הווב. כך אותו שרת יכול לעבוד מול כמה דומיינים בו זמנית, פר משתמש. את זה ניתן לבצע רק בקרברוס.
• יכולת (SSO (single sign-on מובנית.ביכולת הזאת מיקרוסופט עושה שימוש כבד בכל השירותים אשר מספקים שרתי חלונות למינהם, למשל שרת קבצים, exchange וכו׳. זה חוסך מהמשתמש להכניס את פרטי ההזדהות מחדש, כל פעם שהוא עובר לאפליקצייה אחרת שמזדהה מול אותו שרת קרברוס.
• יכולת עבודה מובנית עם מס׳ מנגנוני אימות כגון כרטיסי חכמים, קוראים ביאומטרים, טוקנים ועוד. 
• לקרברוס יש מנגנונים למניעת התקפות replay. למי שלא מכיר על מה אני מדבר כאן, ורואה את זה פעם שנייה בפוסט, אסביר, מדובר במצב שהתוקף הקליט תעבורה של הזדהות תקינה מבעוד מועד, ועכשיו הוא שולח את אותה תעבורה שהוא הקליט שוב לכיוון השרת במטרה שלקבל גישה מחדש.
• בפיירוולים מהדור החדש נעשה שימוש בקרברוס לצורך הפעלת יכולת של User Awarness, זאת אומרת, כתיבת החוקה לפי משתמשים או קבוצות ולא לפי כתבותIP, כמו בפיירוול הקלאסי. זה מאפשר למשתמש לקבל את אותה רמת גישה ללא התלות במיקום גאוגרפי.

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

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

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

יש שיטת הזדהות נוספת, והיא בד״כ בשימוש ע״י web applications. במקרה כזה, הSQL למעשה מחליף את LDAP כמסד נתונים של המשתשמים. היתרון שלו הוא ביכולת גדילה ונוכות התפעול.הSQL עצמו אינו מבצע את ההזדהות, אלא מחזיר למבקש השאילתה את פרטי המשתמש אשר מאוחסנים במסד הנתונים, לכן לא ראיתי סיבה מיוחדת להתעכב עליו.

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

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

קובי.

מכללת טרביצקי| פרק שלישי - HTTP/2

הקדמה.

אינטרנט כבר מלא בעמודים ופוסטים שמסבירים מה זה ואיך אוכלים את זה ברמת RFC ובאנגלית של application delivey experts. אני אנסה להסביר על HTTP/2 (או HTTPbis) בצורה יותר מופשטת, לאנשים שיודעים תקשורת, איך לא עוסקים בהקמת שרתי ווב לפרנסתם ורוצים רק להיות מעודכנים טכנולוגית. אם זאת, אשתדל להביא כמה שיותר מידע אודות הפרוטוקול. אז בוא נתחיל...

מה זה HTTP?

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

קצת היסטוריה.

פיתוח של הפרוטוקול כפי שאנו מכירים היום החל בתחילת שנות ה90 (למראות שרעיון של HTTP הולך הרבה יותר אחורה אל שנות ה80). הגרסה הראשונה של HTTP נחשפה ציבורית ב1996. כבר ב97 יצא גרסה 1.1 עם המון עדכונים מהותיים המון יכולות חדשות והיא למעשה הגרסה שנמצאת בשימוש עד היום על רוב השרתים. איך העולם התקדם והפרוטוקול של כמעט 20 שנה הופך לאט לאט למיושן וחברות החלו לחפש פתונות חדשים. ביולי 2012 חברת גוגל הוציא טיוטה של פרוטוקול ספידי (SPDY) שדי הפך לאבן היסוד של HTTP/2. במאי 2015 יצא התקן הרשמי וגוגל הודיעו שהם מפסיקים פיתוח ותמיכה בספידי לטובת HTTP/2. 

מה כל כך צריך את HTTP/2?

HTTP/2 נועד לתת שיפורים מהותיים ולספק מענה למספר בעיות שקיימות בHTTP1.1:

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

- שיפור ״יחסי עבודה״ בין HTTP וTCP. לTCP יש מנגנונים לתקשורת יעילה, אך HTTP 1.1 לא התשתמש בהם, למעשה את HTTP 1.1 לא עניין בכלל מצב הTCP, מה שיצר לפעמים כפל תעבורה והרבה בייטים מבוזבזים. התקן המקורי של HTTP 1.1 הגדיר 2 TCP קונקשנים לאתר. על מנת לעמוד בתקן, המפתחים היו מתחכמים, יוצרים דומיין חדש ובקוד היו מבקשים חלק מהעמוד מהדומיין השני. עם הזמן, מספר הקונקשנים בתקן עלה והיום ניתן לראות מספרים כמו 20-30 קונקשנים לקליינט, אך עדיין זה צורת עבודה מיושנת. מנגנונים כמו multiplexing של HTTP/2 באים לתת מענה לבעיה הזאת. HTTP/2 יודע להעביר את כל התעבורה במקביל על גבי TCP קונקשן בודד.

-דחיסה. בכל שאילתת HTTP, בראש השאילתא, נמצאים HTTP headers. תפקידם, לעזור לשרת (וגם לקליינט) להבין מה סוג המכונה שנמצאת בכל צד. האם זה טלפון? במידה וכן, השרת יציג אתר מותאם למכשירים ניידים. מה גודל המסך של הקליינט? איזה סוג קובץ הוא מבקש? באיזה שפה להציג את העמוד? האם זה בכלל אלפיקציה ולא דפדפן. הכל כתוב בheaderים. הבעיה היא האותם headerים נשלחים בכל שאילתה ולפעמים נוצר מצב אבסורדי שעבור 1 קילובייט מידע נשלחים 3, כאשר 2 מתוכם רק הheaderים. HTTP/2 פתור את הבעיה על משהו שנקרה HPACK וזה עובד ככה: בשאילתא הראשונה נשלחים כל הheaderים, הם נשמרים במטמון של כל צד, ובהמשך הסשן, נשלחים רק headerים חדשים או שונים.יכולת זו חוסכת המון זמן ותעבורה מיותרת.

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

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

כאן המקום להראות השוואה בין HTTP 1.1 וHTTP/2 (טוב, לא בדיוק 2, אלא SPDY, הHTTP/2 מציג תוצאות אף יותר טובות).

בתמונה הראשונה אני ניגשתי ליוטיוב, שתומך בSPDY בפרוטוקול HTTPS רגיל:

זום של ציר הזמן:

ניתן לראות ששאילתא ראשונה לקחה 1.36ש׳.

עכשיו בוא נפעיל את SPDY:

והנה הזום שלנו:

שימו לב, הפערים מגיעים ל300%!!! למה זה קורה ? כפי שהסברתי קודם, HTTP בפעול לא מסוגל לעבד יותר משאילתא אחת פר קונקשן, וזה יוצר את הblocking time שמצויין בעפור בציר הזמן של HTTPS. בHTTP/2 השאילתות נשלחות במקביל וזה חוסך כמויות אדירות של זמן יקר של שרת, קליינט וצרכן המידע.

רגע, אבל מה עם אבטחת מידע ?

בעקרון, תקן הHTTP/2 אינו מחייב הצפנה, למראת שגוגל די דחפה לכיוון הזה. כתוצאה מכך, רוב מפתחי SPDY/HTTP2 אימצו את העדפה כן לעבוד בSSL עם TLS 1.2 לפחות, אבל בהחלט ניתן לעבוד ללא הצפנה כמו שהיה בHTTP.

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

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

איך HTTP/2 משפיע על ביצועי שרתים ?

-ביחס לHTTPS, הHTTP/2 צורך פחות CPU וזכרון של השרת.

-ביחס לHTTP, הHTTP/2 צורך פחות זכרון, אך קצת יותר CPU.

-ביחס לHTTP/S הHTTP/2 עובד עם הרבה פחות קונקשנים ובכח מעלה משמעותית את קיבולת השרת.

דברים שצריך לקחת בחשבון לפני שעוברים לHTTP/2.

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

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

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

  הבדל בולט נוסף בין HTTP 1.1 וHTTP/2 הא שHTTP/2 פרוטוקול בינרי ולא טקסטואלי כמו קודמו. לכן, הtroubleshooting כאן הוא יותר מורכב, זאת אומרת שבשביל לצפות בתשדורות על השרת, נדרשים פארסרים או ספריות ש״לועסות״ את התעבורה ומציגות אותו בשפה אנושית. גם כלים כמו wireshark הוציאו תמיכה בסיסית בHTTP/2 עם טעינת מפתח לתוכו.

סיכום.

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

נ.ב.

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

חג סוכות שמח וביי,

קובי.

הדברים הקטנים שאנו שוכחים - מחבר lightning

אתמול בתי בא אליי. הטלפון לא נטען, היא אמרה, תסתכל בבקשה. הסתכלתי ומה שראיתי מצולם כאן למעלה. מדובר במכשיר אנדרואיד סיני פשוט בכמה מאות שקלים, לא יותר מידי מאות, אבל זה לא משנה. זה היה יכול להיות גלאקסי 6 או LG בכמה אלפי שקלים. עם פינצטה איכשהו סידרתי את הפינים הנותרים והמכשיר נטען, אם מצליחים בתנועת מנתח לב להכינס את מחבר המיקרוUSB לשקע טעינה. בנקודה הזאת נזכרתי במחבר lightning שמותקן היום בכל מוצר נייד של אפל. רוב משתמשי אפל כלכך התרגלו אליו שכבר לא זוכרים את הימים הקדומים בהם היה להם בתיק כבל מגרפה של מחבר 30 פין. זה היה מחבר די בעייתי, החל מגודלו הפיזי, צריכת חשמל גדולה ביחס לתקנים של היום, היה רגיש לעקמומיות או כיפופים או כל פגיעה פיזית אחרת גם בעת הכנסתו וגם בהוצאתו מן המכשיר. הוידאו שהוא היה מסוגל להוציא היה אנלוגי והיה אפשר להכניס את הכבל רק בכיוון אחד. אני מכיר כמה אנשים שניסו להכניס אותו הפוך, תאמינו לי, זה לא עבד. בספטמבר 2012 אפל הציגו את המחבר החדש (יחד עם אייפון 5), המחבר החדש הוא מחבר דיגיטלי מלא, בדומה לusb ועושה שימוש במספר קטן של חוטי תקשורת (8 לאומת 30) והחידוש הכי גדול והכי שימושי שניתן להכניס את הכבל באיזה כיוון שרוצים! בנוסף, מהנדסי אפל הבינו, שאסור לשים ״לשוניות״,״פינים״, ועוד כל מיני דברים בולטים שנוטעים להתכופף ולהישבר בשימוש יומיומי אגרסיבי והעיפו דברים כאלה משקע בצד של מכשיר הנייד.

עכשיו, יצרני אנדרואידים יקרים, אני פונה אליכם:

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

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

חג סוכות שמח, חברים.

פרוייקט Gelande2: פרק ראשון

1. לפני הכל...

לאחרונה אני התחלתי פרוייקט קטן וחשבתי שיהיה נחמד לשתף אותכם בכל התהליך וגם בתקווה לעזור לאלה שכמוני החליטו להכנס לזה ולא מציאים חומר בנושא, בוודאי בעברית. קודם כל מקווה בשבילי ובשבילכם שיהיה לי די כוח להגיע לפרק ״סיום״ גם בבלוג וגם בכלל. אני תמיד אהבתי להרכיב דגמים של מכוניות ומטוסים ותמיד הייתה לי חיבה גם למכוניות בשלט רחוק ואחרי שגיליתי את התחום, אמרתי לעצמי ״חייבים לעשות גם את זה״. אגב, הגעתי לזה די במקרה, חיפשתי דגם של לנד רובר דיפנדר לאוסף שלי. למי שלא מכיר, דיפנדר זה רכב שטח אמיתי, כזה עם שילדת סולם, לא קרוסובר למדרכות, אפשר להגיד אפילו על גבול הטרקטור מתוצרת חברה בריטית לנד רובר. זה לא רכב שתרצו לנסוע בו בעיר (או אולי אפליו לנסוע בו בכלל), זה רכב שכשאתה נכנס בו אתה חוזר בחזרה אל שנות השמונים. 1983 זאת השנה שבו הרכב הזה יצא לשוק ומאז לא שונה בהרבה בצורתו החיצונית, וגם בפנים השינויים שבוצעו, היו ככורח המציאות ולא איזשהו רצון לחדש. הכי בריטי, הכי שמרני. לא נוח, לא נוסע, רועש, לא הכי אמין בלשון המעטה, יקר ביחס לתמורה...ובכל זאת אני אוהב את הרכב הזה. לדיפנדר יש שני גרסאות עיקריות - 90 (המספר מציין מרווח בין הסרנים) שזו הגרסה הקצרה ו110 הארוכה. גילוי נאות: אין לי שום הכשרה לנהיגה בשטח, בחיים לא נהגתי בשטח, לא היה לי רכב שטח (רכב חברה נחשב?) וכל הידע שלי על הנושא הוא תאורתי בלבד.
כרגע אני לא רואה את עצמי נכנס לתחום רכבי השטח האמיתיים, מאחר וזה תחביב לא זול (אני לא רואה עיין בלנסוע בשבילי יער בן שמן עם המשפחה בשבת, את זה אפשר לעשות עם רוב הליסינגים בלי הרבה כאב ראש). בד״כ, קניית רכב שטח זהו רק שלב ראשון בתהליך ארוך ולא זול בלהביא אותו למצב שהופך אותו לרכב שטח כמו שאתה רוצה, כך שכל העניין הזה אצלי בגדר חלום שאולי יתגשם יום אחד.

2. Gelande  

כפי שכתבתי, את גֵלַנְדֵה (אדמה בגרמנית) מצאתי באיביי בחיפושים אחר דגם 1/24 של דיפנדר. מדובר בקיט של דגם רכב בקנה מידה 1/10 שמיוצר ע״י חברת rc4wd, שזאת חברה שמייצרת מכוניות בשלט רחוק וכל מה שקושור לזה.סוג כזה של מכוניות על שלט נקראים זחלנים (crawler) שמונעים בד״כ במנוע חשמלי ומהירותם נמוכה יחסתי למכוניות מירוץ ומכוניות נייטרו. בזחלנים מה שחשוב זה הטכניקת נהיגה בשטח ולא מהירות ותגובת הנהג. לגלנדה 2 קיימים של דגמי דיפנדר - 90 ו110. בנוסף, כמו כל מכונית ״מקצועית״ (מושג קצת מצחיק לצעצוע, לטעמי) יש שני סוגי קיטים - RTR (ready to run), שבגדול כפי שהשם שלה אומר, כוללת את כל הרכיבים על מנת להרכיב ולהתחיל לנסוע. בפעול זה לא נכון, מאחר ועדיין אתה תצטרך לקנות סוללה, מטען, בודק סוללה, כלי עבודה להרכיב את כל הדבר הזה וכל מיני פיצ׳פקעס כמו חוטים ודבקים. מחירים של הקיטים האלה 750 ו900$ בהתאמה והם בד״כ אף פעם לא במלאי באתר שלהם משום מה ובאיביי כמעט אף פעם לא נמכרים. אני לא כלכך התלהבתי מהקיט הזה מכמה סביות: ראשית, בעיניי הוא קצת מגביל, כי אומנם בסך החלקים החשבון יוצא יותר משתלם, אך החלקים עצמם (מנוע, שלט, אלקטרוניקה ועוד...) הם די בינוניים ואין אפשרות להחליפם במסגרת הקיט. דבר שני, הגוף שלהם מגיע צבוע מראש, לא ניתן להחליף את צבע הרכב והצבע שמגיע לא לטעמי. אם מחברים את כל הדברים ומוסיפים עובדה פשוטה שאין אותם במלאי, אז מקבלים החלטה ללכת על הקיט השני, שעולה 400 ו600$ בהתאמה. כאן אנו מקבלים את השאסי כולל גלגלים וצמיגים, גוף כולל פנים הרכב ו....זהו. גם הקיט הזה out of stock באתר של rc4wd, לכן קניתי אותו באיביי. הלכתי על הגרסה הקצרה, כי בעיניי היא נראת יותר ״קרבית״. 400$ פלוס כ100$ משלוח ומסים שאני עדיין לא יודע את סכומם(קניתי אותו בסוף אוגוסט וכבר כחודש הוא מסתובב בארץ, מכס, דואר).

3. רשימת קניות

אחרי ששמתי יותר מ2000₪ על הקיט אני בעצם קיבלתי דגם של מכונית בקנה מידה 1/10 לא צבוע בלי שום יכולת לנוע או לשלוט. בינתיים, אני גיליתי את עומק התעשייה את מכוניות שלט רחוק. לכל חלק (שאני אפרט בהמשך) יש מוצרים סיניים זולים באיכות ירודה, יש רמה בסיסית ויש את הפרמיום. החלטתי שבחלקים יקרים יותר אני הולך על הפרימיום ובקטנות אנסה את הפשוטים, ואם זה יתברר כזבל (מה שתמיד מתברר כבל, אבל אני כל פעם נופל בזה מחדש), אקנה את הטופ.
זה מה שצריך חוץ מהקיט בשביל להעמיד אחד דיפנדר נוסע (לפני השיפצורים וטיונינג):
אפרט על כל אחד בהמשך:

1. מנוע
2. ESC
3. מקלט
4. שלט
5. סוללה
6. מטען
7. Servo
8. צבעים

מנוע - בזחלנים מתחלק לשני סוגים brushed וbrushless. אני הלכתי על מנוע brushed בגלל מחירו הזול יחסית לסוג השני ויכולתו לעבוד מתחת למים מתוקים (בשלוליות וביצות זה יכול להיות שימושי). מנועים מאופיינים על ידי מספר בסגנון 35,45,55 וכו׳. ככל שהמספר נמוך יותר, המנוע מסתובב פחות מהר, אבל בעל מומנט יותר גבוהה. בזחלנים מהירות לא נחוצה, אך המומנט הוא די חיוני, לכן מומלץ ללכת על המספרים של 35 או 45. אני הלכתי על 35T של חברת טיקין Tekin שהיא חברה שמתמחה בחלקי אלקטרוניקה פרימיום למכוניות שלט רחוק. ליתר דיוק הלכתי על קומבו של מנוע וESC. מה זה  ESC? תמשיך לקרוא.
ESC -  ה״מוח״ של המכונית. זהו הבקר (Electronic Speed Control) אחראי על ויסוט חלק של המהירות למנוע קדימה ואחורה. באיביי יש מלא ESCים סיניים שעולים גרושים, אך אני לא יודע מה איכותם ואיך הם מתנהגים תחת זרם גבוהה (בפורומים די קוטלים אותם) והעדפתי ללכת גם כאן על איכות. הלכתי על FX-R של טיקין.
מקלט - יש מקלטים של 2,3 ו4 ערוצים. ערוץ אחד הולך על היגוי, עוד ערוץ לגז/ברקס. ניתן להתקין אורות ברכב ואז זה עוד ערוץ. יש מטורפים שמפילים וישרים וכאלה שטויות. מקלטים מתקדמים תומכים בAVC זה יותר לרכבי מירץ. מדובר במחשב שיודע למדוד כוחות G ולשלוט בגז בהתאם למהירות ולסיבוב. פחות מדבר בעולם הזחלנים. המקלט הגיע לי בקיט עם השלט (משדר) של ספקטרום שזו חברה מתמחה בתחום השליטה והRF של מכוניות שלט רחוק.

שלט -  עולם השלטים הוא מאוד רחב. פה פשוט הלכתי על מה שממליצים בפורומים Spektrum r4c. זהוא שלט 4 ערוצים שמגיע עם מקלט תואם. קיבלתי אותו, אבל עדיין לא בחנתי אותו. אכתוב על זה בהמשך. בכל מקרה, שלטי פרו יש להם מסך הגדרות וצריך נראה לי לשחק עם זה. עלות - כ550₪ כולל משלוח.
סוללה - מה שהולך היום זה סוללות LiPo - Lithium Polimer. ממה שקראתי, הסוללות הללו מצריכות טיפול מיוחד והפכות להיות לא יציבות כשהן ריקות או טעונות יתר על המידה. אני קצת מפחד מזה (ראיתי כמה סרטונים של סוללות כאלה מתפוצצות), נראה איך אוכלים אותם. בגלל שלסוללות LiPo יש מתח שונה מסוללות NiMh או סוללות רגילות, אנחנו בד״כ נתקלים במתחים של 7.4 וולט לסוללת 2 תאים (פשוט שני סוללות של 3.7 וולט מחוברות במקביל) או 11.1 וולט לסוללה 3 תאים ולכן כל מערכות החשמל והאלקטרוניקה מותאמות לעבוד במתחים הללו. חיוני לשמור על כל התאים מאוזנים, אחרת מתחילים לקרות דברים לא טובים, לכן צריך מטען מאוזן (balanced charger) שבודק בכל רגע נתון מה המתח בכל תא ומווסט את זרם בהתם. בדגם שלי , דיפנדר 90 ספציפית יש בעיה של מקום לסוללה לגובה (19ממ מקס) ולכן הלכתי על סוללה של tunergy של 4500mAh 2cell. בעקרון בהרבה מדינות החוק לא מאפשר שליחה של סוללות בדואר אוויר, ולכן קשה למצוא הרבה מוכרים באיביי ששולחים לארץ. כמובן שלסינים יש פחות רגישות לחוק ולכן משם אפשר לקבל בכיף. בתחום הזה הונדורים המובילים הם Gens ace גרמנית כמדומני, tunergy וvenom. במקור רציתי את gens, רק שאין הסוללות שלהם הם עוברים 20ממ עובי וזה גורם לכך שכל האינטרייר מתרומם ובולט מעבר לחלון בדלת הנהג. לא רציתי שזה יקרה והלכתי על טיונרג׳י בקיבולת קטנה יחסית. אני לא יודע כמה זמן סוללה תחזיק וזה מאוד מסקרן אותי. אעדכן בהמשך.

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

Servo - נחוץ להיגוי של הזחלן. הוא זה שמזיז את מוט ההיגוי בעזרת מתח חשמלי. פה לא שברתי את הראש יותר מידי והלכתי על המלצה מאיזה סרטון ביוטיוב. יש servoים עמודים למים ויש כאלה שלא. לקחתי את הwaterproof. מחירים משתנים בהתאם לאיכות ההרכבה. servoים על מנגנון מברזל יעלה בד״כ יותר מזה מפלסטיק. גם כאן אני עדיין לא יודע להגיד איך זה מתפקד בפועל.

צבעים - גם כאן אפשר בקלות להשתולל. יש צבעי ספריי של טמייה המיועדים למכוניות שלט רחוק עם גוף פלסטיק (לא להתבלבל עם גוף פוליאוריטן) והם נקראים TS או AS. אלו צבעים מסוג laquer והם אמורים לשבת טוב על פלסטיק. אני עשיתי מבחן וקניתי צבע ספריי אפוקסי מאייס בארץ. אחרי 4 שכבות קיבלתי תוצאה משביעה רצון שלי, אך מבחר דל של צבעים גרם לי ללכת בסוף על טמייה. גם כאן יש בעיה על המשלוח וגם כאן יש איסור לשלוח בדואר מיכלים בלחץ. אז או לקנות ממוכר שמוכן לעבור על חוק (בד״כ הם עוטפים את המיכל בנייר כסף), או לשלוח דרך הים. צריך לקחת בחשבון שמיכל אחד של 100מל לא יספיק לכל הבודי וצריך 2-3מיכלים כאלה. (את הגג אני צובע בלבן, לכן הזמנתי מיכל אחד לבן). המחיר של המיכל עצמו הוא מצחיק (6-9 דולר למיכל), אבל המשלוח כפול מהמחיר במקרה הטוב ומשולש ברוב המקרים, לכן אם לא בא לכם לבזבז על זה כסף, אפשר ב20₪ לקנות מיכל של איזה 500מל של צבע באייס ולצבוע באיזי.לפנים הרכב אני כן אלך על צבע מאייס.
בנוסף לכל אלו (אגב, כל זה עולה גם לא מעט כסף), אתם לצטרכו גם סט מברגים/אלנים/מפתחות מתאימים, מאסקינג טייפ איכותי, חוטים רב גידיים נחושת 4ממ אדום ושחור (כמטר בסה״כ), בידוד מתכווץ, מחברים (ארחיב על זה בהמשך),דבק (cement) ורצוי משטח חיתוך.

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

 

פרשת פולקסווגן כמשל על הגדרת ״מאומן״ ו״לא מאומן״

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

אני רוצה להתייחס לנקודה שבה אנחנו קונים מיצרן מוצר/שירות ובד״כ סומכים על המוניטין שלו ועל אמינות שלו ובד״כ מתיחסים לציוד כ״מאומן״ (Trusted הלועזי נשמע הרבה יותר מוכר וטוב) מבלי לתת יוצר מידי חשיבות לעד כמה באמת אנו סומכים עליו.
למשל, אם היה מתגלה שאחת מחברות אבטחת מידע היתה מכניסה תוכנה דומה לזו של VW אשר יודעת לזהות כאשר המוצר נמצא בבדיקות קבלה/עומסים/סטנדרטיזציה ומשנה את הגדרות מערכת על מנת להציג תוצאות טובות יותר על חשבון בטיחות, אני מניח שזו היתה רעידת אדמה בתחום.
עכשיו, זה שעד עכשיו זה לא קרה זה לא אומר שאין כזה דבר, פשוט יכול להיות שעדיין לא תפסו אותם על חם, בנוסף, גם אם יש כזאת תוכנה והיא פועלת, לכם כמשתמש אין הרבה דרכים להתגונן בפני פגיעות כזאת מכיוון שמדובר בקוד שבד״כ נעול.
אבל, לא הכל שחור. דעתי בנושא היא ״In god we trust, everything else should be verified״. מילים כמו Vendor recommended,default security profile,admin,default services כתבותו IP שמוגדרות במכונה במפעל כמו שרתי dns ו ntp בד״כ חייבים לקבל התייחסות מיידית על ידי מתקין/מתפעל המערכת. תמיד חשוב לזכור שלך וליצרן שממנו רכשת את המוצר יש אג׳נדות וסדרי עדיפויות שונים.
הדוגמה הכי בולטת תמיד היא מדיניות הIPS - קנית IPS ואתה לא רוצה ״לבזבז״ זמן (וכסף לאינטגרטור), הרי יש לך default policy! יש שם כל מיני חתימות ומסומנים בכל מיני צ׳קבוקסים, ומה שנשאר הוא לשייך אותו למקום הנכון - פשוט וקל! ממש לא, בד״כ, החוקות/פרופילים הללו לא מגיעים לחצי מהיכולות אמיתיות של המוצר שרכשתם ומותאמות למצב  של PoC או בדיקות ביצועים. כך שנוצר מצב מוזר של אתם שילמתם עבור דבר, וקיבלתם אותו במלואו, אך המשתמשים בחצי ממנו. מה שיותר חמור, הוא שאתם בד״כ חושבים שאתם מוגנים (הרי קניתם את המוצר הטוב בקטגוריה), כשבפועל אתם לא.
 מומלץ להקצות יותר זמן לטובת הפעלת המוצר/פתרון ולהתאים את כל אותם דברים שציינתי, לא לסמוך על הקשחת הציוד ע״י היצרן, אלא לעבור בעצמכם על על אותם דברים כמו פורטים פתוחים,מדיניות משתמשים, החלפת תעודות self-signed (ואם אפשר גם תעודות שסופקו על הציוד) בתעודות שחתומות על ידי גורם מאומן,בדיקה ושינוי במידת הצורך של הגדרות הצפנה (ssl בפרט), שינוי כתובות שרתי dns וntp, להגביל הרשאות גישה של אותו מוצר/פתרון רק לשירותים נחוצים (כגון עדכני תוכן דינמי וגרסאות תוכנה) וכו׳...

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

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

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