Bandbreitenmessung in der Konsole

Man weiß mal wieder nicht, wieso der Download so lange dauert und man würde gern nachsehen was los ist. Mal abgesehen von der Fremdwirkung aka „Freundin beim YouTube quälen erwischen“, kann natürlich auch die Leitung gestört sein.

Also erstmal checken, ob man überhaupt eine Chance hat

Ab hier sind wir ROOT , da wir nur so an die nötigen Informationen ran kommen.

Mit iotop können wir erstmal nachsehen ob unser Rechner nicht durch IO ausgelastet ist:

Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
 3629 be/4 root        0.00 B/s    0.00 B/s  0.00 %  2.32 % [kworker/0:0]
  262 be/4 root        0.00 B/s    0.00 B/s  0.00 %  2.30 % [kworker/2:2]
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd --switched-root --system --deserialize 24
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
 2052 be/4 marius      0.00 B/s    0.00 B/s  0.00 %  0.00 % nautilus -n [gdbus]
    5 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]

Wie man leicht erkennen, hatte ich bei meinem Aufruf keine IO irgendeiner Art auf dem Laptop. Sehr gut so, CHECK.

Als nächstes prüfen wir mal die Leitung ins Netz mit MTR:

# mtr --report-wide bloggt-in-braunschweig.de
 Start: Thu Sep  8 17:38:16 2016
 HOST: warrior                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- fritz.box                 0.0%    10   18.6  16.8   3.2  20.8   4.8
 2.|-- 217.0.119.85              0.0%    10   18.5  19.5  17.8  27.3   2.8
 3.|-- 217.0.65.254              0.0%    10   21.5  18.5  17.4  21.5   1.1
 4.|-- 217.239.44.22             0.0%    10   25.6  27.7  23.3  54.6   9.6
 5.|-- cr01.h.as24679.net        0.0%    10   45.0  36.8  34.5  45.0   3.3
 6.|-- ar13.h.as24679.net        0.0%    10   64.1  61.7  34.9 144.7  31.9
 7.|-- bloggt-in-braunschweig.de 0.0%    10   34.3  34.8  34.1  35.7   0.3

Ok, die Leitung raus ist auch ok, kein Paketloss .. CHECK

Die billigste Bandbreitenmessung schlechthin: Mit wget eine große Datei abholen.

BEENDET --2016-09-08 17:47:47--
Verstrichene Zeit: 2,9s
Geholt: 7 Dateien, 121K in 0,1s (1,06 MB/s)

Am Ende des Wget-Aufrufs bekommt man die Geschwindigkeit angezeigt. (Ja, das WLAN im Hof ist nicht das schnellste 🙂 ) Wenn man jetzt eine große Datei, sagen wir mal 100MB holt, hat man ein belastbares Ergebnis. Das habe ich jetzt natürlich nicht gemacht 🙂

Alle mir bekannten Tools, und das sind nicht viele, nutzen auch nur wget mit einigen Testservern aus. Aber Bandbreite kann man ja auch anders messen .. z.B. mit bmon !

Was geht ab!

Deutlich genauer kann bmon anzeigen, wieviel Bandbreite auf welchem Interface gerade genutzt wird:

Darstellung eines bmon fensters

bmon zeigt neben den einzelnen Interfacen auch Angaben zu QOS Einstellungen aka Trafficshaping auch Statistiken für die aktuelle Werte der Netzwerkkarten an ( Taste i ). Für die Konsole ist das eine sehr praktische Zusammenfassung. Ausgewachsene Masochisten werden allerdings ifconfig auswerten wollen, daß uns diese Daten auch gibt (sortof 😀 ) :  watch -n 0,5 „ifconfig “

[root@eve marius]# ifconfig
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.44  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::4216:7eff:fe24:a01  prefixlen 64  scopeid 0x20<link>
        ether 51:23:09:1a:44:16  txqueuelen 1000  (Ethernet)
        RX packets 2083577  bytes 2706797719 (2.5 GiB)
        RX errors 0  dropped 351  overruns 0  frame 0
        TX packets 1243333  bytes 218434352 (208.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Lokale Schleife)
        RX packets 775  bytes 42829 (41.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 775  bytes 42829 (41.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 51:23:09:1a:44:16  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Wenn man nun selbst grade nichts wissentlich zieht und die Bandbreite trotzdem hoch ist, wird man auf netstat oder iotop ausweichen müssen um den Täter zu ermitteln. Schauen wir uns netstat mal an :

[root@warrior marius]# netstat -lnap | grep -i verbunden  | grep -v unix    
tcp        0      0 192.168.0.103:51438     192.0.78.23:443         VERBUNDEN   3396/firefox        
tcp        0      0 192.168.0.103:48760     192.168.0.34:22         VERBUNDEN   3970/ssh            
tcp        0      0 192.168.0.103:41712     54.149.28.204:443       VERBUNDEN   3396/firefox        
tcp6       0      0 192.168.0.103:35104     83.246.80.153:5222      VERBUNDEN   2028/java

Mit der Anzeige sehen wir, welche zwei Rechner mit welchem Programm grade Daten austauschen. Wenn in Spalte 2 und 3 statt 0 etwas großes drin steht, dann geht da datenmäßig grade richtig was ab, denn das sind die Sende- und Empfangsqueues der Verbindung. Das sind kleine Puffer für Daten, die nicht schnell genug geschrieben oder gelesen wurden.

iotop wird uns dagegen verraten, wer grade wieviel IO macht und Netzwerkverkehr ist auch IO 🙂  So oder so, wir kriegen raus was da läuft.

Im nächsten Artikel geht es dann um weitere Netzwerktools, wie Iptraf, ifstat,vnstat usw..

Vertraue keinem, schon gar nicht Deinem Browser

Man sollte nie, nie nachsehen was sein eigener Computer so treibt, denn es könnte einem nicht gefallen! Genauer gesagt, es macht einem einfach nur Sorgen.

Ich dachte immer Skype wäre verantwortlich…

… was schlimm genug wäre, weil Skype Verbindung wie ein Grippevirus auf den ganzen Planeten verteilt. Wie sich heraus gestellt hat, ist FireFox noch schlimmer. FF hält einfach mal eine offene Verbindung zu Google auf, nur das keiner weiß was da transportiert wird. Man kann nur annehmen, daß es sich um eine hängende Verbindung der Googlesuche handelt, aber sicher kann man sich da nicht sein.

Aber die Krönung meiner kleinen Inspektion des Desktoptraffics war das hier:

tcp        0      0 192.168.0.44:59734      98.137.200.255:80       VERBUNDEN   1929/cinnamon

Oh ja, DER Cinnamon-Desktop selbst wars. Wie eine Recherche gezeigt hat, ist das Problem seit 2013 bekannt. Das Wetter-Applet ist zu blöd!!! die Verbindung zum Yahoo-Wetterserver sauber zu beenden. Also wird, genau wie im Fall der Googlesuche oben, einfach alle paar Sekunden ein KEEP-ALIVE Paket ausgetauscht. Völlig nutzloser Traffic!

Nie Nachsehen, wenn ihr nicht stundenlang Dinge prüfen wollt

Mehr kann man dazu nicht sagen, außer natürlich der Frage: „Wie bist Du da überhaupt drauf gekommen?“

Antwort: „HAK5“

In einer der Hak5 Sendungen ging es um Bandbreitenmessungen. Welche Tools es da gibt, steht in einem anderen Artikel, der morgen kommt : Bandbreitenmessung in der Console

WinSec: Zugangsdatenhash in unter 2 Sekunden geklaut

Der Rechnerarbeitsplatz ist verwaist, der Screensaver mit Passworteingabe saved so vor sich in, und doch sind die Logindaten jetzt bei jemand anderem?

Was nach Magie klingt, ist lediglich das Ausnutzen von aktuellen Mechanismen unter Windows, MacOs und vielleicht auch Linux. Der Angreifer ist dabei ein kleiner USB Stick, der sich als Netzwerkkarte ausgibt und eine schnellere und bessere Netzwerkanbindung verspricht, als die Netzwerkkarte zu bieten hat. Akzeptiert das Betriebssystem die neue Netzwerkkarte als besser, trennt es die bisherigen Netzwerkverbindungen auf und erstellt über den neuen Link sofort neue Verbindungen.  (DHCP ist da nicht ganz schuldlos dran.)

Was kann dabei schon schief gehen, ist doch alles verschlüsselt !

Ja, was kann da schon schief gehen, wenn man sich als SMB Client, Unixern besser bekannt als Samba, als ein Netzwerklaufwerk neu an einem Netzwerkgerät anmeldet ? Na, das Passwort wird erneut übertragen, was im Fall von Samba ein Passwordhash ist und der ist bei Nativem Windows, wer hätte es erraten, nicht sicher. Deswegen Blocken Router Samba auch per Default, damit es keine Passwörter und Usernamen verrät. Ja, der Username wird in Klartext übermittelt 😀

Der Gag am Rande, SMB schickt den Usernamen und Hash unaufgefordert zum Netzwerkgerät, selbst wenn man da noch nie angemeldet war, weil es könnte ja einen User mit dem Passwort dort geben und dann soll der verdammt nochmal auch gleich das Laufwerk benutzen können.

SMB Entwickler: Laßt Euch von der Marketingabteilung nicht immer alles  gefallen, Ihr Weicheier ! Steht auch mal für ein „Nein, ist uns zu unsicher.“ ein !

Wer wars, was benutzte er dazu ?

Hacker Mubix beschreibt in seinem Beitrag wie er mit einer 50 US$ Hardware den Angriff in 15 Sekunden durchführt. Dazu läuft auf dem USB Stick ein Minicomputer mit Linux der einen Sambashare simuliert und einfach alle IPs bedient.

Besser verständlich ist allerdings ein Video von Hak5 über einen anderen Angriff, der die gleiche Lücke von SMB ausnutzt, aber nur funktioniert, wenn der User eingeloggt ist. Dafür braucht er nur 1,5 Sekunden dafür, und dafür reicht schon ein simples Ablenkungsmanöver.

Gegenmaßnahmen

So leid es mir tut, dies zu sagen, aber außer Ausschalten hilft da nichts, weil aus einem Standby könnte der Angreifer den Rechner rausholen, die Netzwerkkarte zu deaktivieren und damit das Netz lahmlegen nutzt auch nichts, weil das USB Gerät ist ja eine Netzwerkkarte und genau die will das OS haben.  Man müßte schon in Windows das automatische akzeptieren von USB Geräten abschalten. Lustigerweise wird das für Storage-Sticks auch gemacht, aber eine USB-Ethernetkarte ist halt kein Storage-Stick 😀  Mal sehen ob M$ ein Einsehen hat und einen Patch rausbringt, daß wenn der Screensafer läuft, keine Automatismen greifen.