[gelöst] NetworkManager vs ifconfig

[gm2601]

Hallo Gurus,

worin besteht der Unterschied zwischen "Verbindung trennen" und "# ifconfig eth0 down"?

tcpdump zeigt weiterhin Aktivitäten nach Ersterem, wobei ich den Eindruck habe, es sind in der Hauptsache Broadcasts oder Gequassel mit dem Router -- wozu das Ganze?

# tcpdump 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:51:31.366843 IP 192.168.1.1.45235 > 255.255.255.255.faximum: UDP, length 173
12:51:31.368190 IP 192.168.1.101.42367 > 192.168.1.1.domain: 11351+ PTR? 255.255.255.255.in-addr.arpa. (46)
12:51:31.418951 IP 192.168.1.1.domain > 192.168.1.101.42367: 11351 NXDomain 0/1/0 (114)
12:51:31.419669 IP 192.168.1.101.39602 > 192.168.1.1.domain: 29597+ PTR? 1.1.168.192.in-addr.arpa. (42)
12:51:31.469706 IP 192.168.1.1.domain > 192.168.1.101.39602: 29597 NXDomain 0/1/0 (91)
12:51:31.470477 IP 192.168.1.101.57725 > 192.168.1.1.domain: 56358+ PTR? 101.1.168.192.in-addr.arpa. (44)
12:51:31.520874 IP 192.168.1.1.domain > 192.168.1.101.57725: 56358 NXDomain 0/1/0 (93)
12:51:34.426870 IP 192.168.1.1.45235 > 255.255.255.255.faximum: UDP, length 173
12:51:34.894893 IP6 fe80::c6e9:84ff:fe5a:79a5 > ipv6-allnodes: ICMP6, router advertisement, length 24
12:51:34.996330 IP6 fe80::e2cb:4eff:fecd:dec3.mdns > ff02::fb.mdns: 0 PTR (QM)? 5.a.9.7.a.5.e.f.f.f.4.8.9.e.6.c.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
12:51:34.996488 IP 192.168.1.101.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 5.a.9.7.a.5.e.f.f.f.4.8.9.e.6.c.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
12:51:35.998031 IP6 fe80::e2cb:4eff:fecd:dec3.mdns > ff02::fb.mdns: 0 PTR (QM)? 5.a.9.7.a.5.e.f.f.f.4.8.9.e.6.c.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
12:51:35.998190 IP 192.168.1.101.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 5.a.9.7.a.5.e.f.f.f.4.8.9.e.6.c.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
12:51:36.368317 ARP, Request who-has 192.168.1.1 tell 192.168.1.101, length 28
12:51:36.368460 ARP, Reply 192.168.1.1 is-at c4:e9:84:5a:79:a5 (oui Unknown), length 46
12:51:44.901607 IP 192.168.1.101.51295 > 192.168.1.1.domain: 42770+ PTR? b.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
12:51:49.954030 IP 192.168.1.101.59859 > 192.168.1.1.domain: 37314+ PTR? 251.0.0.224.in-addr.arpa. (42)
12:51:52.786944 IP 192.168.1.1.45235 > 255.255.255.255.faximum: UDP, length 173
12:51:55.213441 IP6 fe80::c6e9:84ff:fe5a:79a5 > ipv6-allnodes: ICMP6, router advertisement, length 24
12:51:55.846934 IP 192.168.1.1.45235 > 255.255.255.255.faximum: UDP, length 173
12:51:56.672368 IP 192.168.1.101.47128 > a95-101-72-209.deploy.akamaitechnologies.com.http: Flags [.], ack 1465688585, win 245, options [nop,nop,TS val 3521864 ecr 3818426993], length 0
12:51:56.672698 IP 192.168.1.101.47646 > 192.168.1.1.domain: 12561+ PTR? 209.72.101.95.in-addr.arpa. (44)
12:51:56.727646 IP a95-101-72-209.deploy.akamaitechnologies.com.http > 192.168.1.101.47128: Flags [.], ack 1, win 972, options [nop,nop,TS val 3818437073 ecr 3509277], length 0
12:51:56.729421 IP 192.168.1.1.domain > 192.168.1.101.47646: 12561 1/0/0 PTR a95-101-72-209.deploy.akamaitechnologies.com. (102)
12:51:58.916952 IP 192.168.1.1.45235 > 255.255.255.255.faximum: UDP, length 173
12:51:59.018379 IP6 fe80::c6e9:84ff:fe5a:79a5 > ipv6-allnodes: ICMP6, router advertisement, length 24
12:52:01.976963 IP 192.168.1.1.45235 > 255.255.255.255.faximum: UDP, length 173
tcpdump: pcap_loop: The interface went down
27 packets captured
52 packets received by filter
25 packets dropped by kernel

 

[gm2601]

Keinerlei Echo?
Fehlende Angaben, unsinnige Frage,...?

Hintergrund der Frage war mein Eindruck, dass sich ein Webradiosender weder nach "Pause" noch nach Fenster schließen und auch nach "Verbindung trennen" nicht verabschiedete, sondern die Megabytes weiterhin munter ankamen. Erst ein Ifconfig eth0 down" (siehe 4. Zeile von unten im Code) machte dem Spuk ein Ende.

 

[Gräfin Klara]

Hallo Gurus,

worin besteht der Unterschied zwischen "Verbindung trennen" und "# ifconfig eth0 down"?

Verbindung trennen richtet sich an eine Applikation, in deinem Fall an den Networkmanager.
Ein Networkmanager kann die Verbindung nicht trennen. Dazu müßte er schon als proxy zwischen den Verbindungen stehen, was aber nicht der Fall ist.
D.h. ein Networkmanager (unter Linux sowieso eine seltsame Einrichtung), ist nicht in der Lage, einem client (wie dein Radio) seinen socket wegzunehmen.

# ifconfig eth0 down
sollte eigentlich lauten
# ip link set dev eth0 down
weil ifconfig den neuen kernel Netlink Funktionalitäten nicht mehr gerecht wird.

Das gibt dem kernel bekannt, dass das device eth0 aus der Tabelle gültiger Netlink devices entnommen werden soll.
Ist dieses eth0 entfernt, stehen alle clients und auch der Networkmanager blöd da .. das device existiert nicht mehr.
Nichts kann mehr darauf zugreifen. Selbst jene Applikationen, die aktuell dieses device geöffnet hatten, werden mit einem Fehler rausgeworfen.
Schluss, aus, finster.
Das funktioniert so, dass der kernel zuerst die Konfiguration (routing usw.) löscht und dann dem driver von eth0 sagt, dass er die Karte abschalten soll.
Der Nachteil dabei ist, dass eth0 wieder komplett neu konfiguriert und gestartet werden muß.
# ip link set dev eth0 down
ist also nicht wirklich die richtige Lösung, alle Verbindungen zu trennen. Dafür gibt es andere Möglichkeiten.

Gruß
Gräfin Klara

 

[abgdf]

# ip link set dev eth0 down
ist also nicht wirklich die richtige Lösung, alle Verbindungen zu trennen. Dafür gibt es andere Möglichkeiten.

Oh, das ist interessant. Könntest Du die anderen Möglichkeiten bitte ein bißchen beschreiben? Ich würde hin- und wieder gern per Software von Hand die Internetverbindung des Computers trennen (und wieder herstellen), während der Router weiterlaufen soll.

 

[MH1962]

Konzeptionell bedingt gibt es eigentlich keine Möglichkeit, eine fremde TCP-Verbindung zu "trennen". TCP ist eine Ende-zu-Ende-Verbindung, und die sollen gefälligst die beteiligten Partner trennen. Daher ist das Runterfahren des Interface der denkbar ungeeignetste Ansatz, denn wenn das Interface unten ist, kann keiner der beteiligten Partner ein FIN oder ein RST mehr schicken, was die Verbindung beenden würde. Die Verbindungen laufen dann irgendwann auf Timeout, das dauert aber ca. 10 Minuten.

Es gibt aber einen "Trick", der TCP-Verbindungen schnell beendet, und zwar iptables. Man kann (temporär) eine iptables-Regel einrichten, die TCP-Pakete mit einem RST zurückweist, was dann in der Folge dazu führt, dass die Verbindung als beendet angesehen wird. Das wirkt also erst nachdem das nächste Paket kommt und nicht sofort!

Etwa so:

iptables -A INPUT -i eth0 -p tcp -s a.b.c.d -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -o eth0 -p tcp -d a.b.c.d -j REJECT --reject-with tcp-reset

Die erste Regel wirkt auf den entfernten Rechner, die zweite auf den eigenen Rechner. a.b.c.d ist die IP-Adresse des entfernten Rechners. Man kann das auch auf bestimmte Ports einschränken usw.

Wichtig: Wenn man noch mehr iptables-Regeln hat, muss man evtl. die Regel an einer geeigneten Stelle in den Regelsatz einfügen. Also bitte nicht blind abtippen, sondern einlesen und nachdenken!

 

[gm2601]

Oh danke, jetzt dringt starker Tobak auf mich ein, hätte mich doch auch gewundert, wenn ich hier nicht auf geballtes Know-how getroffen wäre....

TCP = end to end reliable connection, auch von "Socken" und ports habe ich vor langer Zeit einmal gehört...ich bin eben zu lange schon aus dem Job.

weil ifconfig den neuen kernel Netlink Funktionalitäten nicht mehr gerecht wird.

Das gehört für mich zur Kategorie "nice to know", ich akzeptiere auch, wenn man das eine Holzhammermethode nennt -- aber wenn man nur die kennt, was dann? ps:

@MH1962
Iptables? Danke für den Tipp, aber das ist etwas für Profis, da lasse ich mal schön die Finger davon.

Zwischenzeitlich habe ich mir den trafic genauer angesehen und festgestellt, dass ich mich geirrt habe. ps:
Der Web-Sender läuft nicht weiter, wenn man auf Pause geht oder gar den entsprechenden Tab schließt, danach reduziert sich "received bytes" sofort um ca 20% auf immerhin noch 4,8MB/min. :???:
Erst wenn ich den Fox beende, bricht der Bytecount fast völlig zusammen, den Rest verursachen wohl irgendwelche Dämonen, die regelmäßig Lebenszeichen geben.

Die Frage müsste nun eigentlich heißen, was treibt der Fox, wenn ich allem Anschein nach nichts mache?

Für mich ist die Anfangsfrage gelöst, aber wer Lust und Zeit hat, kann mir gerne noch über Hintergrundaktivitäten des Foxes Infos zukommen lassen.

 

[Gräfin Klara]

# ip link set dev eth0 down
ist also nicht wirklich die richtige Lösung, alle Verbindungen zu trennen. Dafür gibt es andere Möglichkeiten.

Oh, das ist interessant. Könntest Du die anderen Möglichkeiten bitte ein bißchen beschreiben? Ich würde hin- und wieder gern per Software von Hand die Internetverbindung des Computers trennen (und wieder herstellen), während der Router weiterlaufen soll.

Es kommt darauf an, was du willst. Was erwartest du dir von einer Trennung der Verbindung?
Beispiel:
@MH1962 zeigt hier eine einfache Möglichkeit mit iptables auf.
Diese rules bauen den TCP Datenstrom langsam ab. Tatsache ist aber, dass dieses Verfahren ca. 70% des Datenstroms nicht unterbindet.
Genügt das trotzdem deinen Anforderungen? Wenn nein, dann sollte UDP weg. Reicht dir das dann? ARP und anderes fließen dann nämlich immer noch.
Wenn nein, dann mußt du im OSI noch 2 Layer nach unten in Richtung ethernet. Auch dort gibt es einiges zu tun.
Reicht dir das dann? Die mac ist dann nämlich immer noch als Konstante vorhanden. Soll die auch weg?
Du mußt wissen, was du willst und wozu du es willst.

Gruß
Gräfin Klara

 

[abgdf]

Was erwartest du dir von einer Trennung der Verbindung?

Ich möchte in meinem mit Passwort verschlüsselten Datencontainer wühlen, ohne daß jemand von außen hineinguckt.

 

[gehrke]

Ich möchte in meinem mit Passwort verschlüsselten Datencontainer wühlen, ohne daß jemand von außen hineinguckt.

Wenn Du davon ausgehst, dass jemand tatsächlich Zugriff hat auf dein System, dann ist das temporäre Abschalten vom Netz nur ein stumpfes Schwert. Schließlich könnte dieser Angreifer auch schon lange vorher einen Key-Logger installiert haben, welcher das Passwort bei der Eingabe offline mitprotokolliert und später (nach Reaktivierung des Netzes) dieses nutzen, um asynchron auf Deine geheimen Daten zuzugreifen.

Zugegeben, für dieses Szenario sind Annahmen wie root-Zugriff vorausgesetzt. Man kann aber nicht ausschließen, dass ein Angreifer einen Ansatz für eine Privilegien-Eskalation findet, wenn er laut Deiner Annahme zuvor schon das System infiltrieren konnte ('jemand von außen hineinguckt'). Denn dann scheint es um den Sicherheitslevel dieses Systems nicht besonders gut bestellt zu sein.

Ja, Netz kurzzeitig abschalten oder Stecker ziehen kann helfen, aber ab einer bestimmten Kragenweite des Angreifers wird das nicht ausreichen.

 

[Gräfin Klara]

Was erwartest du dir von einer Trennung der Verbindung?

Ich möchte in meinem mit Passwort verschlüsselten Datencontainer wühlen, ohne daß jemand von außen hineinguckt.

Das ist auch dein Recht!!!

Verwende dieses script

#!/bin/bash
# (C) Klara 2017

IPT_BAK_RULES="/tmp/iptables.bak"
ARP_BAK_RULES="/tmp/arptables.bak"
ROUTE_DEVICE="eth0"

ipt_set_drop()
{
	[ -f "$IPT_BAK_RULES" ] || iptables-save > "$IPT_BAK_RULES"
	iptables --flush
	iptables -P INPUT DROP
	iptables -P FORWARD DROP
	iptables -P OUTPUT DROP
	iptables -t mangle -P PREROUTING DROP
	iptables -t mangle -P INPUT DROP
	iptables -t mangle -P FORWARD DROP
	iptables -t mangle -P OUTPUT DROP
	iptables -t mangle -P POSTROUTING DROP
	return 0
}
arp_set_drop()
{
	[ -f "$ARP_BAK_RULES" ] || arptables-save > "$ARP_BAK_RULES"
	ip -s neighbour flush all
	arptables -A INPUT -i $ROUTE_DEVICE -j DROP
	arptables -A OUTPUT -o $ROUTE_DEVICE -j DROP
	arptables -A FORWARD -i $ROUTE_DEVICE -j DROP
	return 0
}
ipt_restore()
{
	[ -f "$IPT_BAK_RULES" ] || return 1
	iptables-restore < "$IPT_BAK_RULES"
	return 0
}
arp_restore()
{
	[ -f "$ARP_BAK_RULES" ] || return 1
	arptables-restore < "$ARP_BAK_RULES"
	return 0
}
print_status()
{
	local ln=$(printf "%50s" | tr ' ' '-')
	printf "%s\n* iptables\n" "$ln"
	iptables -v -L INPUT
	iptables -v -L OUTPUT
	iptables -v -L FORWARD
	iptables -S -t nat
	iptables -S -t mangle
	printf "%s\n* arptables\n" "$ln"
	arptables -v -L INPUT
	arptables -v -L OUTPUT
	arptables -v -L FORWARD
	return 0
}
#--------------------------------------------------
case "$1" in
	"drop")
		ipt_set_drop
		arp_set_drop
		;;
	"restore")
		arp_restore
		ipt_restore
		;;
	"status")
		print_status
		;;
	*)
		printf "pppffff\n"
		exit 1
		;;
esac
exit 0

Die Regeln sind richtig, das script selbst habe ich nicht getestet.
ROUTE_DEVICE="dein_device_zum_router"
arptables installieren!

"drop"
sperrt TCP,UDP und ICMP in alle Richtungen und verhindert ein eventuelles forwarding.
Weiters wird ARP in Richtung router unterbunden, d.h. er findet dich nicht mehr.
Damit bist du sicher.

"restore"
Zurück zum alten Zustand.
Es kann ein bißchen dauern, bis alles wieder funktioniert, weil die Verbindung zum router erst wieder aufgebaut werden muß.
Wichtig: es wird nur 1x ein backup der rules gemacht. Das ist logistisch verbesserungswürdig.

Gruß
Gräfin Klara

 

[abgdf]

@Gräfin Klara: Herzlichen Dank! Ich werde mir das sehr genau ansehen.