Sim, crie o novo usuário e defina seu UID para ser o mesmo que o outro.
Isso é comumente usado para criar logins raiz "alternativos".
existe uma maneira de configurar aliases de usuários no unix, de modo que, se você tiver um usuário, my_user , eles podem fazer login com um nome de usuário alternativo, ou seja, my_user_alternate e ainda logado como my_user
Você pode fazer isso adicionando um novo usuário com o mesmo ID de usuário (uid) que você deseja como alternativa.
por exemplo:
useradd -o -u 1001 my_user_alternate
É a opção -o que permite que você tenha o mesmo uid. (Supondo que o usuário que você quer 'copiar' tenha um fluxo de 1020)
Tags user-management unix
Estou tentando fazer com que meu tráfego de entrada e saída pareça o mais legítimo possível perto do tráfego SSL. Existe uma maneira de proteger meu próprio tráfego para garantir que ele se pareça com o tráfego SSL e não com o tráfego do OpenVPN? E com base na configuração da minha configuração, todo o tráfego usa a porta 443, que é a porta SSL?
Minha configuração é a seguinte:
STUNNEL no laptop:
%pre%OPENVPN CONFIG NO laptop:
%pre%CONFIGURAÇÃO DO STUNNEL NO SERVIDOR:
%pre%OPENVPN CONFIG no servidor:
%pre%Sua VPN está usando o TCP como um protocolo de transporte. A instância stunnel é usada para encapsular o conteúdo do fluxo TCP em TLS / TCP. Você obtém esta pilha de protocolos:
%pre%Entre as instâncias do stunnel, você tem essa pilha de protocolos no fio:
%pre%Como o TLS criptografa sua carga útil, um invasor só consegue ver:
%pre%Então, sim, é um tráfego TLS simples (pode ser HTTP / TLS, SMTP / TLS, POP / TLS ou qualquer outra coisa para alguém que esteja olhando para o tráfego, mas se parece muito com HTTP / TLS, pois a porta TCP 443 é usava). Você pode verificar isso usando wireshark: registre o tráfego entre as instâncias do stunnel. Na interface do usuário wireshark (botão direito em um pacote do fluxo), você pode solicitar ao wireshark para interpretar o tráfego como TLS: ele o reconhecerá como tráfego TLS (você verá as diferentes mensagens TLS, mas não a carga útil da sessão TLS) .
Você pode querer usar SNI no cliente para parecer com o que um navegador moderno faria Faz. Você pode querer usar o ALPN , mas stunnel atualmente não lida com isso.
Em comparação, se você estiver usando o OpenVPN, você terá algo assim:
%pre%Que se parece com isso:
%pre%A camada TLS incorporada não encapsula os pacotes (IP, Ethernet), mas é usada apenas para configurar a sessão e autenticar:
%pre%Nesse caso, o tráfego não parece um tráfego TLS simples, mas é obviamente o OpenVPN. Se você interpretar esse tráfego como OpenVPN no wireshark, você reconhecerá as mensagens OpenVPN e dentro delas as mensagens TLS (mas não a carga útil).
Você deve estar ciente de que, se um invasor passivo não puder dizer que seu servidor remoto é, na verdade, um servidor OpenVPN, um invasor ativo poderá descobrir isso: simplesmente conectando-se ao seu servidor por TLS, ele será capaz de confirmar que é não um servidor HTTP / TLS. Ao tentar falar o protocolo OpenVPN, ele será capaz de detectar que seu servidor é um servidor OpenVPN / TLS.
Se você está preocupado com isso, é possível ativar a autenticação de cliente TLS: um invasor não poderá iniciar uma sessão de TLS em funcionamento e não poderá adivinhar qual carga útil será encapsulada por TLS.
* Aviso: ** Eu não estou falando sobre o suporte ao TLS embutido no OpenVPN (veja acima para explicação sobre por que ele não irá ajudá-lo).
Outra solução é servir HTTP e OpenVPN na sessão TLS. sslh pode ser usado para detectar automaticamente a carga útil do protocolo e despachar para um servidor HTTP / TCP simples ou Servidor OpenVPN / TCP. O servidor será parecido com o servidor HTTP / TLS padrão, mas alguém que tente falar OpenVPN / TLS com esse servidor será capaz de detectar que ele também é um servidor OpenVPN / TLS.
%pre%Outra solução é usar um servidor HTTP / TLS padrão e usar HTTP CONNECT / TLS para conectar-se ao servidor OpenVPN: ele se parecerá com um servidor HTTP padrão. Você pode até mesmo exigir autenticação do cliente para autorizar a solicitação HTTP CONNECT (o squid deve poder fazer isso).
O OpenVPN tem a opção de usar um proxy HTTP:
%pre%Você deve conseguir combinar isso com uma instância stunnel conectando-se a um HTTPS PROXY remoto:
%pre%Qual implementaria essa pilha de protocolos:
%pre%A resposta do ysdx é ótima e descreve muito bem como o tráfego ficará no fio.
Não mencionado, no entanto, é que a análise de tráfego pode percorrer um longo caminho para a identificação de aplicativos.Vamos supor que sua conexão com o OpenVPN se pareça com uma conexão https na rede, de modo que um invasor não possa ler o fluxo de bytes e saber que tipo de conexão ele é.
Uma conexão típica de https não vai durar muito tempo. Talvez o seu navegador mantenha uma conexão aberta ao seu servidor de e-mail, eu não sei. Em geral, no entanto, haverá muitas conexões relativamente curtas para diversos servidores remotos.
OTOH, a conexão OpenVPN pode viver por horas ou dias, e enviará muitos dados para o servidor openvpn.
Você pode atenuar a conexão de longa duração periodicamente descartando e reiniciando a conexão. Isso supostamente tem implicações para o tráfego de aplicativos, mas pode ser viável. O padrão de lotes e lotes de tráfego entre você e o servidor openvpn, no entanto, será muito mais difícil de camuflar.