IP encaminhamento no Linux - algo importante para certificar-se de fazer ou saber?

2

Ao mover um site com um IP dedicado de um servidor para outro, para minimizar o tempo de inatividade devido a atrasos de propagação de DNS, há a abordagem de usar o encaminhamento de IP para que todo o tráfego para o IP original seja encaminhado para o novo IP.

Existe algo importante a saber ao fazer isso? Aqui estão os passos que pretendo usar. Existe alguma coisa de uma perspectiva de segurança ou de outra forma que eu esteja sentindo falta?

  1. echo "1" > /proc/sys/net/ipv4/ip_forward (ou defini-lo permanentemente)
  2. iptables -t nat -A PREROUTING -d original.ip.goes.here -p tcp --dport 80 -j DNAT --to-destination new.ip.goes.here
  3. iptables -t nat -A POSTROUTING -p tcp -d new.ip.goes.here --dport 80 -j MASQUERADE
  4. Repita # 2 e # 3, mas para a porta 443 , em vez de 80 , se o site tiver SSL

Eu entendo que o tempo de inatividade pode ser reduzido sem recorrer a isso diminuindo o TTL dos registros DNS o suficiente antes da mudança, mas isso ainda não é tão bom nisso, minimizando o tempo de inatividade já que supostamente alguns servidores DNS (e talvez clientes ) armazenará registros por mais tempo do que o TTL diz, se for curto.

EDITAR:

Parte do que me fez pensar se algo está faltando é a pergunta de por que ip_forward nem sempre está definido como 1 e, em vez disso, usa 0 - como se houvesse algum risco de segurança ou comportamento indesejado? se ele estiver definido como 1 em determinadas situações.

    
por sa289 17.01.2016 / 05:04

9 respostas

1

Não há insegurança inerente ao próprio encaminhamento de IP, além de como seu firewall é configurado, se eles são a mesma máquina. Pelo contrário, pode fornecer algum tipo de segurança, ocultando o ip do servidor real.

Ao ativar ip_forwarding , é possível transformar uma caixa linux em um roteador (que pode fazer o encaminhamento de pacotes entre redes) que nem sempre é necessário ou esperado e é por isso que é desativado por padrão. / p>

O artigo a seguir da RedHat explica tudo isso muito bem.

7.4. Regras FORWARD e NAT

Não está claro onde você está adicionando as regras, pois você precisará adicionar isso no firewall / roteador / gateway de borda que pode interceptar e rotear o pacote para o destino desejado. Caso contrário, não vai funcionar. E, desde que essas regras sejam aplicadas na borda, não há problemas de segurança adicionais envolvidos, pois a sua rede interna permanece protegida como antes. Mas isso depende da sua estrutura de rede.

Eu também acho que esta será uma medida temporária e as regras serão removidas mais tarde. Pode ser que você também deva fazer todos os testes possíveis e certificar-se de que isso funcionará da maneira que você quer.

    
por 19.01.2016 / 14:57
4

Part of what got me wondering if there's something I'm missing is the question of why ip_forward isn't always set to 1 and instead defaults to 0 - like is there some security risk or undesired behavior if having it set to 1 in certain situations.

Se o seu sistema (como muitos outros) não precisa ser um roteador, não há razão para ativar o roteamento.

Com relação à porta 80. Como você já tem um servidor da Web em escuta no example.com, é bastante fácil configurar um proxy reverso para o novo servidor da Web. Existem muitos exemplos de falha do servidor sobre como fazer isso, mas brevemente

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://example.com/
    ProxyPassReverse / http://example.com/

    ServerName example.com
</VirtualHost>

Você pode fazer exatamente o mesmo para https na porta 443

<VirtualHost *:443>
    ProxyPreserveHost On
    ProxyPass / https://example.com/
    ProxyPassReverse / https://example.com/

    ServerName example.com
</VirtualHost>

A única outra coisa que você precisa fazer é configurar um resolvedor de DNS local com uma entrada para example.com para que ele seja escolhido de preferência para o DNS global. Algo como dnsmasq deveria fazer isso facilmente.

Em seu caso particular, você prepara seus novos vhosts para example.com antecipadamente, instala o dnsmasq e adiciona example.com ao seu arquivo de hosts local. Então, quando você estiver pronto, ative o serviço dnsmasq e reinicie o apache e parta.

    
por 19.01.2016 / 15:47
1

ip_forwarding: ip_forwarding pode ser perigoso em situações em que endereços IP públicos são usados. Uma máquina Linux recém-instalada poderia então ser usada como um roteador para redes que não deveriam ser roteadas dessa maneira.

iptables: O principal problema com a configuração do iptables é provavelmente o roteamento na nova máquina. Essa máquina tem que usar a máquina antiga como um roteador para enviar de volta os pacotes mutilados e assim você acaba em um desafio de roteamento. É provavelmente muito mais seguro / fácil usar um proxy como o verniz para encaminhar o tráfego http. Se você usa o apache ou o nginx para hospedagem, pode até configurá-los como servidores proxy para o novo servidor da Web.

    
por 19.01.2016 / 15:21
1

Você pode usar o haproxy para isso. A configuração pode ser encontrada abaixo:

global
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    option                  abortonclose
    no option               checkcache
    option                  redispatch
    retries                 3
    timeout http-request    30s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout server          1m
    timeout http-keep-alive 5s
    timeout check           10s
    maxconn                 4000

# x.x.x.x = new IP
# y.y.y.y = old IP

listen l.x.x.x.x
       option forwardfor header X-Real-IP
       option http-server-close
       source y.y.y.y
       bind y.y.y.y:80
       server newserver x.x.x.x:80 id 1

listen l.x.x.x.x.ssl
       source y.y.y.y
       mode tcp
       bind y.y.y.y:443
       server newserver x.x.x.x:443 id 1

Além disso, você pode usar o dnsmasq para encaminhar as solicitações de DNS - uma resposta útil para isso pode ser encontrada aqui em serverfault Como impor dnsmasq para usar dns para alguns hosts?

    
por 19.01.2016 / 15:28
1

Eu movi os datacenters algumas vezes, com um bloco de classe C mudando junto com o movimento. É aconselhável usar o conntrack tanto no iptables quanto no snat.

Aqui está um pequeno script que usei algumas vezes. Simples e funciona como um encanto. Adicione portas adicionais conforme necessário. Depois que o DNS tiver sido atualizado e você não tiver mais conexões, remova as regras do iptables.

#!/bin/sh
IPTABLES="/sbin/iptables"

# modify to suit
EXTERNAL="eth0" 
OLDSERVER="10.10.10.1"
NEWSERVER="10.10.20.2"

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $EXTERNAL -o $EXTERNAL -p tcp --dport 80 -d $OLDSERVER -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t nat -A PREROUTING -i $EXTERNAL -p tcp --dport 80 -d $OLDSERVER -j DNAT --to-destination $NEWSERVER
$IPTABLES -t nat -A POSTROUTING -p tcp --dport 80 -d $NEWSERVER -j SNAT --to $OLDSERVER

echo 1 > /proc/sys/net/ipv4/ip_forward

Este encaminhamento deve ser implementado dentro de um firewall e não deixado para acesso público.

Quanto ao motivo pelo qual o encaminhamento não é definido por padrão, outras respostas podem ser mais adequadas: se o dispositivo não estiver roteando pacotes, ele não deverá estar ativado. É um risco de segurança? Tudo depende da função e configuração do servidor.

Espero que isso ajude.

    
por 19.01.2016 / 16:27
1

Você também precisa ter certeza de que -A Encaminhamento não está definido como ACEITAR, pois seu Servidor se tornaria um Roteador Aberto que poderia (e provavelmente será) usado para atividades maliciosas. Com isso dito basta adicionar uma regra para encaminhar apenas o tráfego que você precisa e você deve ser bom para ir.

O encaminhamento está provavelmente desativado por dois motivos: O número 1 é que cada módulo carregado e ativo usa poder de computação. Quando está desativado, você economiza poder de computação. É simples assim. O número 2 é um pouco mais complicado: quando alguém que é novo no Linux ou no Iptables usa apenas o conjunto de regras padrão, haverá a política de aceitação FORWARD padrão que leva a um roteador aberto (novamente). Como ninguém quer que exista uma segunda "medida de segurança" antes que o servidor comece a rotear pacotes.

    
por 20.01.2016 / 00:42
1

Seus redirecionamentos NAT do iptables funcionarão, mas esteja ciente de que esse método depende do módulo conntrack. Se o seu servidor tiver muitos pedidos simultâneos, a tabela conntrack ficará cheia e você terá um tempo de inatividade. É claro que você pode aumentar o tamanho da tabela de hash conntrack e como as pesquisas de hash são feitas, mas isso pode afetar o desempenho. Então, eu aconselho que você investigue isso minuciosamente se o seu servidor estiver atendendo muito tráfego na web.

Eu também não usaria -j MASQUERADE em suas regras aqui; apenas SNAT e DNAT. Eu já fiz isso antes; minhas regras são as seguintes:

iptables -t nat -A PREROUTING  -p tcp -s TEST_IP -d ORIGINAL_IP --dport 80 -j DNAT --to NEW_IP
iptables -t nat -A POSTROUTING -p tcp -s TEST_IP -d NEW_IP --dport 80 -j SNAT --to ORIGINAL_IP

Isso é útil porque restringe o encaminhamento para um endereço IP / host de fonte única (teste) e você poderá usar esse host para testar se o encaminhamento funciona. Quando estiver satisfeito, você poderá reaplicar essas regras com o -s TEST_IP removido.

Por causa do meu primeiro ponto sobre sobrecarga conntrack, eu ainda diminuiria o TTL do DNS como você descreveu - isso deve minimizar a quantidade total de tráfego que chega ao seu antigo servidor, então quaisquer solicitações não autorizadas são tratadas via redirecionamento de porta NAT do iptables, onde o volume de solicitações deve ser baixo o suficiente para não arriscar o preenchimento da sua tabela conntrack.

    
por 20.01.2016 / 16:20
0

Você não precisa de iptables , haproxy etc para uma tarefa tão simples. Basta instalar rinetd , o arquivo de configuração é mais simples.

<your IP/FQDN> <your port> <where to forward IP/FQDN> <where to forward port>

i.e.

old.webserver.com 80 new.webserver.com 80
    
por 20.01.2016 / 12:47
-2

O melhor exemplo que vi de encaminhamento de IP é o site da cidade de Taiji, no Japão. Como um alvo popular para os hactivistas, eles mantêm um servidor web Apache desatualizado no seu endereço IP de destino de encaminhamento dedicado de 58.94.160.100. Isso serve como uma haste de iluminação para seus outros três servidores, que são modelos MS 2012R, atribuídos a 10.0.0.0, mas fisicamente localizados em partes desconhecidas. Eles utilizam uma dúzia de empresas de hospedagem diferentes para estabilizar seu site enquanto usam encaminhamento de IP persistente, com quase nenhum tempo de inatividade. A menos que sua empresa seja um alvo popular para ataques de negação de serviço, o encaminhamento do seu sinal para o endereço IP dedicado e encaminhado não deve ser um problema, especialmente com o planejamento antecipado. Minha VPN usa uma rede NYC, que está registrada no opendns.com, e com att.net como meu ISP, isso me dá os servidores de nomes em 208.67.220.220 e 208.67.222.222 que estão próximos dos servidores de nomes att.net em 209.xxx .xxx.xxx. Meu loop está definido para 127.0.0.1, que funciona bem usando Tor e dnschef nos modos TCP e ipv6. Meu primeiro adaptador de rede é NAT, então eu designo mais dois como rede nat, com meu quarto e último adaptador como host apenas. O resultado é que eu sempre ocupei 10.0.2.2, 127.0.0.1 ou 192.156.0.100 e isso é ideal para o anonimato com o benefício adicional de poder resolver endereços de sites. Em suma, pensei que o encaminhamento de IP provavelmente fosse utilizado para fins de segurança, portanto, o padrão 0 pode ser uma maneira de proteger o anonimato das geografias de sub-redes específicas, mesmo com servidores de nomes registrados, pois deve haver uma separação completa do trabalho rede em caso de avaria no IP encaminhado. É pouco provável que as pessoas que pesquisam seu IP detectem qualquer vazamento de DNS, pois o sistema precisará ser mantido ativamente. Ouvi dizer que existem cerca de 50.000 servidores de nomes públicos disponíveis em todo o mundo, e alguém com sua experiência em rede pode facilmente trabalhar alguns deles em seu sistema, temporariamente enquanto se desloca, e evitar qualquer tempo de inatividade.

    
por 19.01.2016 / 07:03