יום שלישי, מרץ 21, 2017

כל הכבוד לספק הטלפוניה שלי

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

שנים האמנתי שלא שניתן לשבור Cell Broadcast וגם ערוץ נתונים בזמן חירום, אבל אני חייב להגיד לספק הטלפוניה תודה שלימדתם אותי שזה אפשרי - מתברר שיש אנשים שיכולים להרוס Public Warning System שעובדת שנים.

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

בהתחלה האשמתי את systemd שהוא לא הפעיל נכון, או לא הפעיל כלל את ה timer והservice.

לכן בדקתי שהקבצים במקומות הנכונים ושהכל תקין מבחינתו:

find /etc/systemd/system/  -name *pws* -print
/etc/systemd/system/pws.timer
/etc/systemd/system/timers.target.wants/pws.timer
/etc/systemd/system/pws.service

$cat /etc/systemd/system/pws.timer 
[Unit]
Description=Public Warning System Timer

[Timer]
OnUnitActiveSec=5s
OnBootSec=100s

[Install]
WantedBy=timers.target

$cat /etc/systemd/system/pws.service
[Unit]
Description=Public Warning System Alert

[Service]
Type=oneshot
ExecStart=/bin/bash /usr/local/bin/parse_alerts.sh http://pws/WarningMessages/Alert/alerts.json

$systenctl status pws.timer
● pws.timer - Timed alert check
   Loaded: loaded (/etc/systemd/system/pws.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2017-03-21 11:06:50 IST; 1s ago

Mar 21 11:06:01 pc systemd[1]: Started Public Warning System Timer


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


הקו שאני מדבר עליו מתחבר ב UMTS תחת דור ה "3.5G".
התחברות מבוצעת ע"י wvdial.

ביצעתי מספר בדיקות להבין מהיכן מגיעה הבעיה בערוץ הנתונים :

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.255.238 icmp_seq=17 Packet filtered
^C
--- 8.8.8.8 ping statistics ---
157 packets transmitted, 0 received, +1 errors, 100% packet loss, time 159696ms

חשוב לזכור שהכתובות אצל ספק הטלפוניה שלי הן תחת 10.144.0.0/16 המשכתי לראות מאיפה זה מגיעה וקיבלתי :
mtr --report-wide --show-ips 8.8.8.8
Start: Tue Mar 21 11:46:45 2017
HOST: pc        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- 10.192.192.149  0.0%    10   49.7  59.7  46.8  92.0  16.7
  3.|-- 10.192.192.150  0.0%    10   48.5  64.9  47.0  92.7  18.7
  4.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0


ping 192.168.255.238
PING 192.168.255.238 (192.168.255.238) 56(84) bytes of data.
64 bytes from 192.168.255.238: icmp_seq=1 ttl=253 time=285 ms
64 bytes from 192.168.255.238: icmp_seq=2 ttl=253 time=303 ms
64 bytes from 192.168.255.238: icmp_seq=3 ttl=253 time=272 ms

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.6.6.6        0.0.0.0         UG    0      0        0 ppp0
10.6.6.6        0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

mtr --report-wide --show-ips 192.168.255.238
Start: Tue Mar 21 11:40:55 2017
HOST: pc         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???             100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- 10.192.192.149   0.0%    10   51.1  52.2  48.7  55.9   2.4
  3.|-- 192.168.255.238  0.0%    10   57.2  63.5  50.1  93.7  16.0

sudo nmap -sV 192.168.255.238 

Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-21 11:37 IST
Nmap scan report for 192.168.255.238
Host is up (0.064s latency).
Not shown: 999 closed ports
PORT     STATE    SERVICE     VERSION
5222/tcp filtered xmpp-client

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 294.32 seconds


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

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

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

לא משנה ששלחתי קובץ pcap  ויש לי כתובת IP (שמגיבה כמו גדולה בתוך הרשת שלהם)

צילום מסך :




לאחר שלא הסתדרתי עם ספק הטלפוניה התחלתי לגגל לגבי CB.

 ומתברר שתאוריתית ניתן לקבל את זה דרך gammu (לא פלא , gammu יודע לעשות המון דברים גם ככה) :
פה יש תסריט דרך gist : 

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

יום רביעי, פברואר 22, 2017

KDE@HTML5


היום בעידן הHTM5 אחד הדברים שאני נהנה לראות זה התחברות מרחוק למערכת ע"י דפדפן בלבד, יש את זה אצל vmware ויש את זה בxen אבל פה מדובר על vnc.

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

המערכת עובדת ע"י הפעלת x11vnc בשביל להתחבר לsession קיים (בשונה משרתי vnc אחרים שמאפשרים חיבור ל session נוסף פה מדובר על הססן הנוכחי), בחרתי ב x11vnc ולא ב krfb כי x11vnc היה הרבה יותר מהיר.


apt-get install x11vnc
git clone git://github.com/kanaka/noVNC

יש להגדיר לx11vnc סיסמה  x11vnc -storepasswd

הפעלה ע"י תחת המשתמש שצריך לשתף את הססן שלו:


screen -d -m bash -c "x11vnc -shared  -rfbauth ~/.vnc/passwd"

screen -d -m bash -c "~/noVNC/utils/launch.sh --vnc localhost:5900"

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

הלקוח בדוגמה שלי הוא פיירפוקס 51 אבל זה נבדק גם אם Edge עדכני.

יום שלישי, פברואר 21, 2017

KDE@WIN10

הפעלת אפליקציות של KDE תחת Win10:




יש להפעיל את windows subsystem for linux   ב windows 10 , מה שידוע גם כאפשור lxss.

תחת וינדוס 10 לאחר איפשור של lxss התקינו ubuntu (הריצו bash)  ב cmd.
התקינו את KDE:
sudo apt-get install kubuntu-desktop
 
התקינו את xming הישן והטוב.

עירכו את הקובץ /etc/dbus-1/session.conf ושנו בו חלק האזנה ל tcp:host=localhost,port=0
זה יראה כך:
<listen>tcp:host=localhost,port=0</listen>
 
תחת bash for windows הריצו :

export display=:0

באותו המסוף בשביל להפעיל אפליקציות שדורשות dbus (כל מה שיש תחת KDE)הפעילו

export $(dbus-launch)

אחרון חביב הוא kstart plasma-desktop על מנת להפעיל את סביבת פלסמה.


המינוסים העיקירים :

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

יום ראשון, ינואר 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 שלי המאוחסן במקום שעליו אני סומך יותר.