Directcopy mit SSH

Für alte SSH Hasen ist es nichts Unbekanntes, daß man von einem dritten PC aus, direkt Files zwischen zwei anderen SSH-Servern hinundher kopieren kann. Dazu muß lediglich zwei vollständige Logins angeben:

scp user@server1:/path/foo user@server2:/path/

Solange man die schwache Passwortauthentifizierung benutzt, bekommt man zwei Abfragen zu den Passwörtern der beiden Zugänge. Nachvollziehbar, weil Server 1 das Passwort für Server 2 nicht kennt.

Was aber, wenn man das nicht mehr benutzen kann, weil man sich nur noch mit Key authentifizieren kann ?

Der erste Server, dem man das Kommando zum Kopieren von Daten gibt, akzeptiert klaglos den Schlüssel den unser SSH-Agent ( das ist der Gnome-Keyring-Manager der bei Euch auf dem Desktop läuft ) zur Verfügung stellt. Damit kann man zwar das Kopieren starten, wird sofort ausgebremst, weil Server 1 das Passwort von Server 2 wissen will.

Wenn Server 2 jetzt auch nur noch Keys akzeptiert, weil die PasswortAuth im SSHD deaktiviert wurden, und das solltet Ihr immer einstellen:

PermitRootLogin without-password

Dann habt Ihr ein Problem, denn den nötigen Key kann man nicht vom heimischen PC zum ersten Server senden und dann zur Auth bei Server 2 nutzen.  Um das zu umschiffen gibt es eine unschöne Lösung, die „mal“ geht, wenn es sich um wenige Daten handelt: die Option “ -3 “ (Minus Drei) .

Diese Option sagt SCP , daß es die Daten erst zum eigenen PC überträgt und dann erst zum Server 2. Man kann also nicht mehr von einem Directcopy reden. Am spart sich so lediglich, daß die Dateien erstmal im Temp-Ordner vom System landen und später von Hand gelöscht werden müssen. So gesehen, macht es den Kopierprozess schon einfacher.

Die Lösung mit den Bauchschmerzen

Das es SSH-Agenten gibt, hatte ich ja schon erwähnt. Auf einem normalen Server kann man das Tool auch mit genau dem Namen starten : ssh-agent . Das Programm installieren wir auf Server 1 und rufen es auf. Es gibt uns einige Umgebungsvariablen aus :

#!/bin/bash
SSH_AUTH_SOCK=/tmp/ssh-tqJtR00AWwOq/agent.2040; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2048; export SSH_AGENT_PID;

Die müssen wir z.B. mit „export“ aktivieren, damit ssh den ssh-agent findet. Das obige Beispiel ist aus einem kleinen Script, daß beim Starten der Root-Shell ausgeführt wird. Damit ist man dann als Root automatisch an den ssh-agenten gebunden und muß sich nicht mehr um diese Details kümmern. Da man dem ssh-agent sagen kann, wie lange die Authentifizierungsdaten gecached werden sollen, kann man z.B. den ganzen Tag ohne Eingabe von Passwörtern für Keys arbeiten.

Auszug aus der /root/.bashrc

# Source ssh user agent
if [ -f /root/.sshagent ]; then
        .  /root/.sshagent
fi

Damit eröffnet sich eine Möglichkeit, die Daten von Server 1 auf Server 2 direkt zu kopieren, ohne schwache Passwörter benutzen zu müssen.  Man aktiviert also auf dem Server 1 den RSA/DSA – Schlüssel/key  für Server 2 im ssh-agent und kann dann mit SCP den ganzen Tag Aufträge verteilen.

ssh-add -i /path/foo/key.rsa

Wenn man Keys nutzt, sollte der jeweilige Key noch mit einem Passwort gesichert sein, damit nicht jeder den Key, so er denn erbeutet wurde, benutzen kann.

Und wieso Bauchschmerzen ?

Wenn man vernünftig Arbeiten will, muß der Agent die Authdaten mal min. für einen Arbeitstag cachen. Je länger desto mehr Bauchschmerzen sollte man bekommen, denn in der Zeit könnte jeder, der auf dem Server root wird, sich ungestört in allen Systemen einloggen oder Daten kopieren, zu denen der Schlüssel Einlass gewährt. Der Vorgang das einer Root wird, ist natürlich schon Horror pur, aber wenn die ganze Serverfarm betroffen ist, also wer bei dem Gedanken keine Bauchschmerzen bekommt, dem kann man nicht mehr helfen.

Wenn so ein Server sicher ist, braucht man natürlich keine Bauchschmerzen haben, aber bei den vielen Bugs die in allem möglichen drin ist…. puhh.. Ein bisschen Angst schwingt immer mit. Das mich keiner falsch versteht, ich liebe meinen ssh-agent, aber ich nutze ihn nur, wenn es unbedingt sein muß 🙂

Der logistische Teil

Der ssh-agent müßte auf allen Servern laufen und dort den Schlüssel aktiviert haben, von dem Daten irgendwohinanders kopiert werden sollen. Das kann im Detail recht aufwendig werden, wenn man nicht überall den gleichen Key benutzt.

Das es keine so gute Idee ist, überall den gleichen Key in jede Richtung zu benutzen, sollte Euch klar sein.

Diese Woche im Netz

In Los Angeles wurde erstmalig ein bewaffneter Mann von einem Roboter  entwaffnet. Die Polizei lenkte dazu den Schützen auf der einen Seite ab, während ein Bombenräumroboter sich von der anderen Seite anschlich und die Waffe an sich nahm, wie immer man sich das genau „anschleichen“ vorstellen muß 🙂

Quelle: Ars Technica

Angreifer können einen Tesla Model S  während der Fahrt stoppen. Tolle Aussichten, wie kann man nur son Scheiss auf die Straße schicken!

Quelle: Golem

„Sie hält es nicht länger aus, Captain Kirk!“ – Peinlich – Neuestes US Kriegsschiff USS Zumwalt nach Wassereinbruch wieder im Trockendeck.

Quelle: The Register

In 52 Stunden quer durch die USA, mit einem Tesla ! 13h Tankstops inklusive 🙂

Quelle: Ars Technica

Die wahren Kosten von SSL-Zertifikaten offenlegen ? Let’s Encrypt hat das getan und bestätigt, was viele Kunden schon immer dachten.

Quelle: Golem.de

DDOS Angriff auf Brian Krebs Webpage

Wie Brian Krebs, ein bekannter Security Journalist, auf seiner Webseite bekannt gab, fand gestern der größte je von Akamai gemessene DDOS Angriff auf seine Webseite statt. Die von den Angreifern eingesetzte Bandbreite lag bei erstaunlichen 620 GigaBit / s . Der Angriff konnte von Akamai soweit abgewehrt werden, war aber wohl „dicht“ am Limit.

Mehr dazu gibt bei Brian Krebs im Blog.

Lenovo & Microsoft sperren Linux aus

Microsoft liebt Linux ? wohl kaum. Die neusten Gerüchte und Berichte deuten eher auf eine Verschwörung gegen Linux hin, denn Microsoft hat Lenovo zu einem Windows-10-Only-Deal für eine Laptopserie  gebracht.

Die Ultrabooks der Yoga 900 Serie sind technisch in einem Zustand, in dem nur Windows 10 damit umgehen kann. Laut einem Bericht der HackerNews wurde die SSD in einen properitären Raidzustand gebracht, so daß andere Betriebssysteme diese nicht ansprechen können.

Aufgedeckt hat das ein Reddit User namens BaronHK, dem es am Ende aber gelang, die SSD zu reseten und damit wieder für Linux erreichbar zu machen. Von einem Kauf ist aber grundsätzlich abzuraten, da sowas natürlich nicht noch gefördert werden muß.

Lenovo Mitarbeiter haben das Verhalten bestätigt und erklärt, daß es auf einen Deal mit Microsoft zurück geht.

Fazit: Microsoft bleibt der Feind, der er immer war und Lenovo würde ich eh nicht kaufen 😉

Der vollständigkeithalber sei erwähnt, daß es auch Berichte gibt, in denen Lenovo eine Verschwörung bestreitet: SlashDot

Im TheHackerNews Artikel wird allerdings ein Post einer Lenovomitarbeiters verlinkt, der das Gegenteil zu beweisen scheint.

Update 11:43 Uhr:

Die Sache schlägt in den Medien so einige Wellen. Für Euch ungefiltert die Links, die ich so gesehen habe:

GNOME:  http://mjg59.dreamwidth.org/44694.html
Heise:       http://www.heise.de/newsticker/meldung/Lenovo-und-Microsoft-blocken-Linux-Installation-auf-Notebooks-wohl-nicht-absichtlich-3329244.htmlGolem:     http://www.golem.de/news/fehlende-treiber-intel-verhintert-linux-installation-auf-lenovo-laptops-1609-123393.html
SlashDot:  http://rss.slashdot.org/~r/Slashdot/slashdot/~3/TVPj3XjkwvE/lenovo-denies-claims-it-plotted-with-microsoft-to-block-linux-installs
The Register: http://www.theregister.co.uk/2016/09/21/lenovo_denies_plot_with_microsoft_to_block_linux_installs/

Zu guter Letzt, der Auslöser der Sache: Reddit.com

https://www.reddit.com/r/linux/comments/53ri0m/warning_microsoft_signature_pc_program_now/

Netzwerktools: Iptraf, ifstat, vnstat, Ping & Pong

Im Artikel über Bandbreitenmessungen in der Konsole habe ich Euch ja angedroht, daß es eine Fortsetzung gibt 🙂

Fangen wir mal mit der einfachsten Fragestellung im Netzwerk an:

Habe ich überhaupt ein Netz ?

Dazu fragen wir den Netzwerkstack( ab jetzt nur noch TCP/IP Stack) von Linux mit „ip link“, ob wir überhaupt eine aktive Netzwerkkarte haben, wie man sich denken kann, wird das ohne Netzwerkkarte ein Problem.

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 40:66:3e:21:1a:76 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:0a:cf:07 brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:0a:cf:07 brd ff:ff:ff:ff:ff:ff

Wir erhalten eine Liste aller nützlichen Interface (Netzwerkadapter) mit Ihrem jeweiligen Status.

Das hier als 1 bezeichnete Interface heißt „lo“ und ist das Loopback Device besser bekannt mit seiner StandardIP 127.0.0.1 . Es ist von außen nicht erreichbar und nur für intere Zwecke da. Ein Unixrechner ohne 127.0.0.1 ist mir nicht bekannt 😉 Das Loopback Device wird für diverse Zwecke gebraucht u.a. das mounten von Truecryptcontainern und Netzwerktunneln.

An zweiter Stelle kommt in unserer Liste das „enp2s0“ früher mal als „eth0“ bezeichnet. Heute kommen die Bezeichnungen vom Kernel und zwar nicht direkt zufällig, aber meisten eine Zusammenstelung aus Devicenamen und Ports des Chips der für das Interface verantwortlich ist. Es kann bei jedem anders aussehen, wenn es Lust hat. Man kann es über den „udevd“ auch wieder in eth0 ummünzen, wenn es einem den Aufwand Wert ist.

Für uns ist es das wichtigste Interface, denn es stellt unsere Netzwerkkarte dar. Der „State UP“ meint, daß es „up and running“ ist, also eingeschaltet und funktioniert und das ist genau was wir wollen.

CHECK: Karte vorhanden und aktiv.

Schauen wir uns das Interface genauer an. Dazu brauchen wir „ifconfig“ , es geht auch mit „ip“, aber warum sich quälen 😉

$ ifconfig enp2s0
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.123.234  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::4315:7eff:ee23:0b15  prefixlen 64  scopeid 0x20<link>
        ether 40:66:3e:21:1a:76 txqueuelen 1000  (Ethernet)
        RX packets 368476  bytes 109880955 (104.7 MiB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 499987  bytes 598240703 (570.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Dieser Anzeige können wir entnehmen, daß unsere IP 192.168.123.234 ist, unsere Netzwerkmaske 255.255.0.0 und wie unsere MAC Adresse lautet: 40:66:3e:21:1a:76 . Das ist konkret nicht wichtig, aber wenn Ihr mal Probleme habt einen Rechner im LAN zu erreichen, ist die MACADRESSE der Netzwerkkarte extrem wichtig.

Wie man auch sehen kann, gibt es eine IPv6 Adresse, aber die ist quasi fiktiv, weil nicht es gar nicht konfiguriert ist.

CHECK: Wir haben eine IP Adresse auf der Netzwerkkarte und eine korrekt Netzwerkmaske!

Nun prüfen wir noch, ob die Netzwerkkarte überhaupt irgendwo angeschlossen ist ( Klar geht das von Innen) :

$ ethtool enp2s0 | grep -i detected
    Link detected: yes

Stände da jetzt „no“ , wäre kein Kabel drin, bzw. die Gegenstelle z.B. Router / Switch usw. nicht eingeschaltet.

CHECK: Link detected! Die  Karte ist mit einer anderen Netzwerkkarte über ein Kabel verbunden!

Ping & Pong ?

Mit dem Befehl Ping kann man alle Rechner im LAN „anpingen“, also anstupsen,  die im gleichen Netzwerksegment liegen. Dies meint, daß Sie in der Netzwerkmaske unserer Netzwerkkarte ihre IP Adresse haben UND selbst eine Netzwerkmaske haben, die unsere IP einschliesst. Wie man das berechnet, könnt Ihr im Netz nachlesen.

Für das Beispiel oben war die Netzwerkmaske 255.255.0.0 was meint : mußgenaustimmen.mußgenaustimmen.egal.egal , womit 192.168.0.0 -> 192.168.255.255 abgedeckt sind. Also pinge ich jetzt mal meinen Router an:

$ ping 192.168.123.1
PING 192.168.123.1 (192.168.123.1) 56(84) bytes of data.
64 bytes from 192.168.123.1: icmp_seq=1 ttl=64 time=0.428 ms
64 bytes from 192.168.123.1: icmp_seq=2 ttl=64 time=0.332 ms
64 bytes from 192.168.123.1: icmp_seq=3 ttl=64 time=0.333 ms
64 bytes from 192.168.123.1: icmp_seq=4 ttl=64 time=0.324 ms
64 bytes from 192.168.123.1: icmp_seq=5 ttl=64 time=0.354 ms
64 bytes from 192.168.123.1: icmp_seq=6 ttl=64 time=0.406 ms

Wunderbar, er antwortet UND es kommt nicht zu Aussetzern bei der Sequenznummer, das würde nämlich ein Durchsatzproblem im Netz anzeigen. Die Zeitangabe bezeichnet die Laufzeit des Pakets das wir losgeschickt haben, bis wir eine Antwort darauf hatten. Es gilt: Je kleiner, je besser.  Wenn Zeiten vereinzelt nach oben Ausreisser haben, ist was im Netz los und der Durchsatz stimmt nicht. Das könnte dann z.b. „fremde“ Datenströme im LAN anzeigen oder einen ausgelasteten Prozesser ( auf der Gegenseite ) anzeigen. Da gibt es leider einiges an Möglichkeiten.

CHECK: Der Router ist erreichbar!

Traceroute

Wir gehen mal davon aus, daß der Router ok ist und die DSL Strecke auch. Jetzt will man aber z.b. testen, ob es auf der Strecke zum Lieblingsserver ein Problem gibt. Da ist Traceroute bzw. ein Derivat davon namens MTR Eurer Freund.

                             Packets               Pings
 Host                      Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.123.1           0.0%     3   16.0  10.8   0.4  16.0   9.0
    217.0.119.85
 2. 217.0.119.85            0.0%     3   15.7  15.8  15.7  16.1   0.0
 3. 217.0.65.250            0.0%     3   16.0  15.8  15.6  16.0   0.0
 4. 217.239.45.194          0.0%     2   21.5  21.7  21.5  21.9   0.0
 5. cr01.h.as24679.net      0.0%     2   33.0  33.0  33.0  33.0   0.0
 6. ar13.h.as24679.net      0.0%     2   48.1  40.6  33.0  48.1  10.7
 7. s120.resellerdesktop.de 0.0%     2   33.2  33.2  33.2  33.3   0.0

Die Loss Spalte zeigt hier 0.0% für „Alles OK “ an. Steht hier mehr als nur 0.0 , deutet das auf Probleme beim Datentransport von Paketen an dieser Stelle im Netz hin.

Hinweis: Jeder Rechner auf dieser Welt hat einen eigenen Weg zum Ziel. Wie Bergbäche zu Flüssen werden, so werden auch einzelne Benutzer eines DSL Anbieter vom Bach zum Fluß nur um am Ende in einen großen Teich zu fliessen. Deswegen kann es für den einen PC zu einem Problem kommen, wo sein Nachbar oder irgendwer anders kein Problem hat einen Server zu erreichen. Das ist NORMAL! Glaubt einem beim Telefonsupport zwar keiner, ist aber trotzdem so 🙂

CHECK: Der Server ist erreichbar ohne Paketverluste!

Wenn der Euch jetzt für Webanfragen nicht antwortet, will oder kann er vielleicht grade nicht . Jedenfalls liegt das nicht mehr in Eurer Hand.

Datenströme erfassen mit TCPDump

Ab hier müssen wir wieder ROOT User auf unserem Rechner werden, sonst klappt das nicht.

TCPDump kann Datenströme von der Netzwerkkarte abgreifen und anzeigen bzw. auf die Platte schreiben. Diverse Filter erlauben es, nur das zu sehen, was einen Interessiert. Hier im Beispiel den Aufruf von meinem Blog:

# tcpdump -n  host s120.resellerdesktop.de and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:37:22.112794 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [S], seq 325157599, win 29200, options [mss 1460,sackOK,TS val 18499715 ecr 0,nop,wscale 7], length 0
14:37:22.146706 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [S.], seq 2632340454, ack 325157600, win 28960, options [mss 1452,sackOK,TS val 3762553727 ecr 18499715,nop,wscale 7], length 0
14:37:22.146779 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 18499749 ecr 3762553727], length 0
14:37:22.146854 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [P.], seq 1:97, ack 1, win 229, options [nop,nop,TS val 18499749 ecr 3762553727], length 96: HTTP: GET / HTTP/1.1
14:37:22.180314 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [.], ack 97, win 227, options [nop,nop,TS val 3762553761 ecr 18499749], length 0
14:37:22.181118 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [P.], seq 1:456, ack 97, win 227, options [nop,nop,TS val 3762553762 ecr 18499749], length 455: HTTP: HTTP/1.1 302 Found
14:37:22.181170 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [.], ack 456, win 237, options [nop,nop,TS val 18499783 ecr 3762553762], length 0
14:37:22.181429 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [F.], seq 97, ack 456, win 237, options [nop,nop,TS val 18499784 ecr 3762553762], length 0
14:37:22.214648 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [F.], seq 456, ack 98, win 227, options [nop,nop,TS val 3762553796 ecr 18499784], length 0
14:37:22.214705 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [.], ack 457, win 237, options [nop,nop,TS val 18499817 ecr 3762553796], length 0

Die Uhrzeit mit Microsekunden dürfte noch erkennbar sein, dann folgt das Protokoll „IP“ (ja, gibt noch mehr) , es folgt die QuellIP mit Port und das Ziel mit Port und was danach kommt, sprengt den Rahmen des Artikels, aber so sieht eine Datenübertragung wirklich aus 🙂

Wenn wir jetzt mal sehen wollen, was da übertragen wird, schalten wir mit „-X“ den Inhalt ein:

# tcpdump -n -X  host s120.resellerdesktop.de and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:44:15.222244 IP 192.168.123.234.40968 > 83.246.80.133.http: Flags [S], seq 2086838668, win 29200, options [mss 1460,sackOK,TS val 18912825 ecr 0,nop,wscale 7], length 0
    0x0000:  4500 003c 37b5 4000 4006 9dc1 c0a8 79EA  E..<7.@.@......"
    0x0010:  53f6 5085 a008 0050 7c62 a18c 0000 0000  S.P....P|b......
    0x0020:  a002 7210 1b09 0000 0204 05b4 0402 080a  ..r.............
    0x0030:  0120 9639 0000 0000 0103 0307            ...9........
14:44:15.256813 IP 83.246.80.133.http > 192.168.123.234.40968: Flags [S.], seq 4282242486, ack 2086838669, win 28960, options [mss 1452,sackOK,TS val 3762966832 ecr 18912825,nop,wscale 7], length 0
    0x0000:  4500 003c 0000 4000 3a06 db76 53f6 5085  E..<..@.:..vS.P.
    0x0010:  c0a8 79EA 0050 a008 ff3d d5b6 7c62 a18d  ...".P...=..|b..
    0x0020:  a012 7120 1580 0000 0204 05ac 0402 080a  ..q.............
    0x0030:  e04a 5130 0120 9639 0103 0307            .JQ0...9....
14:44:15.256889 IP 192.168.123.234.40968 > 83.246.80.133.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 18912859 ecr 3762966832], length 0
    0x0000:  4500 0034 37b6 4000 4006 9dc8 c0a8 79EA  E..47.@.@......"
    0x0010:  53f6 5085 a008 0050 7c62 a18d ff3d d5b7  S.P....P|b...=..
    0x0020:  8010 00e5 b45d 0000 0101 080a 0120 965b  .....].........[
    0x0030:  e04a 5130                                .JQ0
14:44:15.256968 IP 192.168.123.234.40968 > 83.246.80.133.http: Flags [P.], seq 1:97, ack 1, win 229, options [nop,nop,TS val 18912859 ecr 3762966832], length 96: HTTP: GET / HTTP/1.1
    0x0000:  4500 0094 37b7 4000 4006 9d67 c0a8 79EA  E...7.@.@..g..."
    0x0010:  53f6 5085 a008 0050 7c62 a18d ff3d d5b7  S.P....P|b...=..
    0x0020:  8018 00e5 48d2 0000 0101 080a 0120 965b  ....H..........[
    0x0030:  e04a 5130 4745 5420 2f20 4854 5450 2f31  .JQ0GET./.HTTP/1
    0x0040:  2e31 0d0a 486f 7374 3a20 6d61 7269 7573  .1..Host:.marius
    0x0050:  2e62 6c6f 6767 742d 696e 2d62 7261 756e  .bloggt-in-braun
    0x0060:  7363 6877 6569 672e 6465 0d0a 5573 6572  schweig.de..User
    0x0070:  2d41 6765 6e74 3a20 6375 726c 2f37 2e34  -Agent:.curl/7.4
    0x0080:  332e 300d 0a41 6363 6570 743a 202a 2f2a  3.0..Accept:.*/*
    0x0090:  0d0a 0d0a                                ....
14:44:15.290765 IP 83.246.80.133.http > 192.168.123.234.40968: Flags [.], ack 97, win 227, options [nop,nop,TS val 3762966867 ecr 18912859], length 0
    0x0000:  4500 0034 84e4 4000 3a06 569a 53f6 5085  E..4..@.:.V.S.P.
    0x0010:  c0a8 79EA 0050 a008 ff3d d5b7 7c62 a1ed  ...".P...=..|b..
    0x0020:  8010 00e3 b3dc 0000 0101 080a e04a 5153  .............JQS
    0x0030:  0120 965b                                ...[
14:44:15.292457 IP 83.246.80.133.http > 192.168.123.234.40968: Flags [P.], seq 1:456, ack 97, win 227, options [nop,nop,TS val 3762966868 ecr 18912859], length 455: HTTP: HTTP/1.1 302 Found
    0x0000:  4500 01fb 84e5 4000 3a06 54d2 53f6 5085  E.....@.:.T.S.P.
    0x0010:  c0a8 79EA 0050 a008 ff3d d5b7 7c62 a1ed  ...".P...=..|b..
    0x0020:  8018 00e3 8e37 0000 0101 080a e04a 5154  .....7.......JQT
    0x0030:  0120 965b 4854 5450 2f31 2e31 2033 3032  ...[HTTP/1.1.302
    0x0040:  2046 6f75 6e64 0d0a 4461 7465 3a20 5765  .Found..Date:.We
    0x0050:  642c 2032 3120 5365 7020 3230 3136 2031  d,.21.Sep.2016.1
    0x0060:  323a 3434 3a31 3420 474d 540d 0a53 6572  2:44:14.GMT..Ser
    0x0070:  7665 723a 2041 7061 6368 652f 322e 342e  ver:.Apache/2.4.
    0x0080:  3138 2028 4665 646f 7261 2920 4f70 656e  18.(Fedora).Open
    0x0090:  5353 4c2f 312e 302e 316b 2d66 6970 730d  SSL/1.0.1k-fips.
    0x00a0:  0a4c 6f63 6174 696f 6e3a 2068 7474 7073  .Location:.https
    0x00b0:  3a2f 2f6d 6172 6975 732e 626c 6f67 6774  ://marius.bloggt
    0x00c0:  2d69 6e2d 6272 6175 6e73 6368 7765 6967  -in-braunschweig
    0x00d0:  2e64 652f 0d0a 436f 6e74 656e 742d 4c65  .de/..Content-Le
    0x00e0:  6e67 7468 3a20 3232 350d 0a43 6f6e 7465  ngth:.225..Conte
    0x00f0:  6e74 2d54 7970 653a 2074 6578 742f 6874  nt-Type:.text/ht
    0x0100:  6d6c 3b20 6368 6172 7365 743d 6973 6f2d  ml;.charset=iso-
    0x0110:  3838 3539 2d31 0d0a 0d0a 3c21 444f 4354  8859-1....<!DOCT
    0x0120:  5950 4520 4854 4d4c 2050 5542 4c49 4320  YPE.HTML.PUBLIC.
    0x0130:  222d 2f2f 4945 5446 2f2f 4454 4420 4854  "-//IETF//DTD.HT
    0x0140:  4d4c 2032 2e30 2f2f 454e 223e 0a3c 6874  ML.2.0//EN">.<ht
    0x0150:  6d6c 3e3c 6865 6164 3e0a 3c74 6974 6c65  ml><head>.<title
    0x0160:  3e33 3032 2046 6f75 6e64 3c2f 7469 746c  >302.Found</titl
    0x0170:  653e 0a3c 2f68 6561 643e 3c62 6f64 793e  e>.</head><body>
    0x0180:  0a3c 6831 3e46 6f75 6e64 3c2f 6831 3e0a  .<h1>Found</h1>.
    0x0190:  3c70 3e54 6865 2064 6f63 756d 656e 7420  <p>The.document.
    0x01a0:  6861 7320 6d6f 7665 6420 3c61 2068 7265  has.moved.<a.hre
    0x01b0:  663d 2268 7474 7073 3a2f 2f6d 6172 6975  f="https://mariu
    0x01c0:  732e 626c 6f67 6774 2d69 6e2d 6272 6175  s.bloggt-in-brau
    0x01d0:  6e73 6368 7765 6967 2e64 652f 223e 6865  nschweig.de/">he
    0x01e0:  7265 3c2f 613e 2e3c 2f70 3e0a 3c2f 626f  re</a>.</p>.</bo
    0x01f0:  6479 3e3c 2f68 746d 6c3e 0a              dy></html>.
14:44:15.292474 IP 192.168.123.234.40968 > 83.246.80.133.http: Flags [.], ack 456, win 237, options [nop,nop,TS val 18912895 ecr 3762966868], length 0
    0x0000:  4500 0034 37b8 4000 4006 9dc6 c0a8 79EA  E..47.@.@......"
    0x0010:  53f6 5085 a008 0050 7c62 a1ed ff3d d77e  S.P....P|b...=.~
    0x0020:  8010 00ed b1e6 0000 0101 080a 0120 967f  ................
    0x0030:  e04a 5154                                .JQT
14:44:15.292764 IP 192.168.123.234.40968 > 83.246.80.133.http: Flags [F.], seq 97, ack 456, win 237, options [nop,nop,TS val 18912895 ecr 3762966868], length 0
    0x0000:  4500 0034 37b9 4000 4006 9dc5 c0a8 79EA  E..47.@.@......"
    0x0010:  53f6 5085 a008 0050 7c62 a1ed ff3d d77e  S.P....P|b...=.~
    0x0020:  8011 00ed b1e5 0000 0101 080a 0120 967f  ................
    0x0030:  e04a 5154                                .JQT
14:44:15.326737 IP 83.246.80.133.http > 192.168.123.234.40968: Flags [F.], seq 456, ack 98, win 227, options [nop,nop,TS val 3762966903 ecr 18912895], length 0
    0x0000:  4500 0034 84e6 4000 3a06 5698 53f6 5085  E..4..@.:.V.S.P.
    0x0010:  c0a8 79EA 0050 a008 ff3d d77e 7c62 a1ee  ...".P...=.~|b..
    0x0020:  8011 00e3 b1cb 0000 0101 080a e04a 5177  .............JQw
    0x0030:  0120 967f                                ....
14:44:15.326802 IP 192.168.123.234.40968 > 83.246.80.133.http: Flags [.], ack 457, win 237, options [nop,nop,TS val 18912929 ecr 3762966903], length 0
    0x0000:  4500 0034 37ba 4000 4006 9dc4 c0a8 79EA  E..47.@.@......"
    0x0010:  53f6 5085 a008 0050 7c62 a1ee ff3d d77f  S.P....P|b...=..
    0x0020:  8010 00ed b19f 0000 0101 080a 0120 96a1  ................
    0x0030:  e04a 5177                                .JQw

Alles was man nicht in Klartext lesen kann, sind meistens Optionen innerhalb des IP Datenpakets. Im obigen Fall handelt es sich eindeutig um TCP Datenverkehr. Wer sich dafür interessiert: hier gibt es mehr

Wie man in dem Dump oben sehen kann, wird HTTP in Klartext übermittelt. Damit keine geheimen Daten verloren gehen, wurde HTTPS erfunden. Wer sich die Mühe macht und den Datensalat oben zusammen setzt, wird das hier sehen:

HTTP/1.1 302 Found
Date: Wed, 21 Sep 2016 12:44:14 GMT
Server: Apache/2.4.18 (Fedora) OpenSSL/1.0.1k-fips
Location: https://marius.bloggt-in-braunschweig.de/
Content-Length: 225
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://marius.bloggt-in-braunschweig.de/">here</a>.</p>
</body></html>

Genau, daß ist einfach die Umleitung von HTTP auf HTTPS.

TCPDump kommt immer dann zum Einsatz, wenn man sehen will, was wirklich über die Leitung gegangen ist. Der Browser behauptet zwar, daß X=U ist, aber sagte das auch der Server so ? 😀

Zurück zu den lokalen Tools: iptraf-ng

IPtraf ist eine wahre Schatzkiste an unterschiedlichen Funktionen. Es zeigt live an, „wer mit wem redet“, Statistiken über die Häufigkeit von Paketen und wer vielviel Daten transportiert hat. Alles zu erklären sprengt genau wie bei TCPDump den Rahmen. Da es mit einem grafischen Interface in der Konsole daher kommt, ist es extrem leicht zu bedienen.

Daher einfach installiere und ausprobieren.

bildschirmfoto-vom-2016-09-21-15-02-44Durchsatzstatistik mit : ifstat

Wer nur eine kleine Statistik braucht, der kann einfach ifstat fragen :

# ifstat
ifstat: history is stale, ignoring it.
#2212.1804289383 sampling_interval=2 time_const=60
Interface        RX Pkts/Rate    TX Pkts/Rate    RX Data/Rate    TX Data/Rate  
                 RX Errs/Drop    TX Errs/Drop    RX Over/Rate    TX Coll/Rate  
lo                   276 0           276 0          8674 0          8674 0      
                       0 0             0 0             0 0             0 0      
enp2s0            392203 2        521196 1       121730K 449     601935K 244    
                       0 3             0 0             0 0             0 0      
virbr0                 0 0             0 0             0 0             0 0      
                       0 0             0 0             0 0             0 0

Statistiken mit : vnstat

Auch mit vnstat kann man Statistiken zu seinem Interface abrufen. Allerdings müssen die erst gesammelt werden, was bedeutet, daß man zwei Aufrüfe benutzen muß:

# vnstat -u -i enp2s0
# vnstat -i enp2s0
Database updated: Wed Sep 21 17:01:50 2016

   enp2s0 since 09/21/16

          rx:  1.35 MiB      tx:  1.20 MiB      total:  2.55 MiB

   monthly
                     rx      | Statistiken mit : vnstat    tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       Sep '16      1.35 MiB |    1.20 MiB |    2.55 MiB |    0.01 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated         1 MiB |       1 MiB |       2 MiB |

   daily
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
         today      1.35 MiB |    1.20 MiB |    2.55 MiB |    0.34 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated         1 MiB |       1 MiB |       2 MiB |

Dafür ist das keine Momentaufnahme, sondern ein wohl definierter Zeitraum. Damit lassen sich also Feststellungen machen, wieviel Traffic eine Anwendung verursacht hat. Natürlich nur, wenn nichts anderes stört.

Womit wir beim Schluß des Artikels wären und der Frage, ob da noch mehr existiert ?

Ja, das tut es. Will man z.b. sein Heimatnetzwerk verlassen, muß man dem Rechner gesagt haben, welcher andere Computer dem eigenen PC die Pakete abnehmen soll, um sie ins Internet weiter zu leiten. Dies geschieht über die Route, welche man mit dem Befehl route sehen und manipulieren kann.  Da die meisten von Euch nicht in der Konsole arbeiten werden, sondern dem Gnome/Cinnamon im Netzwerkmanager gesagt haben, was er tun soll, schauen wir uns nur schnell die Ausgabe an und verzichten heute auf die Manipulation:

# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.121.1   0.0.0.0         UG    100    0        0 enp2s0
192.168.121.0   0.0.0.0         255.255.0.0     U     100    0        0 enp2s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Was man sieht sind alle verfügabren Netze und das ist ein Netz mehr als wir erwarten würden. Das Netzwerk 192.168.122.0, was man aufgrund der Netzmaske als ein Class-C Netz /24 identifizieren kann, wird von der Virtualisierung benutzt. Das wären z.B. VirtualBox oder das schon bei Fedora vorhandene Boxen Tool.

Das andere 192.168.121.0 Netzwerk, ist das normale LAN Netz (meines PCs) Bei Euch wird das anders aussehen.

Das Ziel 0.0.0.0 ist „Der Rest der Welt“ und wird vom Rechner mit der IP 192.168.121.1  „geroutet“. Den nennt man deswegen auch Gateway, nämlich Gateway in ein anderes Netzwerk. Man kann in einem LAN mehrere Gateways haben, man muß als nur in dieser Routentabelle dafür sorgen, daß jedes Zielnetzwerk mit seinem Gateway eingetragen ist. Dazu gehört auch, daß das Gateway mit einem Bein (und korrekter IP und Netzwerkmaske ) in eigenen LAN steht.

Damit soll es für heute genug sein.

Update um 9:09 Uhr :

Auch dieser Beitrag wurde von WordPress entgegen des Planungstermins, nicht angezeigt.