Admin Linux - Gerenciamento Remoto
Ao falar sobre gerenciamento remoto no CentOS como um administrador, vamos explorar dois métodos -
- Gerenciamento de console
- Gerenciamento de GUI
Gerenciamento de console remoto
Gerenciamento de console remoto significa executar tarefas de administração a partir da linha de comando por meio de um serviço como o ssh. Para usar o CentOS Linux de forma eficaz, como administrador, você precisará ser proficiente com a linha de comando. O Linux em sua essência foi projetado para ser usado no console. Mesmo hoje, alguns administradores de sistema preferem o poder do comando e economizam dinheiro no hardware executando caixas Linux básicas, sem terminal físico e sem GUI instalado.
Gerenciamento Remoto de GUI
O gerenciamento remoto de GUI geralmente é realizado de duas maneiras: uma sessão X remota ou um protocolo de camada de aplicativo GUI como o VNC. Cada um tem seus pontos fortes e suas desvantagens. No entanto, na maior parte, o VNC é a melhor escolha para administração. Ele permite o controle gráfico de outros sistemas operacionais, como Windows ou OS X, que não oferecem suporte nativo ao protocolo X Windows.
O uso de X Sessions remotas é nativo tanto para X-Window's Window-Managers quanto para DesktopManagers rodando no X. No entanto, toda a arquitetura X Session é usada principalmente com Linux. Nem todo administrador de sistema terá um laptop Linux disponível para estabelecer uma sessão X remota. Portanto, é mais comum usar uma versão adaptada do servidor VNC.
As maiores desvantagens do VNC são: VNC não oferece suporte nativo a um ambiente multiusuário, como X-Sessions remotas. Conseqüentemente, para o acesso da GUI aos usuários finais, XSessions remotos seria a melhor escolha. No entanto, estamos principalmente preocupados em administrar um servidor CentOS remotamente.
Discutiremos a configuração do VNC para vários administradores em comparação com algumas centenas de usuários finais com X-Sessions remotas.
Estabelecendo a base para segurança com SSH para acesso remoto ao console
ssh ou Secure Shellagora é o padrão para administrar remotamente qualquer servidor Linux. O SSH, ao contrário do telnet, usa TLS para autenticidade e criptografia ponta a ponta das comunicações. Quando configurado corretamente, um administrador pode ter certeza de que tanto sua senha quanto o servidor são confiáveis remotamente.
Antes de configurar o SSH, vamos falar um pouco sobre a segurança básica e o acesso menos comum. Quando o SSH está sendo executado em sua porta padrão de 22; mais cedo ou mais tarde, você terá ataques de dicionário de força bruta contra nomes de usuário e senhas comuns. Isso só vem com o território. Não importa quantos hosts você adicione aos seus arquivos de negação, eles simplesmente virão de diferentes endereços IP diariamente.
Com algumas regras comuns, você pode simplesmente tomar algumas medidas proativas e deixar os bandidos perderem seu tempo. A seguir estão algumas regras de segurança a serem seguidas usando SSH para administração remota em um servidor de produção -
Nunca use um nome de usuário ou senha comum. Os nomes de usuário no sistema não devem ser o padrão do sistema ou estar associados ao endereço de e-mail da empresa como:[email protected]
O acesso root ou de administração não deve ser permitido via SSH. Use um nome de usuário exclusivo e su para fazer o root ou uma conta de administração, uma vez autenticado por SSH.
A política de senha é obrigatória: Senhas de usuário SSH complexas como: "This & IS & a & GUD & P @ ssW0rd & 24 & me". Altere as senhas a cada poucos meses para eliminar a suscetibilidade a ataques incrementais de força bruta.
Desative contas abandonadas ou que não sejam utilizadas por longos períodos. Se um gerente de contratação tiver um correio de voz informando que ele não dará entrevistas por um mês; isso pode levar a indivíduos com experiência em tecnologia com muito tempo disponível, por exemplo.
Observe seus registros diariamente. Como administrador do sistema, dedique pelo menos 30-40 minutos todas as manhãs para revisar o sistema e os registros de segurança. Se solicitado, diga a todos que você não tem tempo para não ser proativo. Essa prática ajudará a isolar os sinais de alerta antes que um problema se apresente aos usuários finais e aos lucros da empresa.
Note On Linux Security- Qualquer pessoa interessada na administração do Linux deve buscar ativamente as notícias e tecnologias atuais sobre segurança cibernética. Embora ouçamos principalmente sobre outros sistemas operacionais sendo comprometidos, uma caixa Linux insegura é um tesouro procurado pelos cibercriminosos. Com o poder do Linux em uma conexão de alta velocidade à Internet, um cibercriminoso habilidoso pode usar o Linux para alavancar ataques em outros sistemas operacionais.
Instalar e configurar SSH para acesso remoto
Step 1 - Instale o servidor SSH e todos os pacotes dependentes.
[root@localhost]# yum -y install openssh-server
'Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: repos.centos.net
* extras: repos.dfw.centos.com
* updates: centos.centos.com
Resolving Dependencies
--> Running transaction check
---> Package openssh-server.x86_64 0:6.6.1p1-33.el7_3 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
Step 2 - Faça um uso regular e seguro para adicionar acesso ao shell.
[root@localhost ~]# useradd choozer
[root@localhost ~]# usermod -c "Remote Access" -d /home/choozer -g users -G
wheel -a choozer
Note- Adicionamos o novo usuário ao grupo wheel permitindo a capacidade de su no root assim que o acesso SSH for autenticado. Também usamos um nome de usuário que não pode ser encontrado nas listas de palavras comuns. Dessa forma, nossa conta não será bloqueada quando o SSH for atacado.
O arquivo que contém as definições de configuração do servidor sshd é / etc / ssh / sshd_config .
As partes que queremos editar inicialmente são -
LoginGraceTime 60m
PermitRootLogin no
Step 3- Recarregue o daemon SSH sshd .
[root@localhost]# systemctl reload sshd
É bom definir o período de tolerância de logoff para 60 minutos. Algumas tarefas de administração complexas podem exceder o padrão de 2 minutos. Não há realmente nada mais frustrante do que ter o tempo limite da sessão SSH ao configurar ou pesquisar alterações.
Step 4 - Vamos tentar fazer o login usando as credenciais de root.
bash-3.2# ssh centos.vmnet.local
[email protected]'s password:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Step 5- Não podemos mais entrar remotamente via ssh com credenciais de root . Então, vamos acessar nossa conta de usuário sem privilégios e usar su na conta root .
bash-3.2# ssh [email protected]
[email protected]'s password:
[choozer@localhost ~]$ su root
Password:
[root@localhost choozer]#
Step 6- Finalmente, vamos garantir que o serviço SSHD carregue na inicialização e que o firewalld permita conexões SSH externas.
[root@localhost]# systemctl enable sshd
[root@localhost]# firewall-cmd --permanent --add-service=ssh
success
[root@localhost]# firewall-cmd --reload
success
[root@localhost]#
O SSH agora está configurado e pronto para administração remota. Dependendo da fronteira de sua empresa, o dispositivo de fronteira de filtragem de pacotes pode precisar ser configurado para permitir a administração remota SSH fora da LAN corporativa.
Configurar VNC para administração remota CentOS
Existem algumas maneiras de habilitar a administração remota do CentOS via VNC no CentOS 6 - 7. A maneira mais fácil, mas mais limitante, é simplesmente usar um pacote chamado vino .Vinoé um aplicativo Virtual Network Desktop Connection para Linux desenvolvido em torno da plataforma Gnome Desktop. Portanto, presume-se que a instalação foi concluída com o Gnome Desktop. Se o Gnome Desktop não foi instalado, faça-o antes de continuar. O Vino será instalado com uma instalação GUI do Gnome por padrão.
Para configurar o compartilhamento de tela com Vino no Gnome, queremos ir para as Preferências do Sistema CentOS para compartilhamento de tela.
Applications->System Tools->Settings->Sharing
Notas para configurar o VNC Desktop Sharing -
Disable New Connections must ask for access- Esta opção exigirá acesso físico para aprovar todas as conexões. Esta opção impedirá a administração remota, a menos que alguém esteja na área de trabalho física.
Enable Require a password- Isso é separado da senha do usuário. Ele controlará o acesso à área de trabalho virtual e ainda exigirá a senha do usuário para acessar uma área de trabalho bloqueada (isso é bom para a segurança).
Forward UP&P Ports: If available leave disabled- O encaminhamento de portas UP&P enviará solicitações Universal Plug and Play para um dispositivo da camada 3 para permitir conexões VNC ao host automaticamente. Nós não queremos isso.
Certifique-se de que o vino esteja escutando na porta VNC 5900.
[root@localhost]# netstat -antup | grep vino
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 4873/vino-server
tcp6 0 0 :::5900 :::* LISTEN 4873/vino-server
[root@localhost]#
Vamos agora configurar nosso Firewall para permitir conexões VNC de entrada.
[root@localhost]# firewall-cmd --permanent --add-port=5900/tcp
success
[root@localhost]# firewall-cmd --reload
success
[root@localhost rdc]#
Finalmente, como você pode ver, somos capazes de conectar nosso CentOS Box e administrá-lo com um cliente VNC no Windows ou OS X.
É tão importante obedecer às mesmas regras para VNC quanto estabelecemos para SSH. Assim como o SSH, o VNC é continuamente verificado em intervalos de IP e testado para senhas fracas. Também vale a pena observar que deixar o login CentOS padrão habilitado com um tempo limite do console ajuda com a segurança VNC remota. Como um invasor precisará do VNC e da senha do usuário, certifique-se de que a senha de compartilhamento de tela seja diferente e tão difícil de adivinhar quanto a senha do usuário.
Após inserir a senha de compartilhamento de tela do VNC, também devemos inserir a senha de usuário para acessar uma área de trabalho bloqueada.
Security Note- Por padrão, o VNC não é um protocolo criptografado. Portanto, a conexão VNC deve ser encapsulada por meio de SSH para criptografia.
Configurar túnel SSH por meio de VNC
A configuração de um túnel SSH fornecerá uma camada de criptografia SSH para o túnel da conexão VNC. Outro ótimo recurso é que ele usa compactação SSH para adicionar outra camada de compactação às atualizações de tela da GUI do VNC. Mais seguro e rápido é sempre uma boa coisa ao lidar com a administração de servidores CentOS!
Portanto, a partir do seu cliente que iniciará a conexão VNC, vamos configurar um túnel SSH remoto. Nesta demonstração, estamos usando o OS X. Primeiro, precisamos fazer o sudo -s para fazer o root .
bash-3.2# sudo -s
password:
Digite a senha do usuário e agora devemos ter o shell de root com um prompt # -
bash-3.2#
Agora, vamos criar nosso túnel SSH .
ssh -f [email protected] -L 2200:192.168.1.143:5900 -N
Vamos quebrar este comando -
ssh - Executa o utilitário ssh local
-f - ssh deve ser executado em segundo plano após a execução completa da tarefa
[email protected] - Usuário ssh remoto no servidor CentOS que hospeda serviços VNC
-L 2200:192.168.1.143:5900 - Crie nosso túnel [Porta local]: [host remoto]: [porta remota do serviço VNC]
-N diz ao ssh que não queremos executar um comando no sistema remoto
bash-3.2# ssh -f [email protected] -L 2200:192.168.1.143:5900 -N
[email protected]'s password:
Após inserir com sucesso a senha do usuário ssh remoto, nosso túnel ssh é criado. Agora para a parte legal! Para conectar, apontamos nosso cliente VNC para o host local na porta do nosso túnel, neste caso a porta 2200. A seguir está a configuração no cliente VNC do laptop Mac -
E, finalmente, nossa conexão remota VNC Desktop!
O legal do tunelamento SSH é que ele pode ser usado para quase todos os protocolos. Os túneis SSH são comumente usados para contornar a filtragem de portas de entrada e saída por um ISP, bem como enganar IDS / IPS da camada de aplicativo enquanto evita o monitoramento de outra camada de sessão.
Seu ISP pode filtrar a porta 5900 para contas não comerciais, mas permitir SSH na porta 22 (ou alguém poderia executar SSH em qualquer porta se a porta 22 for filtrada).
IPS e IDS de nível de aplicativo analisam a carga útil. Por exemplo, um estouro de buffer comum ou injeção de SQL. A criptografia SSH de ponta a ponta criptografará os dados da camada de aplicativo.
O encapsulamento SSH é uma ótima ferramenta na caixa de ferramentas de um administrador Linux para fazer as coisas. No entanto, como um administrador, queremos explorar o bloqueio da disponibilidade de usuários com menos privilégios com acesso ao túnel SSH.
Administration Security Note- Restringir o encapsulamento SSH é algo que requer reflexão por parte de um administrador. Avaliar porque os usuários precisam do encapsulamento SSH em primeiro lugar; quais usuários precisam de tunelamento; junto com a probabilidade de risco prático e o impacto do pior caso.
Este é um tópico avançado que vai além do domínio de uma cartilha de nível intermediário. A pesquisa neste tópico é recomendada para aqueles que desejam alcançar os escalões superiores da administração do CentOS Linux.
Usar Túnel SSH para X-Windows Remoto
O design do X-Windows no Linux é muito bom em comparação com o do Windows. Se quisermos controlar uma máquina Linux remota a partir de outra máquina Linux, podemos aproveitar os mecanismos integrados ao X.
O X-Windows (freqüentemente chamado apenas de "X"), fornece o mecanismo para exibir janelas de aplicativos originadas de uma caixa do Linux para a parte de exibição do X em outra caixa do Linux. Então, através do SSH podemos solicitar que um aplicativo X-Windows seja encaminhado para o display de outra máquina Linux em todo o mundo!
Para executar um aplicativo X remotamente por meio de um túnel ssh, só precisamos executar um único comando -
[root@localhost]# ssh -X [email protected]
The syntax is - ssh -X [usuário] @ [host], e o host deve estar executando ssh com um usuário válido.
A seguir está uma captura de tela do GIMP em execução em uma estação de trabalho Ubuntu por meio de um túnel ssh remoto do XWindows.
É muito simples executar aplicativos remotamente de outro servidor ou estação de trabalho Linux. Também é possível iniciar uma X-Session inteira e ter todo o ambiente de área de trabalho remotamente por meio de alguns métodos.
XDMCP
Pacotes de software sem cabeça, como NX
Configurando telas e áreas de trabalho alternativas no X e gerenciadores de área de trabalho como Gnome ou KDE
Este método é mais comumente usado para servidores headless sem tela física e realmente excede o escopo de um primer de nível intermediário. No entanto, é bom saber das opções disponíveis.