ssf
3.0.0
O Secure Socket Funneling (SSF) é um ferramenta de rede e um kit de ferramentas.
Ele fornece maneiras simples e eficientes de encaminhar dados de vários soquetes (TCP ou UDP) através de um único túnel TLS seguro para um computador remoto.
O SSF é uma plataforma cruzada (Windows, Linux, OSX) e é executável independente.
Características:
Baixe binários pré -construídos
Documentação
Construir no Windows
Construa no Unix/Linux
SSF de compilação cruzada (por exemplo, Raspberry Pi)
Uso: ssf[.exe] [options] server_address
Opções:
-v verbose_level : verbosity: crítico | erro | aviso | info | debug | rastreio (padrão: informações)
-q : modo silencioso. Não imprima toras
-p port : porta remota (padrão: 8011)
-c config_file_path : especifique o arquivo de configuração. Se não estiver definido, 'config.json' é carregado do diretório de trabalho atual
-m attempts : Tentativas de conexão máximas sem sucesso antes de parar (padrão: 1)
-t delay : Hora de esperar antes de tentar se reconectar em segundos (Padrão: 60)
-n : não tente reconectar o cliente se a conexão for interrompida
-g : Permitir portas de gateway. Permita que o cliente vincule soquetes locais para um serviço a um endereço específico em vez de "localhost"
-S : exibir status de microsserviços (ligado/desativado)
Opções de serviços:
-D [[bind_address]:]port : execute um proxy de meias no servidor acessível em [[bind_address]:]port no lado local
-F [[bind_address]:]port : execute um proxy de meias no host local acessível do servidor em [[bind_address]:]port
-X [[bind_address]:]port : Encaminhe a E/S do shell do servidor para a porta especificada no lado local. Cada conexão cria um novo processo de shell
-Y [[bind_address]:]port : Encaminhar E/S da Shell local para a porta especificada no servidor
-L [[bind_address]:]port:host:hostport : conexões TCP encaminhadas para [[bind_address]:]port no host local para host:hostport no servidor
-R [[bind_address]:]port:host:hostport : conexões tcp encaminhadas para [[bind_address]:]port no servidor para host:hostport no lado local
-U [[bind_address]:]port:host:hostport : encaminhar tráfego UDP local em [[bind_address]:]port para host:hostport no servidor
-V [[bind_address]:]port:host:hostport : tráfego UDP forward em [[bind_address]:]port no servidor para host:hostport no lado local
Uso: ssfd[.exe] [options]
Opções:
-v verbose_level : verbosity: crítico | erro | aviso | info | debug | rastreio (padrão: informações)
-q : modo silencioso. Não imprima toras
-c config_file_path : especifique o arquivo de configuração. Se não estiver definido, 'config.json' é carregado do diretório de trabalho atual
-p port : Porta Local (Padrão: 8011)
-R : o servidor retransmitirá apenas conexões
-l host : defina o endereço de ligação ao servidor
-g : Permitir portas de gateway. Permita que o cliente vincule soquetes locais para um serviço a um endereço específico em vez de "localhost"
-S : exibir status de microsserviços (ligado/desativado)
O recurso de cópia deve ser ativado no arquivo de configuração do cliente e do servidor:
{
"ssf" : {
"services" : {
"copy" : { "enable" : true }
}
}
} Uso: ssfcp[.exe] [options] [host@]/absolute/path/file [[host@]/absolute/path/file]
Opções:
-v verbose_level : verbosity: crítico | erro | aviso | info | debug | rastreio (padrão: informações)
-q : modo silencioso. Não imprima toras
-c config_file_path : especifique o arquivo de configuração. Se não estiver definido, 'config.json' é carregado do diretório de trabalho atual
-p port : porta remota (padrão: 8011)
-t : use stdin como entrada
--resume : Tente retomar a transferência de arquivos se o arquivo de destino existir
--check-integrity : verifique a integridade do arquivo no final da transferência
-r : copiar arquivos de forma recursiva
--max-transfers arg : MAX Transferências em paralelo (Padrão: 1)
O cliente executará um proxy de meias na porta 9000 e transferirá solicitações de conexão para o servidor 192.168.0.1:8000
ssf -D 9000 -c config.json -p 8000 192.168.0.1
O servidor estará vinculado à porta 8011 em todas as interfaces de rede
ssfd
O servidor estará vinculado a 192.168.0.1:9000
ssfd -p 9000 -l 192.168.0.1
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
data_in_stdin | ssfcp [-c config_file] [-p port] -t host@path/to/destination/file_destination
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
{
"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 }
}
}
}| Chave de configuração | Descrição |
|---|---|
| argumentos | Use argumentos de configuração em vez de determinados argumentos da CLI (exceto -c ) |
A chave arguments permite que o usuário personalize os argumentos da linha de comando no arquivo de configuração. Esse recurso é uma maneira conveniente de salvar diferentes perfis de conexão do cliente.
Dado o seguinte arquivo de configuração conf.json :
{
"ssf" : {
"arguments" : " 10.0.0.1 -p 443 -D 9000 -L 11000:localhost:12000 -v debug "
}
} O SSF extrairá os argumentos fornecidos e os usará como uma substituição dos argumentos iniciais (exceto -c ).
Por exemplo, ssf -c conf.json será equivalente ao ssf 10.0.0.1 -p 443 -D 9000 -L 11000:localhost:12000 -v debug :
10.0.0.1:443 ( 10.0.0.1 -p 443 )-D 9000 )-L 11000:localhost:12000 )-v debug ) | Chave de configuração | Descrição |
|---|---|
| circuito | Servidores de cadeia de retransmissão usados para estabelecer a conexão com o servidor remoto |
O circuito é uma matriz JSON que contém os servidores e portas de salto que serão usados para estabelecer a conexão. Eles estão listados da seguinte forma:
{
"ssf" : {
"circuit" : [
{ "host" : " SERVER1 " , "port" : " PORT1 " },
{ "host" : " SERVER2 " , "port" : " PORT2 " },
{ "host" : " SERVER3 " , "port" : " PORT3 " }
]
}
}Esta configuração criará a seguinte cadeia de conexão:
CLIENT -> SERVER1:PORT1 -> SERVER2:PORT2 -> SERVER3:PORT3 -> TARGET
O SSF suporta a conexão através de:
CONNECT| Chave de configuração | Descrição |
|---|---|
| http_proxy.host | Host http proxy |
| http_proxy.port | Porta proxy http |
| http_proxy.user_agent | Valor do cabeçalho agente do usuário na solicitação HTTP Connect |
| http_proxy.credentials.username | Credenciais de nome de usuário proxy (todas a plataforma: BASIC ou DIGEST, Windows: NTLM e negocie se reutiliza = false) |
| http_proxy.credentials.password | Credenciais de senha de proxy (Toda a plataforma: BASIC ou DIGEST, Windows: NTLM e negocie se reutiliza = false) |
| http_proxy.credentials.domain | Domínio do usuário (NTLM e negocie apenas a autenticação no Windows) |
| http_proxy.credentials.reuse_ntlm | Reutilizar as credenciais atuais de usuários de computador para autenticar com o proxy ntlm auth (SSO) |
| http_proxy.credentials.reuse_kerb | Reutilize as credenciais atuais de usuários de computador (ticket kerberos) para autenticar com proxy negociar auth (sso) |
Esquemas de autenticação suportados:
| Chave de configuração | Descrição |
|---|---|
| Socks_proxy.version | Versão de meias (4 ou 5) |
| Socks_proxy.host | Host proxy de meias |
| Socks_proxy.port | Porta proxy de meias |
Nenhum esquema de autenticação suportado.
| Chave de configuração | Descrição |
|---|---|
| tls.ca_cert_path | FilePath relativo ou absoluto para o arquivo de certificado CA |
| tls.cert_path | FilePath relativo ou absoluto para o arquivo de certificado de instância |
| tls.key_path | FilePath relativo ou absoluto para o arquivo de chave privado |
| tls.key_password | Senha -chave |
| tls.dh_path | FilePath relativo ou absoluto com o arquivo Diffie-Hellman (somente servidor) |
| tls.cipher_alg | Algoritmo de cifra |
Com as opções padrão, os seguintes arquivos e pastas devem estar no diretório de trabalho do cliente ou do servidor:
./certs/dh4096.pem./certs/certificate.crt./certs/private.key./certs/trusted/ca.crtOnde:
Se você deseja esses arquivos em caminhos diferentes, é possível personalizá -los graças às teclas do caminho do TLS:
{
"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 "
}
}
}| Chave de configuração | Descrição |
|---|---|
| tls.ca_cert_buffer | Conteúdo do arquivo de certificado da CA no formato PEM (: Aviso: n entre dados e cabeçalho PEM/rodapé) |
| tls.cert_buffer | Conteúdo do arquivo de certificado de instância no formato PEM (: aviso: n entre dados e cabeçalho PEM/rodapé) |
| tls.key_buffer | Conteúdo do arquivo de chave privada no formato PEM (: Aviso: n entre dados e cabeçalho/rodapé do PEM) |
| tls.key_password | Senha -chave |
| tls.dh_buffer | Parâmetros Diffie-Hellman Conteúdo do arquivo em formato PEM (: Aviso: n entre dados e cabeçalho/rodapé do PEM, somente servidor) |
| tls.cipher_alg | Algoritmo de cifra |
Você pode integrar os parâmetros TLS diretamente no arquivo de configuração usando o tls.ca_cert_buffer , tls.cert_buffer , tls.key_buffer e tls.dh_buffer KEYS.
{
"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 "
}
}
} Certificados, chaves privadas e parâmetros DH devem estar no formato PEM.n entre dados e cabeçalho PEM/rodapé são obrigatórios.
| Chave de configuração | Descrição |
|---|---|
| Serviços.*. Ativar | Ativar/desativar o microsserviço |
| Serviços.*. Gateway_ports | Ativar/desativar as portas de gateway |
| Serviços.shell.path | Caminho binário usado para criação de casca |
| Services.shell.args | Argumentos binários usados para criação de casca |
Os recursos do SSF são construídos usando microsserviços (encaminhamento TCP, meias remotas, ...)
Existem 7 microsserviços:
Cada recurso é a combinação de pelo menos um microsserviço do lado do cliente e um microsserviço do lado do servidor.
Esta tabela resume como cada recurso é montado:
| recurso SSF | MicrosService Client Late | MicrosService Server Lado |
|---|---|---|
-L : encaminhamento TCP | stream_listener | stream_forwarder |
-R : encaminhamento remoto de TCP | stream_forwarder | stream_listener |
-U : encaminhamento UDP | datagram_listener | datagram_forwarder |
-V : encaminhamento Remote UDP | datagram_forwarder | datagram_listener |
-D : meias | stream_listener | meias |
-F : meias remotas | meias | stream_listener |
-X : shell | stream_listener | concha |
-Y : concha remota | concha | stream_listener |
Essa arquitetura facilita a criação de recursos remotos: eles usam os mesmos microsserviços, mas no lado oposto.
ssf e ssfd vêm com microsserviços pré-habilitados. Aqui está a configuração padrão de microsserviços:
{
"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 }
}
}
} Para ativar ou desativar um microsserviço, defina a chave enable para true ou false .
Tentar usar um recurso que requer um microsserviço desativado resultará em uma mensagem de erro.
openssl dhparam 4096 -outform PEM -out dh4096.pemPrimeiro de tudo, crie um arquivo chamado extfile.txt contendo as seguintes linhas:
[ v3_req_p ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
Em seguida, gerar um certificado autoassinado (o CA) ca.crt e sua chave privada ca.key :
openssl req -x509 -nodes -newkey rsa:4096 -keyout ca.key -out ca.crt -days 3650Gerar uma chave privada privada.Key e um certificado de solicitação de assinatura de certificado.csr :
openssl req -newkey rsa:4096 -nodes -keyout private.key -out certificate.csrGere o certificado ( certificado.pem ) assinando a RSE com a CA ( ca.crt , ca.key ):
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
