ssf -Download - ssf -Quellcode -Download

ssf

C/C++

3.0.0

Herunterladen

Sicherung der Steckdose

Secure Socket Trichter (SSF) ist ein Netzwerk -Tool und ein Toolkit.

Es bietet einfache und effiziente Möglichkeiten, Daten von mehreren Sockets (TCP oder UDP) über einen sicheren TLS -Tunnel an einen Remote -Computer weiterzuleiten.

SSF ist eine Cross -Plattform (Windows, Linux, OSX) und wird als eigenständige ausführbare Ausführungen ausgestattet.

Merkmale:

Lokale und Remote -TCP -Portweiterung
Lokale und Remote -UDP -Portweiterung
Lokaler und Remote -Sockenserver
Lokale und Fernschale durch Sockets
Dateikopie
Natives Relaisprotokoll
TLS-Verbindung mit den stärksten Chiffre-Suites

Laden Sie vorgefertigte Binärdateien herunter

Dokumentation

Erstellen Sie an Fenstern

Bauen Sie auf Unix/Linux auf

Cross Compiling SSF (z. B. Raspberry PI)

Wie man benutzt

Befehlszeile

Kunde

Verwendung: ssf[.exe] [options] server_address

Optionen:

-v verbose_level : Ausführlichkeit: kritisch | Fehler | Warnung | Info | Debug | Trace (Standard: Info)
-q : Ruhemodus. Drucken Sie keine Protokolle aus
-p port : Remote -Port (Standard: 8011)
-c config_file_path : Geben Sie die Konfigurationsdatei an. Wenn nicht festgelegt, wird 'config.json' aus dem aktuellen Arbeitsverzeichnis geladen
-m attempts : MAX erfolglose Verbindungsversuche vor dem Stoppen (Standard: 1)
-t delay : Wartezeit, bevor Sie versuchen, sich in Sekunden zu verbinden (Standard: 60)
-n : Versuchen Sie nicht, den Client wieder zu verbinden, wenn die Verbindung unterbrochen wird
-g : Gateway -Ports zulassen. Ermöglichen Sie den Kunden, lokale Sockets für einen Dienst an eine bestimmte Adresse zu binden und nicht an "Localhost"
-S : Microservices Status anzeigen (Ein/Aus)

Dienstleistungsoptionen:

-D [[bind_address]:]port : Führen Sie einen Sockenproxy auf dem Server aus, der auf [[bind_address]:]port auf der lokalen Seite zugänglich ist
-F [[bind_address]:]port : Führen Sie einen Sockenproxy auf dem lokalen Host aus, der vom Server auf [[bind_address]:]port zugänglich ist
-X [[bind_address]:]port : Server -Shell -E/A an den angegebenen Port auf der lokalen Seite voran. Jede Verbindung erstellt einen neuen Shell -Prozess
-Y [[bind_address]:]port : leiten lokale Shell -E/A an den angegebenen Port auf dem Server weiterleiten
-L [[bind_address]:]port:host:hostport : Vorwärts -TCP -Verbindungen an [[bind_address]:]port auf dem lokalen Host zu host:hostport auf dem Server
-R [[bind_address]:]port:host:hostport : leiten tcp connections an [[bind_address]:]port auf dem server zu host:hostport auf der lokalen Seite
-U [[bind_address]:]port:host:hostport : Leiten Sie den lokalen UDP -Datenverkehr auf [[bind_address]:]port zu host:hostport auf dem Server
-V [[bind_address]:]port:host:hostport : UDP -Datenverkehr auf [[bind_address]:]port auf dem Server zu host:hostport auf der lokalen Seite

Server

Verwendung: ssfd[.exe] [options]

Optionen:

-v verbose_level : Ausführlichkeit: kritisch | Fehler | Warnung | Info | Debug | Trace (Standard: Info)
-q : Ruhemodus. Drucken Sie keine Protokolle aus
-c config_file_path : Geben Sie die Konfigurationsdatei an. Wenn nicht festgelegt, wird 'config.json' aus dem aktuellen Arbeitsverzeichnis geladen
-p port : Lokaler Port (Standard: 8011)
-R : Der Server leitet nur Verbindungen weiter
-l host : Setzen Sie die Server -Bindungs -Adresse
-g : Gateway -Ports zulassen. Ermöglichen Sie den Kunden, lokale Sockets für einen Dienst an eine bestimmte Adresse zu binden und nicht an "Localhost"
-S : Microservices Status anzeigen (Ein/Aus)

Kopie

Die Kopierfunktion muss sowohl in der Client- als auch in der Serverkonfigurationsdatei aktiviert werden:

{
  "ssf" : {
    "services" : {
      "copy" : { "enable" : true }
    }
  }
}

Verwendung: ssfcp[.exe] [options] [host@]/absolute/path/file [[host@]/absolute/path/file]

Optionen:

-v verbose_level : Ausführlichkeit: kritisch | Fehler | Warnung | Info | Debug | Trace (Standard: Info)
-q : Ruhemodus. Drucken Sie keine Protokolle aus
-c config_file_path : Geben Sie die Konfigurationsdatei an. Wenn nicht festgelegt, wird 'config.json' aus dem aktuellen Arbeitsverzeichnis geladen
-p port : Remote -Port (Standard: 8011)
-t : Verwenden Sie Stdin als Eingabe
--resume : Versuchen Sie, die Dateiübertragung wieder aufzunehmen, wenn die Zieldatei vorliegt
--check-integrity : Überprüfen Sie die Dateiintegrität am Ende der Übertragung
-r : Dateien rekursiv kopieren
--max-transfers arg : MAX-Übertragung parallel (Standard: 1)

Beispiele

Kunde

Der Client führt einen Sockenproxy für Port 9000 aus und überträgt Verbindungsanforderungen an den Server 192.168.0.1:8000

 ssf -D 9000 -c config.json -p 8000 192.168.0.1

Server

Der Server wird an allen Netzwerkschnittstellen an Port 8011 gebunden

 ssfd

Der Server ist an 192.168.0.1:9000 gebunden

 ssfd -p 9000 -l 192.168.0.1

Kopieren Sie die lokale Datei in das Remote -Dateisystem

 ssfcp [-c config_file] [-p port] path/to/file host@absolute/path/directory_destination

 ssfcp [-c config_file] [-p port] path/to/file* host@absolute/path/directory_destination

 ssfcp [-c config_file] [-p port] -r path/to/dir host@absolute/path/directory_destination

Rohrdatei von der Standardeingabe zum Remote -Dateisystem

 data_in_stdin | ssfcp [-c config_file] [-p port] -t host@path/to/destination/file_destination

Kopieren Sie Remotedateien in lokales Dateisystem:

 ssfcp [-c config_file] [-p port] remote_host@path/to/file absolute/path/directory_destination

 ssfcp [-c config_file] [-p port] remote_host@path/to/file* absolute/path/directory_destination

 ssfcp [-c config_file] [-p port] -r remote_host@path/to/dir absolute/path/directory_destination

Konfigurationsdatei

{
  "ssf" : {
    "arguments" : " " ,
    "circuit" : [],
    "http_proxy" : {
      "host" : " " ,
      "port" : " " ,
      "user_agent" : " " ,
      "credentials" : {
        "username" : " " ,
        "password" : " " ,
        "domain" : " " ,
        "reuse_ntlm" : true ,
        "reuse_nego" : true
      }
    },
    "socks_proxy" : {
      "version" : 5 ,
      "host" : " " ,
      "port" : " 1080 "
    },
    "tls" : {
      "ca_cert_path" : " ./certs/trusted/ca.crt " ,
      "cert_path" : " ./certs/certificate.crt " ,
      "key_path" : " ./certs/private.key " ,
      "key_password" : " " ,
      "dh_path" : " ./certs/dh4096.pem " ,
      "cipher_alg" : " DHE-RSA-AES256-GCM-SHA384 "
    },
    "services" : {
      "datagram_forwarder" : { "enable" : true },
      "datagram_listener" : {
        "enable" : true ,
        "gateway_ports" : false
      },
      "stream_forwarder" : { "enable" : true },
      "stream_listener" : {
        "enable" : true ,
        "gateway_ports" : false
      },
      "copy" : { "enable" : false },
      "shell" : {
        "enable" : false ,
        "path" : " /bin/bash|C: \ windows \ system32 \ cmd.exe " ,
        "args" : " "
      },
      "socks" : { "enable" : true }
    }
  }
}

Argumente

Konfigurationsschlüssel	Beschreibung
Argumente	Verwenden Sie Konfigurationsargumente anstelle von angegebenen CLI -Argumenten (außer `-c` )

Mit dem arguments können der Benutzer die Befehlszeilenargumente in der Konfigurationsdatei anpassen. Diese Funktion ist eine bequeme Möglichkeit, verschiedene Kundenverbindungsprofile zu sparen.

Angesichts der folgenden Konfigurationsdatei conf.json :

{
  "ssf" : {
    "arguments" : " 10.0.0.1 -p 443 -D 9000 -L 11000:localhost:12000 -v debug "
  }
}

SSF extrahiert die angegebenen Argumente und verwendet sie als Ersatz der anfänglichen Argumente (außer -c ).

Zum Beispiel entspricht ssf -c conf.json ssf 10.0.0.1 -p 443 -D 9000 -L 11000:localhost:12000 -v debug :

Verbindung zu 10.0.0.1:443 ( 10.0.0.1 -p 443 ) herstellen
Starten Sie den Sockenservice ( -D 9000 )
Starten Sie den TCP -Port -Weiterleitungsdienst ( -L 11000:localhost:12000 )
Setzen Sie Ausführungsstufe auf Debuggen ( -v debug )

Schaltung

Konfigurationsschlüssel	Beschreibung
Schaltung	Relay -Kettenserver, die verwendet werden, um die Verbindung zum Remote -Server herzustellen

Die Schaltung ist ein JSON -Array, das die Bounce -Server und -Ports enthält, mit denen die Verbindung hergestellt wird. Sie sind wie folgt aufgeführt:

{
  "ssf" : {
    "circuit" : [
      { "host" : " SERVER1 " , "port" : " PORT1 " },
      { "host" : " SERVER2 " , "port" : " PORT2 " },
      { "host" : " SERVER3 " , "port" : " PORT3 " }
    ]
  }
}

Diese Konfiguration erstellt die folgende Verbindungskette:

 CLIENT -> SERVER1:PORT1 -> SERVER2:PORT2 -> SERVER3:PORT3 -> TARGET

Proxy

SSF unterstützt die Verbindung durch:

HTTP -Proxy mithilfe der HTTP -Methode CONNECT HTTP
Sockenproxy (V4 oder V5)

HTTP -Proxy

Konfigurationsschlüssel	Beschreibung
http_proxy.host	HTTP -Proxy -Host
http_proxy.port	HTTP -Proxy -Port
http_proxy.user_agent	Benutzer-Agent-Header-Wert in der HTTP-Verbindungsanforderung
http_proxy.credentials.username	Proxy -Benutzername -Anmeldeinformationen (alle Plattform: Basic oder Digest, Windows: NTLM und Verhandlung, wenn reusse = false)
http_proxy.credentials.password	Proxy -Kennwort -Anmeldeinformationen (alle Plattform: Basic oder Digest, Windows: NTLM und Verhandlung, wenn reusse = false)
http_proxy.credentials.domain	Benutzerdomäne (NTLM und nur über Windows verhandeln)
http_proxy.credentials.rus_ntlm	Wiederverwenden aktueller Computerbenutzeranmeldeinformationen, um sich mit Proxy NTLM Auth (SSO) zu authentifizieren
http_proxy.credentials.rus_kerb	Wiederverwenden aktueller Computerbenutzeranmeldeinformationen (Kerberos -Ticket), um sich mit Proxy -Verhandlungsauth (SSO) zu authentifizieren

Unterstützte Authentifizierungsschemata:

Basic
Verdauen
NTLM (nur Windows)
Verhandeln Sie mit Kerberos (Wiederverwendung von Computerbenutzeranmeldeinformationen)

Sockenproxy

Konfigurationsschlüssel	Beschreibung
SOCKS_PROXY.VERSION	Sockenversion (4 oder 5)
SOCKS_PROXY.HOST	Socken -Proxy -Host
SOCKS_PROXY.PORT	Socken -Proxy -Port

Kein Authentifizierungsschema unterstützt.

Tls

Verwenden externer Dateien

Konfigurationsschlüssel	Beschreibung
tls.ca_cert_path	Relativer oder absoluter Filepath zur CA -Zertifikatdatei
tls.cert_path	relative oder absolute Filepath in die Instanzzertifikatdatei
tls.key_path	relative oder absolute Filepath in die private Schlüsseldatei
tls.key_password	Schlüsselkennwort
tls.dh_path	relativer oder absoluter Filepath zur Diffie-Hellman-Datei (nur Server)
tls.cipher_alg	Cipher -Algorithmus

Bei Standardoptionen sollten die folgenden Dateien und Ordner im Arbeitsverzeichnis des Clients oder im Server enthalten sein:

./certs/dh4096.pem
./certs/certificate.crt
./certs/private.key
./certs/trusted/ca.crt

Wo:

DH4096.PEM enthält die Diffie-Hellman-Parameter (generieren DH-Parameter)
Certificate.crt und privat.key sind das Zertifikat und der private Schlüssel des SSF -Servers oder des Clients (Zertifikat generieren)
CA.CRT ist die verkettete Liste der vom SSF -Server oder Client vertrauenswürdigen Zertifikate (CA generieren)

Wenn Sie diese Dateien auf verschiedenen Pfaden haben möchten, können Sie sie dank der TLS -Pfadschlüssel anpassen:

{
  "ssf" : {
    "tls" : {
      "ca_cert_path" : " ./certs/trusted/ca.crt " ,
      "cert_path" : " ./certs/certificate.crt " ,
      "key_path" : " ./certs/private.key " ,
      "key_password" : " " ,
      "dh_path" : " ./certs/dh4096.pem " ,
      "cipher_alg" : " DHE-RSA-AES256-GCM-SHA384 "
    }
  }
}

Nur mit der Konfigurationsdatei

Konfigurationsschlüssel	Beschreibung
tls.ca_cert_buffer	CA -Zertifikatdateiinhalt im PEM -Format (: Warnung: `n` zwischen Daten und PEM -Header/Fußzeile)
tls.cert_buffer	Inhalt des Instanzzertifikatsdatei im PEM -Format (: WARNUNG: `n` zwischen Daten und PEM -Header/Fußzeile)
tls.key_buffer	Private Schlüsseldateiinhalte im PEM -Format (: Warnung: `n` zwischen Daten und PEM -Header/Fußzeile)
tls.key_password	Schlüsselkennwort
tls.dh_buffer	Diffie-Hellman-Parameterdateiinhalte im PEM-Format (: Warnung: `n` zwischen Daten und PEM-Header/Fußzeile, nur Server)
tls.cipher_alg	Cipher -Algorithmus

Sie können die TLS -Parameter direkt in die Konfigurationsdatei integrieren, indem Sie die tls.ca_cert_buffer , tls.cert_buffer , tls.key_buffer und tls.dh_buffer KEYS verwenden.

{
  "ssf" : {
    "tls" : {
      "ca_cert_buffer" : " -----BEGIN CERTIFICATE----- n ... n -----END CERTIFICATE----- " ,
      "cert_buffer" : " -----BEGIN CERTIFICATE----- n ... n -----END CERTIFICATE----- " ,
      "key_buffer" : " -----BEGIN RSA PRIVATE KEY----- n ... n -----END RSA PRIVATE KEY----- " ,
      "key_password" : " " ,
      "dh_buffer" : " -----BEGIN DH PARAMETERS----- n ... n -----END DH PARAMETERS----- " ,
      "cipher_alg" : " DHE-RSA-AES256-GCM-SHA384 "
    }
  }
}

Zertifikate, private Schlüssel und DH -Parameter müssen im PEM -Format sein. Euen n zwischen Daten und PEM -Header/Fußzeile sind obligatorisch.

Microservices

Konfigurationsschlüssel	Beschreibung
Dienstleistungen.*. Aktivieren	Aktivieren/deaktivieren Sie Mikroservice
Dienstleistungen.*. Gateway_ports	Aktivieren/deaktivieren Sie Gateway -Ports
services.shell.path	binärer Weg zur Schalenerstellung verwendet
services.shell.args	Binäre Argumente für die Erstellung von Schalen verwendet

Die Funktionen von SSF werden mit Microservices erstellt (TCP -Weiterleitung, Remote -Socken, ...)

Es gibt 7 Microservices:

stream_forwarder
Stream_Listener
datagram_forwarder
Datagram_Listener
Kopie
Socken
Hülse

Jede Funktion ist die Kombination von mindestens einem Client -Microservice und einem Server -Microservice.

Diese Tabelle fasst zusammen, wie jede Funktion zusammengestellt wird:

SSF -Funktion	Microservice Client Seite	MicroService Server -Seite
`-L` : TCP -Weiterleitung	Stream_Listener	stream_forwarder
`-R` : Remote -TCP -Weiterleitung	stream_forwarder	Stream_Listener
`-U` : UDP -Weiterleitung	Datagram_Listener	datagram_forwarder
`-V` : Remote -UDP -Weiterleitung	datagram_forwarder	Datagram_Listener
`-D` : Socken	Stream_Listener	Socken
`-F` : Remote -Socken	Socken	Stream_Listener
`-X` : Shell	Stream_Listener	Hülse
`-Y` : Fernschale	Hülse	Stream_Listener

Diese Architektur erleichtert es einfacher, Remote -Funktionen zu erstellen: Sie verwenden dieselben Mikrodienste, jedoch auf der anderen Seite.

ssf und ssfd sind mit vorab fähigen Microservices ausgestattet. Hier ist die Standardkonfiguration von Microservices:

{
  "ssf" : {
    "services" : {
      "datagram_forwarder" : { "enable" : true },
      "datagram_listener" : { "enable" : true },
      "stream_forwarder" : { "enable" : true },
      "stream_listener" : { "enable" : true },
      "socks" : { "enable" : true },
      "copy" : { "enable" : false },
      "shell" : { "enable" : false }
    }
  }
}

Um einen Microservice zu aktivieren oder zu deaktivieren, setzen Sie den Aktivieren von true oder false enable .

Der Versuch, eine Funktion zu verwenden, die einen deaktivierten Microservice erfordert, führt zu einer Fehlermeldung.

So generieren Sie Zertifikate für TLS -Verbindungen

Manuell

Erzeugen von Diffie-Hellman-Parametern

openssl dhparam 4096 -outform PEM -out dh4096.pem

Generierung einer selbstsignierten Zertifizierungsbehörde (CA)

Erstellen Sie zunächst eine Datei namens extfile.txt mit den folgenden Zeilen:

 [ v3_req_p ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

Generieren Sie dann ein selbstsigniertes Zertifikat (CA) CA.CRT und seinen privaten Schlüssel Ca.Key :

openssl req -x509 -nodes -newkey rsa:4096 -keyout ca.key -out ca.crt -days 3650

Erstellen eines privaten Schlüssels und eines Zertifikats (bei der CA signiert)

Generieren Sie einen privaten Schlüssel privat.Key und ein Zertifikatantragszertifikat.csr :

openssl req -newkey rsa:4096 -nodes -keyout private.key -out certificate.csr

Generieren Sie das Zertifikat ( Zertifikat.PEM ), indem Sie das CSR bei der CA ( CA.CRT , CA.KEY ) unterschreiben:

openssl x509 -extfile extfile.txt -extensions v3_req_p -req -sha1 -days 3650 -CA ca.crt -CAkey ca.key -CAcreateserial -in certificate.csr -out certificate.pem

Expandieren

Zusätzliche Informationen

Version 3.0.0
Typ C/C++
Aktualisierungszeit 2025-03-14
Größe 595.85KB
Kommt von Github

Ähnliche Anwendungen

DragonBonesCPP

2025-03-15
Beeftext

2025-03-15
networkit

2025-03-15
TensorflowASR

2025-03-16
libjson rpc cpp

2025-03-16
PEGTL

2025-03-15