Entendo que você pode implementar um firewall para permitir acesso a um servidor apenas a partir de endereços IP específicos, mas as pessoas não podem falsificar o endereço IP de origem em um pacote TCP? Como isso realmente impede que pessoas sem escrúpulos acessem seu servidor?
Responder1
O que o cara disse é a resposta que você procura.
Acho que o que você está pensando é o seguinte:
SERVER.......................CLIENT
............[FIREWALL].........|
..|............................|
..|_>___[CHECK FOR AUTHORITY]_<_|
Este diagrama pressupõe que tanto o servidor quanto o cliente possuem firewalls (geralmente possuem).
Se a Autoridade falhar, a chamada para o Servidor/Cliente será ignorada.
Então se o ip do servidor for xxx.xxx.xxx.1 e o cliente for xxx.xxx.xxx.2 e o cliente tentar acessar o servidor enviando um comando sem autorização.. O log do seu servidor ficaria assim xxx.xxx .xxx.2 [Falha na autorização - IGNORAR]
Se xxx.xxx.xxx.2 ocultasse seu ip como xxx.xxx.xxx.3, que está autorizado a acessar o servidor, isso aconteceria. xxx.xxx.xxx.3 -> Enviar pacote de comando para xxx.xxx.xxx .1 xxx.xxx.xxx.1 -> Responder ao comando e enviar pacote para xxx.xxx.xxx.3
Portanto, xxx.xxx.xxx.1 nunca obteria o comando recuperado.
Agora, o que você provavelmente está pensandoCOMO ISSO É SEGURO?
Bem, a maioria dos servidores realmente funciona assim.
SERVER..............................CLIENT
..|______________[CONNECT]___________<_|
............|
...[TEST AUTHORIZATION]
...........|
......[PASSED]
..........|
...........[SEND CONNECTED RESPONSE]...|
Portanto, se o cliente estiver autorizado e fizer uma chamada para o servidor, o servidor responderá com uma resposta conectada para enviar de volta ao cliente. Se o cliente obtiver essa resposta, o servidor saberá que este é o cliente correto.
Responder2
Certamente alguém pode falsificar seu endereço IP para ENVIAR os pacotes TCP/IP, mas ele nunca receberá qualquer RESPOSTA porque irá para o endereço IP falso que ele usou! Portanto, esta forma é inútil para quem deseja estabelecer uma comunicação bidirecional!
Responder3
Foi observado que falsificar o remetente não é suficiente; você também desejará obter a resposta de volta para fazer qualquer coisa útil. Então você precisaria fazer um homem completo no meio.
No entanto, os firewalls geralmente não "permitem" muita coisa simplesmente com base no IP de origem.
Firewalls são usados principalmente parabloqueando, mas não para autorização.
Ou seja, um IP não confiável nem saberá que existe uma VPN, nem será capaz de se conectar ao serviço VPN. Ou ataque-o facilmente, aliás. Mas o principal recurso de segurança é a própria VPN.
Como a filtragem baseada em IP é barata, é um ótimoprimeira linha de defesa. Rejeitar qualquer pacote no firewall significa que os serviços por trás terão que lidar com muito menos “ataques” (e outros ruídos). Executar um DDoS contra um firewall é mais difícil do que executar um DDoS contra um serviço real, porque você precisa preencher a conexão com a Internet, não a CPU do servidor que gerencia as solicitações.
Responder4
Na verdade, é possível causar danos com conexões unidirecionais (por exemplo, com protocolos sem estado como o UDP), mas isso se resume a evitar a autenticação (insegura) baseada em IP.
TCP
O TCP geralmente não é afetado, pois o estabelecimento da conexão exige o envio de volta de um pacote ao host de origem. É assim que funciona:
Alice está na lista de hosts autorizados.
- Alice envia um pacote SYN para Bob.
- Bob retorna SYN-ACK para Alice para sinalizar que ela pode prosseguir
- Alice prossegue com um pacote ACK e continua com a carga pretendida.
Charlie tenta se conectar ao serviço.
- Charlie envia um pacote SYN para Bob.
- O Firewall bloqueia o pacote, Bob não recebe nada (ou um aviso nos logs de que Charlie tentou se conectar a ele.
- Charlie pode ou não saber que sua solicitação foi rejeitada (dependendo da configuração do firewall, a solicitação expira ou Bob envia explicitamente um pacote ICMP rejeitado/inacessível)
Charlie de alguma forma sabe que Alice pode acessar o serviço.
- Charlie envia um pacote SYN para Bob, fingindo ser Alice.
- O pacote passa pelo Firewall, Bob retorna SYN-ACK para Alice.
- Alice responde RST-ACK (redefinir reconhecimento) ou ICMP Inacessível, já que ela não esperava algo de Bob.
- Charlie nunca saberá se o pedido foi atendido.
Agora, e se a conexão já estiver estabelecida? É para isso que servem os números de sequência: eles não podem (não devem) ser previstos por outros, e ambas as partes esperam que as sequências sempre aumentem em um.
- Quando a conexão é estabelecida, ambas as partes selecionam um número de sequência preferencialmente aleatório.
- Em cada pacote enviado, o número de sequência deve ser incrementado em um. Isso permite que a extremidade receptora rejeite pacotes com números de sequência errados e reordene aqueles que estão dentro da janela aceita.
Agora Charlie não tem como "injetar" pacotes em uma conexão existente entre Alice e Bob, pois ele não pode prever o número de sequência, e seus pacotes serão rejeitados por Bob, junto com talvez um aviso ou aviso nos logs.
UDP
Se o protocolo for UDP, ele é fortemente suscetível a falsificação, pois os pares são capazes de injetar pacotes falsificados na Internet; portanto, é necessário adicionar um mecanismo de autenticação ou criptografia na camada de aplicação em vez de transporte.
Mitigação
Os ISPs adicionarão medidas para evitar a falsificação de endereços IP. Poderia ser tão simples quanto rejeitar todos os pacotes que não correspondam aos seus próprios netblocks de sair do roteador, e pacotes que correspondam aos seus netblocks de entrar na rede.
Numa rede local, muitas vezes é muito fácil fazer spoofing, pois não existem muitos mecanismos para impedir que alguém o faça.