As instâncias do EC2 vêm com uma única interface - eth0. Essa interface é mapeada para o endereço IP privado da sua instância e não pode ser desanexada da instância. (Claro, você pode derrubar a interface, mas isso é uma função do sistema operacional, não da AWS).
O único caso em que você pode anexar / desconectar interfaces de rede é se sua instância está sendo executada em uma Virtual Private Cloud (VPC). Tais instâncias suportam várias interfaces.
Como a instância tem apenas uma única interface de rede, o fato de você conseguir se conectar a ela - mesmo que seja apenas pelo console da AWS - sugere que a interface ainda existe e está operacional (a entrada 'Network Interface') na entrada do console da AWS é preenchida apenas para instâncias de VPC). Vale a pena notar que o endereço IP público de uma instância será alterado quando uma instância for interrompida e iniciada (embora uma reinicialização não deva afetar isso). IPs elásticos podem ser usados para fornecer um endereço IP 'estático'. O endereço IP público (seja dinâmico ou 'elástico') não está diretamente associado à interface, e sim à rede EC2, o endereço público da NAT ao privado.
Como você ainda tem acesso SSH à instância, pode confirmar que a interface está operacional, procurando por uma entrada eth0 na saída de ifconfig . Você também pode usar o comando ec2-describe-instances para obter os endereços IP privados e públicos de sua (s) instância (s).
As instâncias do EC2 geralmente têm duas causas de pacotes bloqueados - o firewall do sistema operacional (iptables / netfilter, neste caso) ou o grupo de segurança do EC2. Na medida do possível, é sempre preferível bloquear o tráfego com o seu grupo de segurança, pois impede que os dados atinjam a instância. Grupos de segurança, no entanto, são sem estado, e a maioria dos pacotes não está configurada para modificá-los dinamicamente, então você provavelmente usará o iptables também.
Por padrão, o grupo de segurança do EC2 descarta todos os pacotes ICMP (necessários para o ping) - portanto, a menos que você o habilite especificamente, o ping não funcionará. Para ativar o ping no console da AWS (para o seu grupo de segurança):
- Crie uma 'Regra ICMP personalizada' para o seu grupo de segurança
- Tipo: Solicitação de eco e tipo: Resposta de eco (ambos são obrigatórios)
- Fonte: 0.0.0.0/0
Você pode ver suas regras de iptables atualmente configuradas com: iptables -nvL e pode ver as configurações do grupo de segurança com ec2-describe-group SECURITY_GROUP
Ataques de força bruta e ter seu servidor varrido são, infelizmente, parte do que implica ter um servidor voltado para o público hoje. Os ataques ocorrem normalmente não é algo com que se preocupar, mas sim como o seu servidor é configurado para garantir que esses ataques não resultem em violações. Normalmente, o bloqueio manual de um único endereço IP não é o caminho mais eficaz, uma vez que você normalmente encontrará uma grande variedade de IPs como os originadores de ataques contra o seu servidor. Eu recomendaria olhar para fail2ban se você quiser uma solução baseada em logins com falha (ele varre seus logs e dinamicamente adiciona / remove as regras de firewall necessárias) ou um conjunto de regras do iptables com base no módulo recente.
Além disso, geralmente é uma boa prática, ao trabalhar com o iptables, configurar uma tarefa cron que libera as regras do iptables ( iptables -F ) após alguns minutos, para que você não se desconecte acidentalmente do servidor.
Nesse caso, uma atualização para o nginx resultou em uma configuração inválida, devido à adição de /etc/nginx/conf.d/default.conf . Crie um arquivo vazio com o mesmo nome (em vez de excluir o arquivo) para evitar que futuras atualizações causem o mesmo problema. Embora provavelmente não seja algo que a maioria das pessoas faz após uma atualização, você sempre pode testar sua configuração do nginx com service nginx configtest , o que permitirá que você saiba se há algum problema antes de finalizar o processo nginx em execução.
Se você realmente se encontrar com uma interface de rede desabilitada (por exemplo, por causa de ifdown eth0 ), você não poderá acessar o SSH na instância (ou contatá-la de qualquer maneira). A solução para esse cenário é parar a instância, desconectar o volume raiz do EBS, anexá-lo como um volume adicional a uma nova instância do EC2, corrigir o problema, reconectar o volume do EBS à sua instância original e iniciá-lo novamente. É uma das vantagens definitivas dos volumes do EBS.