Mudanças entre as edições de "Configurando um gateway de acesso remoto com Guacamole"
(11 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
+ | |||
=== Introdução === | === Introdução === | ||
− | Com a pandemia do COVID-19, nossa rotina diária de trabalho | + | Com a pandemia do COVID-19, nossa rotina diária de trabalho em ir a empresa todos os dias sofreu uma brusca alteração e a necessidade de acesso aos recursos computacionais remotamente causou uma correria na busca de soluções de TI para suportar essa demanda. O Home Office que muito se ouvia falar foi finalmente instituído na maioria das empresas ao redor do mundo. |
− | No cenário das Universidades não foi diferente. A necessidade de acesso equipamentos de pesquisa em laboratórios, aos | + | No cenário das Universidades não foi diferente. A necessidade de acesso a equipamentos de pesquisa em laboratórios, aos laboratórios de informática, sistemas internos e servidores exigiu de todos os profissionais de TI uma corrida por soluções que envolva um acesso de remoto de forma segura, fácil para o usuário e que demonstre um bom desempenho no acesso de um grande conjunto de dispositivos computacionais de maneira orquestrada. |
− | Segundo o levantamento da empresa [https://www.kaspersky.com.br/blog/ataques-rdp-brasil-home-office-pesquisa/15590/ Kaspersky] houve um aumento em 330% de ataques a sistemas de acesso remoto no Brasil. A adesão “forçada” pelo Home Office fez disparar os ciberataques direcionados ao “Remote Desktop Protocol (RDP)” e em menor quantidade também ao VNC (Virtual Network Computing). Devido a necessidade de transferir a maioria dos seus colaboradores para o trabalho a distância em seus lares, muitas empresas deixaram as medidas de segurança | + | Segundo o levantamento da empresa [https://www.kaspersky.com.br/blog/ataques-rdp-brasil-home-office-pesquisa/15590/ Kaspersky] houve um aumento em 330% de ataques a sistemas de acesso remoto no Brasil. A adesão “forçada” pelo Home Office fez disparar os ciberataques direcionados ao “Remote Desktop Protocol (RDP)” e em menor quantidade também ao "VNC (Virtual Network Computing)". Devido a necessidade de transferir a maioria dos seus colaboradores para o trabalho a distância em seus lares, muitas empresas deixaram as medidas de segurança de lado, fazendo liberações indiscriminadas sem proteção de portas de acesso remoto no firewall corporativo, muitas vezes sem criptografia, sem uma política de senhas fortes, ou não habilitando a autenticação de dois fatores. |
− | Este breve artigo tem como objetivo | + | Este breve artigo tem como objetivo descrever uma configuração básica inicial de forma sugerir uma solução de um gateway de acesso remoto centralizado, utilizando o software livre e de código aberto chamado Apache Guacamole. |
=== Projeto Apache Guacamole === | === Projeto Apache Guacamole === | ||
− | O projeto [https://guacamole.apache.org/ Apache Guacamole] é uma arquitetura completa que possibilita o acesso remoto a desktops utilizando apenas o navegador Web, sem a instalação de nenhum plug-in ou software cliente. Uma vez conectado ao servidor Guacamole ele age com um intermediário (proxy) até um | + | O projeto [https://guacamole.apache.org/ Apache Guacamole] é uma arquitetura completa que possibilita o acesso remoto a desktops utilizando apenas o navegador Web, sem a instalação de nenhum plug-in ou software cliente (''clientless''). Uma vez conectado ao servidor Guacamole ele age com um intermediário (''proxy'') até um computador específico localizado na rede local da empresa, utilizando os protocolos suportados como: RDP, VNC, SSH. Na Figura 1 podemos compreender toda a arquitetura e os seus componentes durante uma conexão fora do perímetro corporativo. |
+ | |||
+ | [[Arquivo:Guac-arch.png|miniaturadaimagem|Figura 1 - Arquitetura Guacamole|379x379px]] | ||
− | |||
− | Todo o projeto é composto por um daemon guacamole-server, que fornece o proxy guacd e as bibliotecas relacionadas e o daemon guacamole-client, que fornece o cliente para ser atendido pelo contêiner do servlet do Tomcat. Portanto precisamos que o ambiente esteja preparado com o Tomcat | + | Todo o projeto é composto por um ''daemon'' guacamole-server, que fornece o ''proxy'' guacd e as bibliotecas relacionadas e o ''daemon'' guacamole-client, que fornece o cliente para ser atendido pelo contêiner do servlet do Tomcat. Portanto precisamos que o ambiente esteja preparado com o Tomcat (versão maior que 8.5) e o Java OpenJDK. O guacamole-client está disponível em formato binário, mas o guacamole-server deve ser construído a partir do código fonte. Ambas as partes serão descritas com detalhes a seguir. |
=== Apache Guacamole Server === | === Apache Guacamole Server === | ||
Linha 24: | Linha 26: | ||
* Suporte ao VNC: depende da biblioteca libvncclient | * Suporte ao VNC: depende da biblioteca libvncclient | ||
− | * Suporte ao RDP: depende do FreeRDP (utilizar a versão 2.0 | + | * Suporte ao RDP: depende do FreeRDP (utilizar a versão maior que 2.0, atualizada, para evitar problemas de segurança já conhecidos) |
* Suporte ao SSH: depende de libssh2, OpenSSL e Pango | * Suporte ao SSH: depende de libssh2, OpenSSL e Pango | ||
* Suporte ao Kubernetes: depende de libwebsockets, OpenSSL e Pango | * Suporte ao Kubernetes: depende de libwebsockets, OpenSSL e Pango | ||
− | A compilação do guacamole-server cria um executável chamado guacd que pode ser executado manualmente ou de forma automática como serviço. | + | A compilação do guacamole-server cria um executável chamado guacd que pode ser executado manualmente ou de forma automática como serviço. É desejável e recomendado sempre fazer o download do código fonte mais recente clonando o repositório git do guacamole pelo GitHub: |
− | É desejável e recomendado sempre fazer o download do código fonte mais recente clonando o repositório git do guacamole | ||
<pre> | <pre> | ||
− | git clone git://github.com/apache/guacamole-server.git | + | # git clone git://github.com/apache/guacamole-server.git |
</pre> | </pre> | ||
− | Quando o código fonte do guacamole-server for baixado e extraído você precisará construir o arquivo configure, que no caso do download pelo GitHub | + | Quando o código fonte do guacamole-server for baixado e extraído você precisará construir o arquivo configure, que no caso do download pelo GitHub não vem incluso. |
<pre> | <pre> | ||
Linha 51: | Linha 52: | ||
=== Apache Guacamole Client === | === Apache Guacamole Client === | ||
− | A parte do guacamole-client é compactada em um arquivo totalmente independente, chamado guacamole.war e o seu download pode ser feito diretamente pelo site do [https://guacamole.apache.org/releases/1. | + | A parte do guacamole-client é compactada em um arquivo totalmente independente, chamado guacamole.war e o seu download pode ser feito diretamente pelo site do [https://guacamole.apache.org/releases/1.3.0/ Apache Guacamole]. Novamente sempre é recomendado a última versão estável. A sua instalação envolve uma cópia do arquivo para o diretório do contêiner do servlet CATALINA_HOME/webapps/. O diretório varia de acordo com a instalação em cada distribuição mas, normalmente o diretório padrão é /usr/share/tomcat/webapps. |
<pre> | <pre> | ||
Linha 57: | Linha 58: | ||
</pre> | </pre> | ||
− | Depois que o arquivo guacamole.war for copiado é necessário reiniciar o Tomcat para descompactar o arquivo . | + | Depois que o arquivo guacamole.war for copiado é necessário reiniciar o Tomcat para descompactar o arquivo .war na aplicação. |
<pre> | <pre> | ||
Linha 63: | Linha 64: | ||
</pre> | </pre> | ||
− | Verificar possíveis | + | Verificar sempre possíveis mensagens de erros é uma boa prática e mesmo que o Guacamole esteja sendo executado com sucesso, ele está desconfigurado e devemos realizar algumas etapas adicionais no arquivo de configuração principal guacamole.properties. |
− | |||
− | === Configurando o guacamole.properties === | + | === Configurando o arquivo guacamole.properties === |
Para que o guacamole-server funcione você deve configurá-lo com um ou mais método de autenticação. O método padrão lê todos os usuários de um único arquivo chamado user-mapping.xml. Um exemplo de como configurar um usuário básico pode ser realizado da seguinte forma: | Para que o guacamole-server funcione você deve configurá-lo com um ou mais método de autenticação. O método padrão lê todos os usuários de um único arquivo chamado user-mapping.xml. Um exemplo de como configurar um usuário básico pode ser realizado da seguinte forma: | ||
Linha 81: | Linha 81: | ||
Todos os arquivos de configurações se encontram no diretório padrão /etc/guacamole, onde são divididos em: | Todos os arquivos de configurações se encontram no diretório padrão /etc/guacamole, onde são divididos em: | ||
− | * guacamole.properties: principal arquivo de configuração | + | * guacamole.properties: principal arquivo de configuração. |
− | * logback.xml: o sistema de registro chamado Logback para todas as mensagens | + | * logback.xml: o sistema de registro chamado Logback para todas as mensagens. |
− | * extensions: o local de todas as extensões do Guacamole que carregará automaticamente os .war | + | * extensions: o local de todas as extensões do Guacamole que carregará automaticamente os arquivos .war |
− | * lib: o diretório de bibliotecas requeridas por quaisquer extensões do Guacamole | + | * lib: o diretório de bibliotecas requeridas por quaisquer extensões do Guacamole e drivers de banco de dados. |
− | Porém, a configuração do Guacamole começa a ficar interessante e divertida quando você tem uma base de dados de usuários e | + | Porém, a configuração do Guacamole começa a ficar interessante e divertida quando você tem uma base de dados de usuários e quer integrar, como por exemplo, o LDAP. Existem muitos tutoriais na Internet com exemplos de configurações do arquivo guacamole.properties para integrar as bases de dados. Alguns que foram pesquisados são de versões antigas e parâmetros que não são mais necessários na versão atual. Depois de muitas tentativas e interagindo com a comunidade de usuários do Guacamole, foi possível uma configuração funcional de uma consulta em uma base de dados LDAP (Active Directory) em conjunto com a base de dados MySQL/MariaDB, no qual é necessário para o gerenciamento dos usuários, grupos e atribuições dos desktops a serem conectados. |
==== Autenticação MySQL/MariaDB ==== | ==== Autenticação MySQL/MariaDB ==== | ||
− | Para habilitar o suporte a autenticação MySQL/MariaDB é necessário fazer o download das extensões no site [https://guacamole.apache.org/releases/1. | + | Para habilitar o suporte a autenticação MySQL/MariaDB é necessário fazer o download das extensões no site [https://guacamole.apache.org/releases/1.3.0/ Quacamole Releases] |
− | O arquivo guacamole-auth-jdbc-mysql-1. | + | O arquivo guacamole-auth-jdbc-mysql-1.3.0.jar deve ser copiado para o diretório /etc/guacamole/extensions |
− | O driver MySQL JDBC não vem junto com o pacote de extensão .jar e o seu | + | O driver MySQL JDBC não vem junto com o pacote de extensão .jar e o seu download pode ser feito no site do [https://dev.mysql.com/downloads/connector/j/ MySQL]. O driver também é conhecido como Connector/J e o seu arquivo .jar deve ser copiado para o diretório /etc/guacamole/libs |
Na sequência devemos importar para a base de dados MySQL/MariaDB os arquivos do diretório schema para criar os esquemas de dados: | Na sequência devemos importar para a base de dados MySQL/MariaDB os arquivos do diretório schema para criar os esquemas de dados: | ||
Linha 119: | Linha 119: | ||
==== Autenticação LDAP ==== | ==== Autenticação LDAP ==== | ||
− | Da mesma forma como foi feita | + | Da mesma forma como foi feita a cópia da extensão anteriormente para o MySQL/MariaDB, devemos realizar para o arquivo guacamole-auth-ldap-1.3.0.jar e copiá-lo para o diretório /etc/guacamole/extensions |
− | Depois inserimos no arquivo guacamole.properties a configuração para consulta ao Active Directory | + | Depois inserimos no arquivo guacamole.properties a configuração para consulta ao Active Directory: |
<pre> | <pre> | ||
Linha 135: | Linha 135: | ||
=== Guacamole através de um Proxy === | === Guacamole através de um Proxy === | ||
− | É altamente recomendável que o guacamole-server esteja, no caso de um servidor em produção, atrás de um proxy reverso, isolando assim operações privilegiadas, fornecendo flexibilidade e segurança utilizando | + | É altamente recomendável que o guacamole-server esteja, no caso de um servidor em produção, atrás de um ''proxy'' reverso, isolando assim operações privilegiadas, fornecendo flexibilidade e segurança utilizando certificados digitais e criptografia SSL. O uso do ''proxying'' no Guacamole pelo elemento conector AJP não irá funcionar, ele não é suportado e deverá ser revertido para porta padrão do Tomcat HTTP 8080. |
− | + | Com isso foi configurado no Apache Web Server a função de proxy reverso utilizando as diretivas ''ProxyPass'' e ''ProxyPassReverse''. Um exemplo de um arquivo /etc/httpd/conf.d/guacamole.conf a ser criado pode ser observado nas linhas abaixo: | |
<pre> | <pre> | ||
Linha 153: | Linha 153: | ||
ProxyPassReverse http://hostname:8080/guacamole/ | ProxyPassReverse http://hostname:8080/guacamole/ | ||
</Location> | </Location> | ||
− | |||
</VirtualHost> | </VirtualHost> | ||
</pre> | </pre> | ||
− | === Habilitando Certificados Digitais no Guacamole === | + | === Habilitando os Certificados Digitais no Guacamole === |
− | É recomendado o uso de certificados digitais em todos os componentes da arquitetura do Guacamole para garantirmos uma conexão segura no tráfego das informações e no acesso remoto. É uma configuração trabalhosa que envolve vários processos desde a criação das chaves até a importação dos certificados da autoridade certificadora. As seguintes etapas foram | + | É recomendado o uso de certificados digitais em todos os componentes da arquitetura do Guacamole para garantirmos uma conexão segura no tráfego das informações e no acesso remoto. É uma configuração trabalhosa que envolve vários processos desde a criação das chaves até a importação dos certificados da autoridade certificadora. As seguintes etapas foram executadas: |
==== Criptografia entre o Tomcat e o servidor Guacamole ==== | ==== Criptografia entre o Tomcat e o servidor Guacamole ==== | ||
Linha 205: | Linha 204: | ||
</pre> | </pre> | ||
− | Importar o certificado digital da autoridade | + | Importar o certificado digital da autoridade certificadora no armazenamento de chaves do Java: |
<pre> | <pre> | ||
Linha 211: | Linha 210: | ||
</pre> | </pre> | ||
− | Alterar o arquivo de serviços guacd.service do systemctl o caminho do certificado e da chave: | + | Alterar o arquivo de serviços guacd.service do systemctl e incluir o caminho do certificado e da chave: |
<pre> | <pre> | ||
Linha 217: | Linha 216: | ||
</pre> | </pre> | ||
− | Após a alteração do arquivo devemos executar o reload: | + | Após a alteração do arquivo devemos executar o reload no systemctl e reiniciar o ''daemon'' guacd: |
<pre> | <pre> | ||
# systemctl daemon-reload | # systemctl daemon-reload | ||
+ | # systemctl restart guacd | ||
</pre> | </pre> | ||
Devemos obter no arquivo /var/log/messages um registro semelhante a este: | Devemos obter no arquivo /var/log/messages um registro semelhante a este: | ||
<pre> | <pre> | ||
− | guacd[6393]: Guacamole proxy daemon (guacd) version 1. | + | guacd[6393]: Guacamole proxy daemon (guacd) version 1.3.0 started |
guacd[6393]: Using PEM keyfile /etc/pki/tls/certs/key.pem | guacd[6393]: Using PEM keyfile /etc/pki/tls/certs/key.pem | ||
guacd[6393]: Using certificate file /etc/pki/tls/certs/certificado.pem | guacd[6393]: Using certificate file /etc/pki/tls/certs/certificado.pem | ||
− | guacd[6393]: Listening on host 127.0.0.1 | + | guacd[6393]: Listening on host ::1, port 4822 |
+ | </pre> | ||
+ | |||
+ | O daemon guacd em algumas distribuições, caso na rede tenha o IPv6 habilitado, faz o bind na porta 4822 da conexão em ::1 (localhost em IPv6). Em situações que a rede tenha somente IPv4, o Tomcat tenta se conectar em (127.0.0.1). Devido a essa situação é necessário adicionar algumas linhas no arquivo de configuração /etc/guacamole/guacd.conf: | ||
+ | |||
+ | <pre> | ||
+ | [server] | ||
+ | bind_host=127.0.0.1 | ||
+ | bind_port=4822 | ||
</pre> | </pre> | ||
− | ==== Criptografia na consulta na base dos usuários do Active Directory | + | ==== Criptografia na consulta na base dos usuários do Active Directory utilizando LDAPS ==== |
− | Devemos primeiro exportar o certificado do Active Directory | + | Devemos primeiro exportar o certificado do Active Directory: |
<pre> | <pre> | ||
# openssl s_client -showcerts -connect hostname:636 </dev/null 2>/dev/null | openssl x509 -outform PEM > cert-ad.pem | # openssl s_client -showcerts -connect hostname:636 </dev/null 2>/dev/null | openssl x509 -outform PEM > cert-ad.pem | ||
</pre> | </pre> | ||
− | Depois importar na base de chaves do Java: | + | Depois importar na base de armazenamento de chaves do Java: |
<pre> | <pre> | ||
# keytool -importcert -alias "ldaps" -keystore /etc/pki/java/cacerts -file cert-ad.pem | # keytool -importcert -alias "ldaps" -keystore /etc/pki/java/cacerts -file cert-ad.pem | ||
</pre> | </pre> | ||
− | Após esses processos devemos | + | Após esses processos devemos, devemos incluir as seguintes linhas no arquivo de configuração guacamole.properties para comunicação segura (LDAPS) com o Active Directory: |
<pre> | <pre> | ||
Linha 251: | Linha 259: | ||
=== Interface de Administração do Guacamole === | === Interface de Administração do Guacamole === | ||
− | Após vencermos todas as etapas de configurações com sucesso vamos acessar a interface de administração digitando no navegador o nome do servidor configurado. Deverá aparecer uma tela solicitando o usuário e a senha. | + | Após vencermos todas as etapas de configurações com sucesso vamos acessar a interface de administração digitando no navegador o nome do servidor configurado. Deverá aparecer uma tela solicitando o usuário e a senha. Deve ser utilizado o usuário e a senha que foi definida na base de dados do MySQL/MariaDB ou no LDAP. Se não foram criado ainda esse usuário e senha, isso deve ser realizado antes de acessar o painel de administração. |
+ | |||
+ | Ao entrar com o usuário administrador escolha a opção ''Settings''. Devemos encontrar um menu de configurações como mostra a Figura 2: | ||
+ | |||
+ | [[Arquivo:Fig-setting.png|miniaturadaimagem|Figura 2 - Settings|centro|940x940px]] | ||
− | |||
* ''Active Sessions'': lista as conexões ativas no momento podendo encerrar a sessão do usuário caso seja necessário. | * ''Active Sessions'': lista as conexões ativas no momento podendo encerrar a sessão do usuário caso seja necessário. | ||
− | * ''History'': mostra um histórico de todos os usuários que realizaram as conexões remotas, os horários, duração e os desktops acessados. | + | * ''History'': mostra um histórico de todos os usuários que realizaram as conexões remotas, os horários, duração da conexão e os desktops acessados. |
* ''Users'': todos os usuários encontrados no LDAP ou MySQL/MariaDB. Aqui ao selecionar os usuários, você poderá configurar quais desktops serão atribuídos, junto com o perfil de acesso de cada um. | * ''Users'': todos os usuários encontrados no LDAP ou MySQL/MariaDB. Aqui ao selecionar os usuários, você poderá configurar quais desktops serão atribuídos, junto com o perfil de acesso de cada um. | ||
* ''Groups'': criação de grupos de desktops, para facilitar a administração dos acessos remotos | * ''Groups'': criação de grupos de desktops, para facilitar a administração dos acessos remotos | ||
− | * ''Connections'': nesta seção | + | * ''Connections'': nesta seção são adicionadas as máquinas remotas a serem acessadas, escolhendo o tipo de conexão, informando o IP e a forma de autenticação no caso de um RDP, conforme Figura 3. |
* ''Preferences'': altera as opções de teclado e mouse. Se o acesso vier de um dispositivo móvel, as opções aqui devem ser alteradas para que funcione em telas touch. | * ''Preferences'': altera as opções de teclado e mouse. Se o acesso vier de um dispositivo móvel, as opções aqui devem ser alteradas para que funcione em telas touch. | ||
+ | [[Arquivo:Fig3-parameters.png|miniaturadaimagem|Figura 3 - Parâmetros |420x420px]] | ||
+ | |||
=== Conclusão === | === Conclusão === | ||
− | Neste artigo | + | Neste artigo foram mostradas algumas configurações básicas do Guacamole com certificados digitais a serem implementadas em todas as camadas de acesso da aplicação, com um bom nível se segurança no trânsito das informações. Na versão atual existem outros tipos de autenticações, inclusive com dois fatores (2FA) que não foi coberto neste documento, mas que podem ser encontrados no Manual do Guacamole, como por exemplo: DUO, TOPT, CAS, OpenID, SAML e RADIUS. |
− | Como em qualquer sistema, devemos sempre estar atento | + | Como em qualquer sistema computacional, devemos sempre estar atento as vulnerabilidades divulgadas nos protocolos de RDP, SSH e suas bibliotecas, assim como no Tomcat, Java e Apache Web Server, instalando sempre as últimas versões estáveis. Ver o relatório [https://guacamole.apache.org/security/ Security Reports] |
− | + | Incentivamos a configuração do Guacamole em IPv6 em todos os componentes, desde o portal gateway web até o acesso remoto interno aos dispositivos. Com isso os usuários poderão experimentar um melhor acesso ao dispositivo final, sem atrasos e traduções de endereços realizados pelo NAT durante o trânsito dos pacotes, por ISPs que ainda não adotaram o IPv6. | |
− | Espero com esse artigo ter conseguido demonstrar uma configuração básica de uma solução viável dentre muitas que existem, para acesso remoto | + | Por fim, o projeto Apache Guacamole demonstrou ser uma alternativa viável de acesso remoto a desktops, sistemas e servidores, podendo ser acessado inclusive por tablets e smartphones, através de um navegador, sem a instalação de clientes ou plug-ins. Facilita e centraliza, através de um gateway, o gerenciamento das conexões remotas em vez de ter que configurar túneis SSH e liberações de portas RDP e VNC nos ''firewalls.'' Fornece, para a realização de auditoria, um relatório completo de conexões realizadas pelos usuários. |
+ | |||
+ | Espero assim com esse artigo ter conseguido demonstrar uma configuração básica de uma solução viável dentre muitas que existem, para o acesso remoto principalmente em desktops. Ainda incentivar e demostrar as vantagens em sempre adotar o IPv6 com padrão nas configurações de novos serviços a serem oferecidos aos usuários. | ||
+ | |||
+ | Qualquer dúvida, sugestões, críticas, estou a disposição. [https://www.linkedin.com/in/henri-alves-godoy/ Linkedin] | ||
Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Henri.godoy Henri A. Godoy] | Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Henri.godoy Henri A. Godoy] | ||
− | |||
=== Referência === | === Referência === |
Edição atual tal como às 11h13min de 13 de janeiro de 2023
Introdução
Com a pandemia do COVID-19, nossa rotina diária de trabalho em ir a empresa todos os dias sofreu uma brusca alteração e a necessidade de acesso aos recursos computacionais remotamente causou uma correria na busca de soluções de TI para suportar essa demanda. O Home Office que muito se ouvia falar foi finalmente instituído na maioria das empresas ao redor do mundo.
No cenário das Universidades não foi diferente. A necessidade de acesso a equipamentos de pesquisa em laboratórios, aos laboratórios de informática, sistemas internos e servidores exigiu de todos os profissionais de TI uma corrida por soluções que envolva um acesso de remoto de forma segura, fácil para o usuário e que demonstre um bom desempenho no acesso de um grande conjunto de dispositivos computacionais de maneira orquestrada.
Segundo o levantamento da empresa Kaspersky houve um aumento em 330% de ataques a sistemas de acesso remoto no Brasil. A adesão “forçada” pelo Home Office fez disparar os ciberataques direcionados ao “Remote Desktop Protocol (RDP)” e em menor quantidade também ao "VNC (Virtual Network Computing)". Devido a necessidade de transferir a maioria dos seus colaboradores para o trabalho a distância em seus lares, muitas empresas deixaram as medidas de segurança de lado, fazendo liberações indiscriminadas sem proteção de portas de acesso remoto no firewall corporativo, muitas vezes sem criptografia, sem uma política de senhas fortes, ou não habilitando a autenticação de dois fatores.
Este breve artigo tem como objetivo descrever uma configuração básica inicial de forma sugerir uma solução de um gateway de acesso remoto centralizado, utilizando o software livre e de código aberto chamado Apache Guacamole.
Projeto Apache Guacamole
O projeto Apache Guacamole é uma arquitetura completa que possibilita o acesso remoto a desktops utilizando apenas o navegador Web, sem a instalação de nenhum plug-in ou software cliente (clientless). Uma vez conectado ao servidor Guacamole ele age com um intermediário (proxy) até um computador específico localizado na rede local da empresa, utilizando os protocolos suportados como: RDP, VNC, SSH. Na Figura 1 podemos compreender toda a arquitetura e os seus componentes durante uma conexão fora do perímetro corporativo.
Todo o projeto é composto por um daemon guacamole-server, que fornece o proxy guacd e as bibliotecas relacionadas e o daemon guacamole-client, que fornece o cliente para ser atendido pelo contêiner do servlet do Tomcat. Portanto precisamos que o ambiente esteja preparado com o Tomcat (versão maior que 8.5) e o Java OpenJDK. O guacamole-client está disponível em formato binário, mas o guacamole-server deve ser construído a partir do código fonte. Ambas as partes serão descritas com detalhes a seguir.
Apache Guacamole Server
O guacamole-server contém em seu código fonte todos os componentes básicos do lado do servidor exigidos para a conexão com a área de trabalho remota. Mesmo assim algumas dependências são necessárias como: cairo, libjpeg, libpng e da biblioteca OSSP UUID. Elas devem estar presentes e instaladas de acordo com a distribuição Linux utilizada. No caso deste artigo, todo ambiente foi configurado utilizando a distribuição CentOS
Algumas dependências são absolutamente necessárias, enquanto outras são opcionais. A presença de dependências opcionais permite recursos adicionais como por exemplo:
- Suporte ao VNC: depende da biblioteca libvncclient
- Suporte ao RDP: depende do FreeRDP (utilizar a versão maior que 2.0, atualizada, para evitar problemas de segurança já conhecidos)
- Suporte ao SSH: depende de libssh2, OpenSSL e Pango
- Suporte ao Kubernetes: depende de libwebsockets, OpenSSL e Pango
A compilação do guacamole-server cria um executável chamado guacd que pode ser executado manualmente ou de forma automática como serviço. É desejável e recomendado sempre fazer o download do código fonte mais recente clonando o repositório git do guacamole pelo GitHub:
# git clone git://github.com/apache/guacamole-server.git
Quando o código fonte do guacamole-server for baixado e extraído você precisará construir o arquivo configure, que no caso do download pelo GitHub não vem incluso.
# cd guacamole-server/ # autoreconf -fi
Em seguida podemos agora executar o configure para instalar o script de inicialização do guacd no diretório /etc/init.d/ para que seja executado de forma automática a cada reboot.
# ./configure --with-init-dir=/etc/init.d # make # make install
Apache Guacamole Client
A parte do guacamole-client é compactada em um arquivo totalmente independente, chamado guacamole.war e o seu download pode ser feito diretamente pelo site do Apache Guacamole. Novamente sempre é recomendado a última versão estável. A sua instalação envolve uma cópia do arquivo para o diretório do contêiner do servlet CATALINA_HOME/webapps/. O diretório varia de acordo com a instalação em cada distribuição mas, normalmente o diretório padrão é /usr/share/tomcat/webapps.
# cp guacamole.war /usr/share/tomcat/webapps
Depois que o arquivo guacamole.war for copiado é necessário reiniciar o Tomcat para descompactar o arquivo .war na aplicação.
# systemctl restart tomcat
Verificar sempre possíveis mensagens de erros é uma boa prática e mesmo que o Guacamole esteja sendo executado com sucesso, ele está desconfigurado e devemos realizar algumas etapas adicionais no arquivo de configuração principal guacamole.properties.
Configurando o arquivo guacamole.properties
Para que o guacamole-server funcione você deve configurá-lo com um ou mais método de autenticação. O método padrão lê todos os usuários de um único arquivo chamado user-mapping.xml. Um exemplo de como configurar um usuário básico pode ser realizado da seguinte forma:
<user-mapping> <authorize username="username" password="hash-password" encoding="md5"> </authorize> </user-mapping>
Todos os arquivos de configurações se encontram no diretório padrão /etc/guacamole, onde são divididos em:
- guacamole.properties: principal arquivo de configuração.
- logback.xml: o sistema de registro chamado Logback para todas as mensagens.
- extensions: o local de todas as extensões do Guacamole que carregará automaticamente os arquivos .war
- lib: o diretório de bibliotecas requeridas por quaisquer extensões do Guacamole e drivers de banco de dados.
Porém, a configuração do Guacamole começa a ficar interessante e divertida quando você tem uma base de dados de usuários e quer integrar, como por exemplo, o LDAP. Existem muitos tutoriais na Internet com exemplos de configurações do arquivo guacamole.properties para integrar as bases de dados. Alguns que foram pesquisados são de versões antigas e parâmetros que não são mais necessários na versão atual. Depois de muitas tentativas e interagindo com a comunidade de usuários do Guacamole, foi possível uma configuração funcional de uma consulta em uma base de dados LDAP (Active Directory) em conjunto com a base de dados MySQL/MariaDB, no qual é necessário para o gerenciamento dos usuários, grupos e atribuições dos desktops a serem conectados.
Autenticação MySQL/MariaDB
Para habilitar o suporte a autenticação MySQL/MariaDB é necessário fazer o download das extensões no site Quacamole Releases
O arquivo guacamole-auth-jdbc-mysql-1.3.0.jar deve ser copiado para o diretório /etc/guacamole/extensions
O driver MySQL JDBC não vem junto com o pacote de extensão .jar e o seu download pode ser feito no site do MySQL. O driver também é conhecido como Connector/J e o seu arquivo .jar deve ser copiado para o diretório /etc/guacamole/libs
Na sequência devemos importar para a base de dados MySQL/MariaDB os arquivos do diretório schema para criar os esquemas de dados:
# ls schema/ 001-create-schema.sql 002-create-admin-user.sql upgrade # cat schema/*.sql | mysql -u root -p guacamole_db Enter password: password
Depois inserimos no arquivo guacamole.properties a configuração para conexão ao banco de dados:
mysql-hostname: hostname mysql-port: 3306 mysql-database: guacamole_db mysql-username: username mysql-password: password
A cada alteração no arquivo guacamole.properties o Tomcat deve ser reiniciado.
Autenticação LDAP
Da mesma forma como foi feita a cópia da extensão anteriormente para o MySQL/MariaDB, devemos realizar para o arquivo guacamole-auth-ldap-1.3.0.jar e copiá-lo para o diretório /etc/guacamole/extensions
Depois inserimos no arquivo guacamole.properties a configuração para consulta ao Active Directory:
ldap-hostname: hostname ldap-port: 389 ldap-search-bind-dn: cn=username,dc=example,dc=server,dc=br ldap-search-bind-password: password ldap-config-base-dn: dc=example,dc=server,dc=br ldap-user-base-dn: dc=example,dc=server,dc=br ldap-username-attribute: sAMAccountName
Guacamole através de um Proxy
É altamente recomendável que o guacamole-server esteja, no caso de um servidor em produção, atrás de um proxy reverso, isolando assim operações privilegiadas, fornecendo flexibilidade e segurança utilizando certificados digitais e criptografia SSL. O uso do proxying no Guacamole pelo elemento conector AJP não irá funcionar, ele não é suportado e deverá ser revertido para porta padrão do Tomcat HTTP 8080.
Com isso foi configurado no Apache Web Server a função de proxy reverso utilizando as diretivas ProxyPass e ProxyPassReverse. Um exemplo de um arquivo /etc/httpd/conf.d/guacamole.conf a ser criado pode ser observado nas linhas abaixo:
<VirtualHost *:80> ServerName hostname ErrorLog /var/log/httpd/error.log CustomLog /var/log/httpd/requests.log combined RewriteEngine on RewriteRule "^/$" "https://hostname/" [R] <Location /guacamole> Order allow,deny Allow from all ProxyPass http://hostname:8080/guacamole/ flushpackets=on ProxyPassReverse http://hostname:8080/guacamole/ </Location> </VirtualHost>
Habilitando os Certificados Digitais no Guacamole
É recomendado o uso de certificados digitais em todos os componentes da arquitetura do Guacamole para garantirmos uma conexão segura no tráfego das informações e no acesso remoto. É uma configuração trabalhosa que envolve vários processos desde a criação das chaves até a importação dos certificados da autoridade certificadora. As seguintes etapas foram executadas:
Criptografia entre o Tomcat e o servidor Guacamole
Importando o certificado raiz e intermediário da autoridade certificadora:
# keytool -import -trustcacerts -alias root -file ac-raiz.pem -keystore .keystore # keytool -import -trustcacerts -alias intermediate -file cadeia-intermediaria.pem -keystore .keystore
Importando o certificado recebido da autoridade certificadora:
# keytool -import -trustcacerts -alias tomcat -file certificado.pem -keystore .keystore
Listando os certificados importados:
# keytool -list -keystore .keystore
Configurando o Conector Tomcat editando o arquivo server.xml:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" keystoreFile=".keystore" keystorePass="password" clientAuth="false" sslProtocol="TLS" />
Habilitando o servidor Web e Proxy Reverso com os Certificados Digitais
Para configurar o servidor Web Apache temos que editar as linhas do arquivo /etc/httpd/conf.d/ssl.conf e incluir o caminho do certificado recebido pela autoridade certificadora e a chave privada do certificado:
SSLEngine On SSLCertificateFile /etc/pki/tls/certs/certificado.pem SSLCertificateKeyFile /etc/pki/tls/certs/key.pem
Criptografia entre a comunicação do guacd-client e o guacd-server
Devemos adicionar a linha abaixo no arquivo de configuração principal guacamole.properties
guacd-ssl: true
Importar o certificado digital da autoridade certificadora no armazenamento de chaves do Java:
# keytool -importcert -alias "guacd" -keystore /etc/pki/java/cacerts -file /etc/pki/tls/certs/certificado.pem
Alterar o arquivo de serviços guacd.service do systemctl e incluir o caminho do certificado e da chave:
ExecStart=/usr/local/sbin/guacd -f $OPTS -C /etc/pki/tls/certs/certificado.pem -K /etc/pki/tls/certs/key.pem
Após a alteração do arquivo devemos executar o reload no systemctl e reiniciar o daemon guacd:
# systemctl daemon-reload # systemctl restart guacd
Devemos obter no arquivo /var/log/messages um registro semelhante a este:
guacd[6393]: Guacamole proxy daemon (guacd) version 1.3.0 started guacd[6393]: Using PEM keyfile /etc/pki/tls/certs/key.pem guacd[6393]: Using certificate file /etc/pki/tls/certs/certificado.pem guacd[6393]: Listening on host ::1, port 4822
O daemon guacd em algumas distribuições, caso na rede tenha o IPv6 habilitado, faz o bind na porta 4822 da conexão em ::1 (localhost em IPv6). Em situações que a rede tenha somente IPv4, o Tomcat tenta se conectar em (127.0.0.1). Devido a essa situação é necessário adicionar algumas linhas no arquivo de configuração /etc/guacamole/guacd.conf:
[server] bind_host=127.0.0.1 bind_port=4822
Criptografia na consulta na base dos usuários do Active Directory utilizando LDAPS
Devemos primeiro exportar o certificado do Active Directory:
# openssl s_client -showcerts -connect hostname:636 </dev/null 2>/dev/null | openssl x509 -outform PEM > cert-ad.pem
Depois importar na base de armazenamento de chaves do Java:
# keytool -importcert -alias "ldaps" -keystore /etc/pki/java/cacerts -file cert-ad.pem
Após esses processos devemos, devemos incluir as seguintes linhas no arquivo de configuração guacamole.properties para comunicação segura (LDAPS) com o Active Directory:
ldap-port: 636 ldap-encryption-method: ssl
Interface de Administração do Guacamole
Após vencermos todas as etapas de configurações com sucesso vamos acessar a interface de administração digitando no navegador o nome do servidor configurado. Deverá aparecer uma tela solicitando o usuário e a senha. Deve ser utilizado o usuário e a senha que foi definida na base de dados do MySQL/MariaDB ou no LDAP. Se não foram criado ainda esse usuário e senha, isso deve ser realizado antes de acessar o painel de administração.
Ao entrar com o usuário administrador escolha a opção Settings. Devemos encontrar um menu de configurações como mostra a Figura 2:
- Active Sessions: lista as conexões ativas no momento podendo encerrar a sessão do usuário caso seja necessário.
- History: mostra um histórico de todos os usuários que realizaram as conexões remotas, os horários, duração da conexão e os desktops acessados.
- Users: todos os usuários encontrados no LDAP ou MySQL/MariaDB. Aqui ao selecionar os usuários, você poderá configurar quais desktops serão atribuídos, junto com o perfil de acesso de cada um.
- Groups: criação de grupos de desktops, para facilitar a administração dos acessos remotos
- Connections: nesta seção são adicionadas as máquinas remotas a serem acessadas, escolhendo o tipo de conexão, informando o IP e a forma de autenticação no caso de um RDP, conforme Figura 3.
- Preferences: altera as opções de teclado e mouse. Se o acesso vier de um dispositivo móvel, as opções aqui devem ser alteradas para que funcione em telas touch.
Conclusão
Neste artigo foram mostradas algumas configurações básicas do Guacamole com certificados digitais a serem implementadas em todas as camadas de acesso da aplicação, com um bom nível se segurança no trânsito das informações. Na versão atual existem outros tipos de autenticações, inclusive com dois fatores (2FA) que não foi coberto neste documento, mas que podem ser encontrados no Manual do Guacamole, como por exemplo: DUO, TOPT, CAS, OpenID, SAML e RADIUS.
Como em qualquer sistema computacional, devemos sempre estar atento as vulnerabilidades divulgadas nos protocolos de RDP, SSH e suas bibliotecas, assim como no Tomcat, Java e Apache Web Server, instalando sempre as últimas versões estáveis. Ver o relatório Security Reports
Incentivamos a configuração do Guacamole em IPv6 em todos os componentes, desde o portal gateway web até o acesso remoto interno aos dispositivos. Com isso os usuários poderão experimentar um melhor acesso ao dispositivo final, sem atrasos e traduções de endereços realizados pelo NAT durante o trânsito dos pacotes, por ISPs que ainda não adotaram o IPv6.
Por fim, o projeto Apache Guacamole demonstrou ser uma alternativa viável de acesso remoto a desktops, sistemas e servidores, podendo ser acessado inclusive por tablets e smartphones, através de um navegador, sem a instalação de clientes ou plug-ins. Facilita e centraliza, através de um gateway, o gerenciamento das conexões remotas em vez de ter que configurar túneis SSH e liberações de portas RDP e VNC nos firewalls. Fornece, para a realização de auditoria, um relatório completo de conexões realizadas pelos usuários.
Espero assim com esse artigo ter conseguido demonstrar uma configuração básica de uma solução viável dentre muitas que existem, para o acesso remoto principalmente em desktops. Ainda incentivar e demostrar as vantagens em sempre adotar o IPv6 com padrão nas configurações de novos serviços a serem oferecidos aos usuários.
Qualquer dúvida, sugestões, críticas, estou a disposição. Linkedin
Autor: Henri A. Godoy