Der Windows kernel-Modus Treiber bietet Portmaster eine hochleistungs Betriebssystems Integration. Es bietet ein Internes Zwischenspeichern für die beste Leistung und lässt Portmaster alle Entscheidungen treffen.
Die beste Architektur ist wie folgt:
+----------------+
| |
+------>| Portmaster |------>+
| | | |
| +----------------+ |
| |
| (2a) verdict request | (3) set verdict
[user mode] | |
..................|................................|........................
[kernel mode] | |
| |
+-------------------------------------|---+
| +-> | (2b/4) handle packet
(1) packet | Driver if in cache | according to verdict
------------>| (2) check verdict cache +---------> |-------------------->
| |
+-----------------------------------------+
Diese Architektur erlaubt Hochleistung, da die meisten Packete direkt im kernel behandelt werden. Nur neue Verbindungen müssen in Nutzerland geschoben werden damit Portmaster ein Urteil fällen kann.
Der Treiber ist in dem Windows Netzwerk Stapel installiert - zwischen OSI Schicht 2 und 3 - und sieht die IP Schicht und alles darüber.
So werden Packete behandelt:
PortmasterRecvVerdictRequest.packetInfo) und setzt ein Urteil via PortmasterSetVerdict.PortmasterGetPayload, indem er die vorherige Packet ID von PortmasterRecvVerdictRequest nutzt.Windows nützt einen System Service namens DNS Client oder auch dnscache genannt, um Abfragen für Applikationen zu lösen. Abfragen die durch diesen Service gemacht werden können nicht direkt zu der originalen Applikation die die Anfrage gestartet hat verlinkt werden.
Somit kann Portmaster die eigentliche Applikation nicht identifizieren und macht somit nicht direkt eine Entscheidung über Abfragen die über den Windows DNS Client kommen. (außer für Block Bypassing ), Sondern wird sich die IPs merken und diese nutzen um die Domänen mit Verbindungen übereinzustimmen wenn die tatsächliche Verbindung initialisiert wird.
Dieser Vorgang kann manchmal dazu führen das Portmaster eine Domäne einer Verbindung falsch zuschreibt.
Zum Beispiel, wenn zwei Prozesse verschiedene Domänen nutzen aber zur gleichen IP Adresse zeigen, daher kann es passieren, dass Portmaster denkt das sich der erste Prozess zu der Domäne verbindet und der zweiter anders herum. Vorallem wenn Anfragen parallel gemacht werden oder wenn Verbindungen neu erzeugt werden ohne neu über die Domäne abzufragen.
Als eine Lösung für dieses Problem, werden wir Anfragen nach HTTP Headers und TLS Handshakes zu suchen. Mit Information die direkt von der Verbindung gesammelt wird, wird die Zuschreibung genauer.
In Versionen bis v0.6.6, deaktiviert Portmaster den Windows DNS Client um direkt alle DNS Anfragen zu sehen. Da das zu verschiedenen Problemen führt, wurde es mit einer umgehung in vo.6.7 rückängig gemach du kannst das genaue entwicklungs Protokoll lesen um mehr über diese Änderung und die Gründe dahinter zu erfahren.
Auf Linux versuchen wir zwei Wege der Betriebssystems Integration bereitzustellen.
Quellen Code firewall/interception/nfq
Portmaster nutzt iptables und nfqueue um Netzwerk Verkehr zu inspezieren und zu kontrollieren. Die nfqueue erlaubt es Packete in den Nutzerplatz zu leiten und ein Urteil zu erhalten und eine Makierung zu einer Verbindung zu setzen.
Portmaster akzeptiert alle Packete, aber makiert die ganze Verbindung danach als akzeptiert/fallen gelassen. Das entlastet Portmaster von schwerem Netzwerkverkehr, da sobald eine Entscheindung über eine Verbindung getroffen wurde, die Verbindung zurück zum kernel kommt, und nie wieder zum Nutzerplatz gleitet werden muss, was relativ aufwendig ist.
Hier sind die Regeln die Portmaster für IPv4 und IPv6 anwendet.
mangle: C170
mangle: C171
filter: C17
mangle C170 -j CONNMARK --restore-mark
mangle C170 -m mark --mark 0 -j NFQUEUE --queue-num {17040|17060} --queue-bypass
mangle C171 -j CONNMARK --restore-mark
mangle C171 -m mark --mark 0 -j NFQUEUE --queue-num {17140|17160} --queue-bypass
filter C17 -m mark --mark 0 -j DROP
filter C17 -m mark --mark 1700 -j ACCEPT
filter C17 -m mark --mark 1701 -p icmp -j RETURN
filter C17 -m mark --mark 1701 -j REJECT --reject-with {icmp-host-prohibited|icmp6-adm-prohibited}
filter C17 -m mark --mark 1702 -j DROP
filter C17 -j CONNMARK --save-mark
filter C17 -m mark --mark 1710 -j ACCEPT
filter C17 -m mark --mark 1711 -p icmp -j RETURN
filter C17 -m mark --mark 1711 -j REJECT --reject-with {icmp-host-prohibited|icmp6-adm-prohibited}
filter C17 -m mark --mark 1712 -j DROP
filter C17 -m mark --mark 1717 -j ACCEPT
mangle OUTPUT -j C170
mangle INPUT -j C171
filter OUTPUT -j C17
filter INPUT -j C17
nat OUTPUT -p udp --dport 53 -m mark --mark 1799 -j DNAT --to {127.0.0.17:53|[::1]:53}
nat OUTPUT -m mark --mark 1717 -p {tcp|udp} -j DNAT --to-destination 127.0.0.17:1117 # for Gate17
17040 bricht auf zu:
17 ist ein Identifikator, damit du leicht erkennen kannst was zu Portmaster/Gate17 gehört0 für Ausgabe, 1 for Eingabe4 für IPv4, 6 für IPv60 id für multi-threaded nfqueue (derzeit wird nur ein thread benutzt)1700 Akzeptiere
1701 Blockiere
1702 wird fallen gelassen
1710 Permanentes Akzeptieren
1711 Permanentes Blockieren
1712 Permanentes fallen lassen
1717 Leite um zu Gate17
1799 Leite um zu nameserver (für Irreführende DNS Abfragen)
Wir planen eine Alternative zur iptables Integration berreitzustellen indem wir ein kernel Modul schreiben um die benötigten Packet Abfangung zu behandeln. Je nach Leistung und Stabilität von der iptables Integration, wird das früher oder später in Angriff genommen.
Golang Docs process/proc
Um herauszufinden zu welchem Packet ein Prozess gehört, wird zuerst das proc Dateisystem analysiert um die Sockel ID von einem abgefangenen Packet zu finden. Dann wird das Prozess Verzeichnis nach der passenden PID durchsucht. Das ist ein bisschen umständlich, aber leider gibt es keinen besseren Weg diese Information zu erhalten.
Mit systemd-resolved, rollen Linux Distributionen langsam einen System Resolver aus, der ähnliche Fähigkeiten wir der Windows DNS Client besitzt.
Das wichtige Detail für Protmaster ist das Abfragen zu systemd-resolved über das D-Bus interface gesendet werden anstatt Packete auf dem Kabel. Als ein Ergebnis kann Portmaster nicht den eigentlichen Prozess hinter einer Abfrage identifizieren und keine Entscheidung über Abfragen von systemd-resolved fällen (außer für Block Bypassing ), sondern wird sich die IPs merken und diese nutzen um die Domänen mit Verbindungen übereinzustimmen wenn die tatsächliche Verbindung initialisiert wird.
Dieser Vorgang kann manchmal dazu führen das Portmaster eine Domäne einer Verbindung falsch zuschreibt.
Zum Beispiel, wenn zwei Prozesse verschiedene Domänen nutzen aber zur gleichen IP Adresse zeigen, daher kann es passieren, dass Portmaster denkt das sich der erste Prozess zu der Domäne verbindet und der zweiter anders herum ist. Vorallem wenn Anfragen parallel gemacht werden oder wenn Verbindungen neu erzeugt werden ohne neu über die Domäne abzufragen.
Als eine Lösung für das, werden wir Anfragen nach HTTP Headers und TLS Handshakes zu suchen. Mit Information die direkt von der Verbindung gesammelt wird, wird die Zuschreibung genauer.
Portmaster verwendet folgende Ports:
717 SPN Eingangspunkt für Tunnelverbindungen (nur localhost)817 Portmaster API für die Integration mit UI Elementen und anderen Helfern (nur localhost)SPN nodes nutzen zusätzlich gewöhnliche Ports wie 80 und 443 um Zugriff auf beschränkte Neztwerkumfelder zu gewährleisten.
Alle dieser ports sind in dem System Port Umfang (1-1023) für zusätzliche Sicherheit. Diese Ports erfordern die Nutzung von Administrator Privilegien. Das fügt eine zusätsliche Schutzschicht gegen Prozesse hinzu die versuchen UI Komponenten denken zu lassen das alles OK ist, obwohl das nicht der Fall ist.
Manche von euch werden feststellen das diese Port Nummern nicht von uns registriert sind. Das ist richtig:
17 ist dem (historischen) Quote of the Day Protokoll Zugewiesen. Das wurde primär dazu verwendet Netzwerkprobleme zu beheben, aber ist nicht mehr aktiv in Nutzun. Aber in jedem Fall : SPN ist abwärskompatibel!717 und 817 sind von IANA zugeteilt . Die ganze Liste ist hier.IANA gibt an das "System und Nutzer Ports NICHT ohne oder vor IANA Registrierung genutzt werden sollten." NICHT ist als "NICHT EMPFOHLEN" definiert, aber gibt an das es Gründe unter bestimmten Umständen gibt wenn dieses Verhalten aktzeptiert oder sogar nützlicht ist, aber sollte vorsichtich abgewogen werden. Während wir planen in der Zukunft einen Registrierungs Prozess zu starten, glauben wir das wir RFC konform sind, da die Ports 717 und 817 (1) nur lokal genutzt werden, (2) nicht dem Internet ausgesetzt sind und (3) wichtig für die Sicherheit sind.
Es gibt 2 primäre Betriebssystem Integrations Schnittstellen die Portmaster nutzt um Betriebssystem spezifische Logik in Cross-Platform Struktur anzuwenden.
Packet Kanal ist für das einnehmen aller gesehenen PacketePermanent* Aktion Funktionen aufgerufen wird.nfqueue auf Linuc und eine benutzerdefinierten kernel-Modus Treiber auf Windows/proc auf Linux und die iphlpapi.dll auf Windows.Zusätzlich, gibt es manche nicht essentziellen Schnittstellen die Dinge wie Namen oder Symbole von Programmen liefern