Como o Hacker pode acessar o conteúdo do VPS CentOS 6? [fechadas]

Question

Só quero entender. Por favor, corrija erros e escreva conselhos

O hacker pode acessar o VPS:

1. Através do (usando) terminal do console, por exemplo, usando o PuTTY.

Para acessar, o hacker precisa saber o número da porta, nome de usuário e senha.

O hacker de número de porta pode saber escanear portas abertas e tentar fazer o login. A única maneira de fazer login, como eu entendo, precisa saber o nome de usuário e a senha.

Para bloquear (dificultar) a varredura de portas, é necessário usar o iptables para configurar /etc/sysconfig/iptables . Eu segui esse link tutorial e tenho

*nat
:PREROUTING ACCEPT [87:4524]
:POSTROUTING ACCEPT [77:4713]
:OUTPUT ACCEPT [77:4713]
COMMIT

*mangle
:PREROUTING ACCEPT [2358:200388]
:INPUT ACCEPT [2358:200388]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2638:477779]
:POSTROUTING ACCEPT [2638:477779]
COMMIT

*filter
:INPUT DROP [1:40]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [339:56132]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -s 11.111.11.111/32 -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -s 11.111.11.111/32 -p tcp -m tcp --dport 21 -j ACCEPT
COMMIT

Com relação às portas que precisam ser abertas.

Se não usa o ssl, então deve deixar a porta aberta 80 para o site.

Em seguida, para ssh (padrão 22) e para ftp (padrão 21). E defina o endereço IP, a partir do qual pode se conectar. Então, se hacker usa outro endereço IP, ele não pode acessar mesmo sabendo nome de usuário e senha?

Quanto aos e-mails, não tenho certeza.

Se eu enviar um e-mail usando o Gmail (Enviar e-mail como: (Usar o Gmail para enviar de seus outros endereços de e-mail)), a porta 25 não será necessária.

Para e-mails recebidos no dynadot.com, uso o Email Forwarding. Isso significa que os e-mails “não chegam ao VPS” (antes de chegar ao VPS, os e-mails são encaminhados, por exemplo, para o Gmail)? Se os e-mails não chegarem ao VPS, a porta 110 também não será necessária.

Se usar somente ssl, abra a porta 443 e feche a porta 80.

Não entenda em relação à porta 3306

No PuTTY com /bin/netstat -lnp consulte

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      992/mysqld

Como entender, é para o mysql. Mas não se lembra que eu abri essa porta (pode ser quando instalado mysql, a porta é aberta automaticamente?). O Mysql é instalado no mesmo servidor, onde todos os outros conteúdos. Precisa entender sobre a porta 3306

2. O hacker também pode acessar o terminal do console através do Painel de controle do provedor de hospedagem VPS (acesso de emergência do console serial).

Como entender, usar apenas o terminal do console (PuTTY, etc.) pode fazer alterações "globais" (alterações que não podem ser modificadas com o ftp).

3. Hacker pode acessar meu VPS explorando algum buraco no meu código PHP e upload, por exemplo, Trojan.

Infelizmente, a situação enfrentou que o VPS foi hackeado. Como entendi foi porque eu usei o ZPanel. No VPS (\ etc \ zpanel \ panel \ bin)) encontrou um arquivo php, que foi identificado como Trojan por alguns scanners de vírus (em virustotal.com).

Experimentou o arquivo no computador local (wamp).

E parece que o hacker pode ver todo o conteúdo do VPS, renomear, apagar, fazer upload, etc. Da minha opinião, se no PuTTY usar o comando como chattr +i /etc/php.ini , então o hacker não poderia modificar o php.ini.

Existe alguma outra maneira de entrar no VPS?

    

Answer 1

O que você descreveu é uma vulnerabilidade do ZPanel se o arquivo foi colocado dentro de seu diretório e é acessível através do servidor web - eu vi isso acontecer um milhão de vezes em instalações Joomla / Wordpress.

Quanto à captura de tela fornecida - isso parece um shell PHP que poderá listar o sistema de arquivos porque o Apache pode acessar o sistema de arquivos. Quais arquivos / diretórios o script pode acessar / ler estão sujeitos às permissões definidas para esses arquivos.

Agora, responda suas perguntas:

1. Eu sugeriria usar o CSF para proteger seu servidor, que oferece proteção contra ataques de porta e examina seu log SSH para verificar se há ataques de força bruta ativando e bloqueando o endereço IP do invasor. Quanto a deixar portas abertas - pergunte-se o que o servidor fará e depois abra as portas necessárias:
   • 21 para FTP
   • 22 para SSH
   • 25 para servidor SMTP
   • 80 para HTTP
   • 443 para HTTPS se você estiver usando este
   • 110/995 para POP3 / POP3 via SSL - se você quiser usar um servidor de e-mail no seu VPS
   • 143/993 para IMAP4 / IMAP4 via SSL - o mesmo que para conexão POP3

Você pode fechar a porta 3306-MySQL, se você precisar acessar o servidor MySQL de um local remoto, poderá sempre adicionar uma regra iptables que permita que apenas o endereço IP remoto acesse a porta 3306.

Além disso, você pode usar chaves SSH para login root e desativar login de senha para o usuário root (PermitRootLogin sem senha), portanto, somente usuários com a chave SSH adicionada em ~ / .ssh / authorized_keys podem acessar a conta root. Outra maneira é desativar completamente o acesso root e usar outra conta para que você possa entrar na conta root (su - root).

Mas sua segurança é tão strong quanto seu elo mais fraco - você pode ter tudo bloqueado, mas se o aplicativo da Web estiver vulnerável - eles encontrarão uma maneira de entrar nele.

Se você for o único usando o servidor, poderá ver com o ZPanel adicionar um Auth HTTP antes de acessar o painel ou se estiver atrás de um servidor HTTP definido por VPN que atende o Zpanel para permitir somente acesso ao endereço IP da VPN.

Editar: Adicionar chattr +i /etc/php.ini desabilitaria quaisquer modificações no arquivo php.ini, já que definiu um atributo imutável, e não você (root) ou qualquer outro seria capaz de modificar o arquivo.

Quanto à proteção do php.ini, você pode considerar modificar as seguintes opções, se este for um servidor de produção:

• display_errors - desativado
• expose_php - desativado

Além disso, você pode desativar o número de funções desnecessárias do PHP que tornariam os scripts de shell PHP inutilizáveis:

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo Se o seu script não estiver funcionando corretamente depois que essas funções estiverem desativadas, verifique qual função seria necessária, remova da lista e reinicie o servidor HTTP.

    

Answer 2

Bem, claro! Tudo depende da superfície de ataque.

Qualquer coisa da parte inferior da pilha para cima é um alvo em potencial. Sem saber mais sobre um determinado VPS, sabemos que eles devem ter no mínimo:

• Vulnerabilidades da camada física (tocando em um fio, roubando um servidor físico)
• Vulnerabilidades da camada 2 (farejamento de tráfego de outra VLAN, explorações do ARP)
• Vulnerabilidades de rede (negação de serviço)
Vulnerabilidades de
• Sessão / Transporte / etc (camada de quebra automática) (a manipulação do cliente em certificados de pensamento é válida, outros problemas de SSL, seqüestro etc.)
• Vulnerabilidades da camada de apresentação / aplicativo (sua jornada começa aqui)

Em um ambiente virtualizado, o tipo de pilha é iniciado para que a camada de aplicativo no servidor físico hospede a camada física no ambiente virtual. Por exemplo, digamos que você esteja hospedando um VPS em um único servidor físico com algum hipervisor. Qualquer problema de armazenamento, rede ou servidor pode afetar as máquinas virtuais que residem nesse servidor.

Por outro lado, mesmo que tudo esteja bem no mundo físico, o ambiente virtual hospeda hardware virtualizado, para que você tenha que começar tudo de novo.

No entanto, os dois ambientes não precisam ser considerados totalmente separadamente. Embora o ambiente virtual esteja no topo do ambiente físico, ele ainda pode potencialmente atingir redes físicas. É aí que a sobreposição entre as ameaças virtuais e físicas começa.

Por exemplo, seu ISP pode ter um roteador de borda física que inspecione e filtre o tráfego. Pode verificar as querystrings de URLs não criptografados para ver se algo está errado. Se o fitler foi bom o suficiente, você pode supor que você não precisa se preocupar com tráfego fora (graças a ponte e NAT). Ainda assim, você pode executar sua própria verificação nos querystrings para ter uma dupla certeza. Neste caso, o tráfego foi:

1. Do cliente ao filtro de borda ISP (físico)
2. Ou: do filtro de borda do ISP para o cliente por meio de ponte física para virtual OU do filtro de borda do ISP para o gateway do cliente para o cliente
3. Do filtro do cliente para o aplicativo cliente

Eu entendo que é uma maneira realmente indireta de responder a sua pergunta, mas eu estou tentando dizer é que você deve pensar em sua superfície de ataque - especialmente o fruto mais fraco - ao invés de pensar em uma lista de verificação. Se você permitir uploads de arquivos, precisará ter uma maneira confiável de filtrar arquivos inválidos. Se você permitir a autenticação HTTP básica, será necessário evitar ataques de espionagem e de força bruta. Se você permitir o SSH, talvez queira auditar cuidadosamente as tentativas de login.

Portanto, em vez de pensar categoricamente em segurança, pense nisso em termos da superfície de ataque criada para que seus serviços específicos funcionem.