Este artigo é o quarto de uma série sobre "Como controlar sua infraestrutura de rede". O conteúdo de todos os artigos da série e links podem ser encontrados aqui.

Em primeira parte nesta seção, abordamos alguns aspectos da segurança de rede do segmento "Data Center". Esta parte será dedicada ao segmento "Acesso à Internet".

Acesso à Internet

O tema da segurança é, sem dúvida, um dos mais complexos no mundo das redes de dados. Como nos casos anteriores, sem pretender ser exhaustivo, abordarei aqui questões relativamente simples, mas que, na minha opinião, são importantes, cujas respostas espero que ajudem a aumentar o nível de segurança da sua rede.

Ao auditar este segmento, preste atenção nos seguintes aspectos:

design
configurações BGP
Proteção contra DOS/DDOS
filtragem de tráfego no firewall

Design

Como exemplo de design deste segmento para uma rede empresarial, eu recomendaria manual da Cisco no âmbito do modelo SAFE.

Claro que, talvez, a solução de outros fornecedores lhe pareça mais atraente (ver quadrante do Gartner de 2018), mas, sem convidá-lo a seguir este design em detalhes, ainda considero útil compreender os princípios e ideias subjacentes.

Observação
No modelo SAFE, o segmento "Acesso Remoto" é parte do "Acesso à Internet". Mas nesta série de artigos, o abordaremos separadamente.

O conjunto padrão de equipamentos neste segmento para uma rede empresarial é composto por

roteadores de borda
firewalls

Observação 1
Nesta série de artigos, ao falar sobre firewalls, refiro-me a NGFW.

Observação 2
Não estou abordando soluções L2/L1 ou soluções L2 sobre L3 que são necessárias para garantir a conectividade L1/L2, limitando-me apenas a questões do nível L3 e acima. Em parte, as questões L1/L2 foram discutidas no capítulo "Limpeza e documentação«.

Se você não encontrou um firewall neste segmento, não se apresse em tirar conclusões.

Vamos, como na parte anterior, começar com a pergunta: é necessário usar um firewall neste segmento, no seu caso?

Posso dizer que parece ser o local mais justificável para a utilização de firewalls e para a aplicação de algoritmos complexos de filtragem de tráfego. Na parte 1 , mencionamos 4 fatores que podem impedir o uso de firewalls no segmento de data center. Mas aqui eles não são tão significativos.

Exemplo 1. Latência
Quando se trata de internet, não faz sentido falar em latências até mesmo na ordem de 1 milissegundo. Portanto, a latência neste segmento não pode ser um fator que limita o uso do firewall.

Exemplo 2. Desempenho
Em alguns casos, esse fator ainda pode ser significativo. Assim, pode ser que você precise desviar parte do tráfego (por exemplo, o tráfego de balanceadores de carga) ao redor do firewall.

Exemplo 3. Confiabilidade
Esse fator ainda precisa ser levado em conta, mas, considerando a instabilidade da própria internet, sua importância para este segmento não é tão significativa quanto para o data center.
Suponha que seu serviço opere sobre http/https (com sessões curtas). Nesse caso, você pode usar duas máquinas independentes (sem HA) e, em caso de problemas com uma delas, redirecionar todo o tráfego para a segunda.
Ou você pode usar firewalls em modo transparente e, ao falhar, direcionar o tráfego ao redor dos firewalls enquanto o problema é resolvido.

Portanto, é mais provável que apenas o preço seja o fator que o levará a abandonar o uso de firewalls neste segmento.

Importante!
Há uma tentação de combinar este firewall com o firewall do data center (usar um único firewall para esses segmentos). A solução, em princípio, é possível, mas deve-se entender que, como o firewall de ‘Acesso à Internet’ está, de fato, na linha de frente da sua defesa e ‘recebe’, pelo menos, parte do tráfego malicioso, é claro que é preciso considerar o risco aumentado de que este firewall venha a ser comprometido. Ou seja, usando os mesmos dispositivos em ambos os segmentos, você reduzirá significativamente a disponibilidade do seu segmento de data center.

Como de costume, é preciso entender que, dependendo do serviço que a empresa fornece, o design deste segmento pode variar bastante. Você pode escolher diferentes abordagens, conforme as demandas.

Exemplo
Se você é um provedor de conteúdo, com uma rede CDN (veja, por exemplo, uma série de artigos), você pode não querer criar infraestrutura com dezenas, ou até centenas, de pontos de presença usando dispositivos separados para roteamento e filtragem de tráfego. Isso seria caro e pode ser simplesmente excessivo.
Para BGP, não é necessário ter roteadores dedicados; você pode usar ferramentas open-source, como Quagga. Portanto, o que você pode precisar é de um servidor ou vários servidores, um switch e BGP.
Nesse caso, seu servidor ou vários servidores podem atuar não apenas como servidor CDN, mas também como roteador. Claro, há muitos detalhes a considerar (como garantir o balanceamento), mas isso é viável, e essa abordagem foi aplicada com sucesso para um de nossos parceiros.
Você pode ter vários data centers com proteção completa (firewalls, serviços de proteção contra DDoS fornecidos por seus provedores de Internet) e dezenas ou centenas de ‘pontos de presença simplificados’ apenas com switches L2 e servidores.
E quanto à proteção neste caso?
Vamos analisar, por exemplo, o popular ataque de DDoS por Amplificação de DNS. Seu perigo reside no fato de que gera uma grande quantidade de tráfego que simplesmente 'sobrecarrega' 100% de suas uplinks.
O que temos em nosso design.

Se você usar AnyCast, o tráfego é distribuído entre seus pontos de presença. Se a largura de banda total for em terabits, isso, por si só (ainda que recentemente tenha havido alguns ataques com tráfego malicioso da ordem de um terabit) protege você contra ‘desbordamento’ de uplinks.

Se, de fato, algum uplink 'estiver congestionado', você simplesmente retira esse local de operação (para de anunciar o prefixo).

Você também pode aumentar a parte do tráfego proveniente de seus data centers 'completos' (e, consequentemente, protegidos), assim removendo uma parte significativa do tráfego malicioso dos pontos de presença não protegidos.
E mais uma pequena observação sobre esse exemplo. Se uma quantidade suficiente de tráfego for gerenciada através de IXs, isso também reduz sua vulnerabilidade a tais ataques.

Configuração do BGP.

Aqui temos dois tópicos.

Conectividade
Configuração do BGP.

Já falamos um pouco sobre conectividade em parte 1. A essência é que o tráfego para seus clientes siga o caminho mais otimizado. Embora a otimização não seja sempre apenas sobre latência, geralmente, uma baixa latência é o principal indicador de otimização. Para algumas empresas, isso é mais importante; para outras, menos. Tudo depende do serviço que você oferece.

Exemplo 1
Se você é uma bolsa de valores e seus clientes precisam de intervalos de tempo inferiores a milissegundos, então, claramente, a internet não pode ser considerada.

Exemplo 2
Se você é uma empresa de jogos e dezenas de milissegundos são importantes para você, então a conectividade é, sem dúvida, muito relevante.

Exemplo 3
Também é necessário entender que, devido às propriedades do protocolo TCP, a velocidade de transmissão de dados em uma sessão TCP também depende do RTT (Round Trip Time). As redes CDN são construídas, em parte, para resolver esse problema, trazendo os servidores de distribuição de conteúdo mais perto do consumidor desse conteúdo.

A pesquisa sobre conectividade é uma questão separada e interessante, merecendo um artigo ou uma série de artigos, e requer uma boa compreensão de como a internet "funciona".

Recursos úteis:

ripe.net
bgp.he.net

Exemplo
Vou fornecer apenas um pequeno exemplo.
Suponha que seu data center esteja em Moscovo, e você tenha um único uplink – Rostelecom (AS12389). Nesse caso (single homed), o BGP não é necessário, e como endereços públicos, você provavelmente usará um bloco de endereços do Rostelecom.
Suponha que você ofereça um serviço e tenha um número suficiente de clientes da Ucrânia que reclamam de grandes latências. Ao investigar, você descobriu que os endereços IP de alguns deles estão na rede 37.52.0.0/21.
Executando um traceroute, você viu que o tráfego passava pelo AS1299 (Telia), e ao executar um ping, você obteve um RTT médio de 70 a 80 milissegundos. Você pode ver isso também no looking glass do Rostelecom.
Com a ferramenta whois (no site ripe.net ou na ferramenta local), você pode facilmente determinar que o bloco 37.52.0.0/21 pertence ao AS6849 (Ukrtelecom).
Em seguida, ao acessar bgp.he.net você verá que o AS6849 não tem relações com o AS12389 (eles não são nem clientes, nem uplinks um do outro, e também não têm peering). Mas se você olhar a lista de peers para o AS6849, verá, por exemplo, AS29226 (Mastertel) e AS31133 (Megafon).
Ao encontrar o looking glass desses provedores, você pode comparar o caminho e o RTT. Por exemplo, para Mastertel, o RTT será em torno de 30 milissegundos.
Portanto, se a diferença entre 80 e 30 milissegundos é significativa para o seu serviço, talvez você precise considerar a conectividade, obter seu número AS no RIPE, seu bloco de endereços e conectar uplinks adicionais e/ou criar pontos de presença em IXs.

Ao usar BGP, você não apenas melhora a conectividade, mas também reserva sua conexão com a internet.

Este documento contém recomendações para configurar o BGP. Apesar de essas recomendações terem sido elaboradas com base nas melhores práticas dos provedores, elas são, sem dúvida, úteis e devem fazer parte do hardening que discutimos em primeira parte.

Proteção contra DOS/DDOS

Atualmente, ataques de DOS/DDOS se tornaram uma realidade cotidiana para muitas empresas. Na verdade, de uma forma ou de outra, você está sendo atacado com bastante frequência. O fato de você ainda não ter notado isso indica apenas que não houve um ataque direcionado contra você até agora, e que os meios de proteção que você utiliza, mesmo sem saber (como várias proteções embutidas nos sistemas operacionais), são suficientes para minimizar a degradação do serviço prestado para você e seus clientes.

Existem recursos na internet que, com base em logs do equipamento, desenham mapas bonitos de ataques em tempo real.

Aqui Você pode encontrar links para eles.

Meu favorito mapa da CheckPoint.

A proteção contra DDOS/DOS geralmente é em camadas. Para entender o porquê, é necessário saber quais tipos de ataques DOS/DDOS existem (veja, por exemplo, aqui ou aqui)

Isso significa que temos três tipos de ataques:

ataques volumétricos
ataques de protocolo
ataques de aplicação

Enquanto você pode se proteger dos últimos dois tipos de ataques por conta própria usando, por exemplo, firewalls, você não conseguirá se proteger contra ataques que visam "sobrecargas" em seus uplinks (a menos que sua capacidade total de canais de internet não seja medida em terabits, e de preferência em dezenas de terabits).

Portanto, a primeira linha de defesa é a proteção contra ataques "volumétricos", e essa proteção deve ser fornecida por seu provedor ou provedores. Se você ainda não percebeu isso, é porque até agora você teve sorte.

Exemplo
Suponha que você tenha vários uplinks, mas apenas um dos provedores pode fornecer essa proteção. Mas se todo o tráfego passar por um único provedor, como fica a conectividade que discutimos brevemente anteriormente?
Durante um ataque, você terá que sacrificar parcialmente a conectividade.

isso é apenas durante o ataque. Você pode, em caso de ataque, reconfigurar manualmente ou automaticamente o BGP, fazendo com que o tráfego seja direcionado apenas através do provedor que lhe oferece um "guarda-chuva". Após o término do ataque, você pode restaurar o roteamento ao seu estado anterior.

não é necessário redirecionar todo o tráfego. Se você, por exemplo, perceber que alguns uplinks ou peering não estão sob ataque (ou o tráfego não é significativo), pode continuar a anunciar os prefixos com atributos competitivos para esses vizinhos BGP.

Você também pode deixar a proteção contra "protocol attacks" e "application attacks" para parceiros.
Aqui aqui você pode ler uma boa pesquisa (tradução). Na verdade, o artigo é de dois anos atrás, mas isso vai lhe dar uma ideia das abordagens que você pode adotar para se proteger contra ataques DDoS.

Basicamente, você pode se limitar a isso, confiando totalmente sua proteção a uma empresa terceirizada. Essa solução tem seus prós, mas também um óbvio contra. A verdade é que pode se tratar (novamente, dependendo do que sua empresa faz) da sobrevivência do negócio. E confiar essas questões a organizações externas...

Portanto, vamos examinar como organizar uma segunda e terceira linha de defesa (como complemento à proteção do provedor).

Assim, a segunda linha de defesa consiste em filtragem e limitadores de tráfego (policers) na entrada da sua rede.

Exemplo 1
Suponha que você tenha "se protegido com um guarda-chuva" contra DDoS com a ajuda de um dos provedores. Suponha que esse provedor utilize Arbor para filtrar o tráfego e filtros na borda de sua rede.
A largura de banda que o Arbor pode "processar" é limitada e o provedor, naturalmente, não pode constantemente passar o tráfego de todos os seus parceiros que contrataram esse serviço através do equipamento de filtragem. Assim, em condições normais, o tráfego não é filtrado.
Suponha que esteja ocorrendo um ataque de SYN flood. Mesmo que você tenha contratado um serviço que, em caso de ataque, redireciona automaticamente o tráfego para filtragem, isso não acontece instantaneamente. Durante um minuto ou mais, você permanece sob ataque. E isso pode levar à falha do seu equipamento ou degradação do serviço. Nesse caso, a limitação de tráfego no roteador de borda, embora impeça que algumas sessões TCP sejam estabelecidas durante esse tempo, salvará sua infraestrutura de problemas maiores.

Exemplo 2
Um volume anormal de pacotes SYN pode não ser apenas resultado de um ataque de SYN flood. Vamos supor que você ofereça um serviço em que pode ter cerca de 100 mil conexões TCP simultâneas (em um único data center).
Suponha que, devido a um problema temporário com um de seus principais provedores, metade das sessões tenha sido “derrubada”. Se o seu aplicativo estiver configurado de forma que, "sem pensar", imediatamente (ou após um determinado intervalo de tempo uniforme para todas as sessões) tenta restabelecer a conexão, você receberá aproximadamente ao mesmo tempo pelo menos 50 mil pacotes SYN.
Se, sobre essas sessões, por exemplo, deve funcionar um handshake ssl/tls, que implica na troca de certificados, então, do ponto de vista do esgotamento de recursos para o seu balanceador de carga, isso será um "DDOS" muito mais forte do que um simples SYN flood. A princípio, os balanceadores deveriam lidar com tal evento, mas… infelizmente, enfrentamos esse problema de forma contundente.
E, claro, um policer no roteador de borda salvará seu equipamento nesse caso.

O terceiro nível de proteção contra DDOS/DOS são as configurações do seu firewall.

Aqui você pode conter ataques do segundo e do terceiro tipo. Em geral, tudo o que chegar ao firewall poderá ser filtrado aqui.

Conselho
Tente dar ao firewall o mínimo trabalho possível, filtrando o máximo que puder nas duas primeiras linhas de defesa. E é por isso.
Já aconteceu de você, ao gerar tráfego para testar, por exemplo, quão resistente é o sistema operacional dos seus servidores a ataques DDOS, acabar ‘matando’ seu firewall ao sobrecarregá-lo 100% com tráfego de intensidade normal? Se não, talvez seja porque você ainda não tentou?
Em geral, o firewall, como eu já disse, é uma tecnologia complexa e funciona bem com vulnerabilidades conhecidas e soluções testadas. No entanto, se você enviar algo incomum, como um lixo qualquer ou pacotes com cabeçalhos incorretos, há uma chance considerável (com base na minha experiência) de que ele possa confundir equipamentos de alta performance. Portanto, na etapa 2, use listas de controle de acesso (ACLs) comuns (nos níveis L3/L4) para permitir apenas o tráfego que deveria entrar na sua rede.