יום ראשון, ינואר 15, 2017

הגדרות SSL באתר

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

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




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



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

אתה מאחסן את האתר שלך ולא דאגת ל SSL ? תבדוק מה קורה כאשר ניגשים לאתר שלך באמצעות https:// כי עוד מעט זה יהיה ברירת המחדל (https by default)

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

יום שבת, ינואר 14, 2017

מתארח באתר בו יש נתב מספק האינטרנט ? תחזיק שרת DNS משלך

יש לך נתב/ מודם המסופק ע"י ספק האינטרנט ולא החלפת סיסמאות - צא מנקודת ההנחה שיש לך maleware על הנתב.

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

אם לא פיספסתם היתה מתקפה על נתבי D-Link לפני מספר שבועות ( DnsChanger ), זה ביחד עם זה שנתבים המסופקים ע"י ספקי האינטרנט מכילים הגדרות ברירת מחדל להתחברות, יכול לעשות 1+1 ולהבין שככל הנראה נראה בקרוב מתקפות מתוך הנתבים האלה. אני לא מאמין שמרבית הלקוחות יחסמו את כל המשתמשים שהוגדרו בנתבים שסופקו להם.

היום אני אישית מחזיק שרת DNS משלי, שלדאבוני אינו מוגדר לעבודה אל מול dnscrypt עדיין, הסיבה העיקרית שלא הגדרתי dnscrypt + bind9 היא עצלנות נטו.

מה שצריך לעשות זה:

להתקין dnssec resolver 
להתקין dnscrypt ולהגדיר את proxy_resolver_name למשהוא שיהיה נגיש (תחת /etc/default/dnscrypt-proxy)

ולחכות ליום בו הספקים המקומיים יתחילו לתמוך ב dnssec.

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

יום ראשון, דצמבר 18, 2016

Huawei E8732

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

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

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

מכיוון שחלק מהמחשבים במשרד עובדים עם Win10 ,לא ניתן פשוט להשתמש במודם 3G נורמאלי ;אז נאלצתי לרכוש מודם חדש ומכיוון שהיחיד בחנות שתמך ב"LTE" הוא Huawei  E8732 LTE Wingle הלכתי עליו.

תדרים:
LTE FDD 2600 MHz:
2500 MHz~2570 MHz(Uplink)/2620 MHz~2690 MHz(Downlink)
LTE FDD 1800 MHz:
1710MHz~1785 MHz(Uplink)/1805 MHz~1880 MHz(Downlink)
LTE FDD 700 MHz (B17)
704 MHz~716 MHz(Uplink)/ 734 MHz~746 MHz(Downlink)
LTE FDD 700 MHz (B28)
703 MHz~748 MHz(Uplink)/758 MHz~803 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 1900 MHz:
1850 MHz~1910 MHz(Uplink)/1930 MHz~1990 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 2100 MHz:
1920 MHz~1980 MHz(Uplink)/2110 MHz~2170 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 900 MHz:
880~915 MHz(Uplink)/925~960 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 850 MHz:
824 MHz~849 MHz(Uplink)/869 MHz~894 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS AWS
1710MHz~1755MHz(Uplink)/2110MHz~2155MHz(Downlink)
LTE TDD 2300 MHz:
2300MHz~2400MHz(Uplink/Downlink)
GSM/GPRS/EDGE 850 MHz:
824 MHz~849 MHz(Uplink)/869 MHz~894 MHz(Downlink)
GSM/GPRS/EDGE 900 MHz:
880 MHz~915 MHz(Uplink)/925 MHz~960 MHz(Downlink)
GSM/GPRS/EDGE 1800 MHz:
1710 MHz~1785 MHz(Uplink)/1805 MHz~1880 MHz (Downlink)
GSM/GPRS/EDGE 1900 MHz:
1850 MHz~1910 MHz(Uplink)/1930 MHz~1990 MHz(Downlink)



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

[ 7139.260092] usb 1-1: new high-speed USB device number 10 using ehci-pci
[ 7139.393887] usb 1-1: New USB device found, idVendor=12d1, idProduct=1f01
[ 7139.393902] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7139.393909] usb 1-1: Product: HUAWEI_MOBILE
[ 7139.393915] usb 1-1: Manufacturer: HUAWEI_MOBILE
[ 7139.393920] usb 1-1: SerialNumber: SOMELIE
[ 7139.445451] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 7139.445777] scsi host6: usb-storage 1-1:1.0
[ 7140.209885] usb 1-1: USB disconnect, device number 10

ולאחר קסם ה usb_modeswitch הפך ל (אפס התערבות ממני פרט להכנת קפה):

[ 7141.128083] usb 1-1: new high-speed USB device number 11 using ehci-pci
[ 7141.270518] usb 1-1: New USB device found, idVendor=12d1, idProduct=14db
[ 7141.270533] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 7141.270541] usb 1-1: Product: HUAWEI_MOBILE
[ 7141.270547] usb 1-1: Manufacturer: HUAWEI_MOBILE
[ 7141.448708] cdc_ether 1-1:1.0 eth1: register 'cdc_ether' at usb-0000:00:13.2-1, CDC Ethernet Device, MYMAC
[ 7141.458747] usb-storage 1-1:1.2: USB Mass Storage device detected
[ 7141.459065] scsi host7: usb-storage 1-1:1.2
[ 7141.548519] cdc_ether 1-1:1.0 enxMYMAC: renamed from eth1
[ 7142.465769] scsi 7:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[ 7142.469366] sd 7:0:0:0: Attached scsi generic sg1 type 0
[ 7142.488979] sd 7:0:0:0: [sdb] Attached SCSI removable disk

פלט ה lsusb הוא :


Bus 001 Device 011: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

לצערי הזיהוי שגויי אבל בשביל זה מספיק טוב (כי זה עובד !).

שימוש בקוד פתוח :

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

אני לא יודע אם זה נחשב או לא GPL Violation או לא אבל זה נראה מסריח.

ע"פ הרישיונות יש שימוש במקטעים מ :

Android
OpenSSL
SSLeay
BusyBox
libsepol
iproute
bridge-utils
libnl
Samba
siproxd
zlib
osip
cups
MiniUPnP
FUSE
ועוד ...

DNS שבור :

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

וי-פי :

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

צריכת חשמל :

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

שימוש בWin10 :


Win10 זיהה את המכשיר והצליח להתחבר גם כethernet וגם ב WiFi.


שימוש בדביאן :


מהירות באחת מחברות האפ"ס (מדווח כ LTE) :
Monitoring wlan0...    (press CTRL-C to stop)

 wlan0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   264.80 MiB  |       10.04 MiB
--------------------------------------+------------------
          max           11.96 Mbit/s  |      403 kbit/s
      average            2.97 Mbit/s  |   112.71 kbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                     196744  |          105121
--------------------------------------+------------------
          max               1061 p/s  |         575 p/s
      average                269 p/s  |         144 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                 12.17 minutes


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

אני מציין כי אין LOS כי אני רואה בערך איפה האנטנה אמורה להיות (לפי המיפוי היא נמצאת על גג המבנה)  אבל אני לא מצליח לזהות אותה על הגג המבנה.

יום ראשון, דצמבר 11, 2016

הגדרת ברירת מחדל

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

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

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

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

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

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

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

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

והחלק הכי חשוב שמות משתמש וסיסמא ברירת מחדל : Admin/admin  , support/support , user/user

יום שבת, דצמבר 03, 2016

Office365 mount forbidden

לצערי לא ניתן יותר להשתמש ב davfs2 בשביל לעגון תוכן משותף שיושב על office365 (שיתוף ע"ג sharepoint). גם תוכנות קוד פתוח דוגמת cyberduck נכשלות כשלון חרוץ , קונקי וחבריו לא הצליחו לתת לי פתרון סביר ללא מאמץ.

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

מניסיון העבר sharepoint בדר"כ משתמש בפרוטוקול webdav[s] וזה פשוט עובד מהקופסא, גם בויינדוס וגם בדביאן/רד האט.

יש מערכות שאתה צריך להזדהות פשוט ב http basic באחרות קרברוס ויש כאלה שדורשים OAuth. אבל ככל זה פשוט עובד. 

בעבר הייתי משתמש בcadaver ו mount.davfs2 בשביל העיגון :

עבור webdav אני משתמש ב davf2 ובשביל לעגן את החומר המשותף של VSA תחת 9.17.232.196 מספיק לשמור את פרטי ההתחברות ב  ~/.davf2/secrets כמו :

http://9.17.232.196/sites/VSA/ schenzel myPaSSwoRd

ואז פשוט ב cadaver או mount.

הפעם הדומיין שלי הוא example תחת sharepoint.com:

וניסיתי לשמור את הפרטים בצורה של  :
https://example.sharepoint.com/sites/VSA/ schenzel myPaSSwoRd

וזה נכשל עם שגיאה 403, גם ניסיון גישה באמצעות cadaver או אפילו גישה ל webdavs://example.sharepoint.com/sites/VSA בקונקורר נותן וריאציות של 403.

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

x-msdavext_error: 917656;
 Access+denied.+Before+opening+files+in+this+location%%2c+you+must+first+browse+to+the+web+site

הפתרון ? להתחבר ל https://example.sharepoint.com  באמצעות משהוא שיוכל לשתף עוגיות עם התוכנה איתה אתם מתחברים לרכיב (נגיד konqueror).

במקרה של konqueror מספיק פשוט להתחבר ל https://example.sharepoint.com ואז ניתן לגשת לכל הדברים המשותפים באמצעות webdavs לדוגמא ל:
webdavs://example.sharepoint.com/sites/VSA 

בגלל שמדובר על עוגיות והדומיין של העוגייה הוא example.sharepoint.com אז ניתן להשתמש בעוגיה עבור כל האתרים המשותפים (שנמצאים תחת sites/SITE_NAME). 

התיקיות שמעניינת אותי  בדר"כ זה (בהנחה שקוראים לsite כ VSA) :

webdavs://example.sharepoint.com/sites/VSA/Shared%20Documents/

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