Este artigo é o quarto da série “Como assumir o controle de sua infraestrutura de rede”. O conteúdo de todos os artigos da série e links podem ser encontrados .
В Neste capítulo, analisamos alguns aspectos da segurança de rede no segmento de Data Center. Esta parte será dedicada ao segmento “Acesso à Internet”.
Acesso à Internet
O tema segurança é sem dúvida um dos temas mais complexos do mundo das redes de dados. Tal como nos casos anteriores, sem pretender profundidade e exaustividade, considerarei aqui questões bastante simples, mas, na minha opinião, importantes, cujas respostas, espero, ajudem a aumentar o nível de segurança da sua rede.
Ao auditar este segmento, preste atenção aos seguintes aspectos:
- projeto
- Configurações de BGP
- Proteção DOS/DDOS
- filtragem de tráfego no firewall
Projeto
Como exemplo do design deste segmento para uma rede corporativa, eu recomendaria da Cisco dentro .
Claro, talvez a solução de outros fornecedores pareça mais atraente para você (veja. ), mas sem encorajá-lo a seguir esse design detalhadamente, ainda acho útil entender os princípios e ideias por trás dele.
Nota
No SAFE, o segmento “Acesso Remoto” faz parte do segmento “Acesso à Internet”. Mas nesta série de artigos consideraremos isso separadamente.
O conjunto padrão de equipamentos neste segmento para uma rede corporativa é
- roteadores de fronteira
- firewalls
Nota 1
Nesta série de artigos, quando falo sobre firewalls, quero dizer .
Nota 2
Omito a consideração de vários tipos de soluções L2/L1 ou de sobreposição L2 sobre L3 necessárias para garantir a conectividade L1/L2 e limito-me apenas a questões no nível L3 e acima. Parcialmente, questões de L1/L2 foram discutidas no capítulo “".
Se você não encontrou um firewall neste segmento, não tire conclusões precipitadas.
Vamos fazer o mesmo que em Vamos começar com a pergunta: é necessário utilizar firewall nesse segmento no seu caso?
Posso dizer que este parece ser o local mais justificado para usar firewalls e aplicar algoritmos complexos de filtragem de tráfego. EM Mencionamos 4 fatores que podem interferir no uso de firewalls no segmento de data center. Mas aqui eles não são mais tão significativos.
Exemplo 1. O atraso
No que diz respeito à Internet, não faz sentido falar em atrasos de cerca de 1 milissegundo. Portanto, o atraso neste segmento não pode ser um fator limitante ao uso do firewall.
Exemplo 2. Desempenho
Em alguns casos, esse fator ainda pode ser significativo. Portanto, talvez seja necessário permitir que algum tráfego (por exemplo, tráfego de balanceadores de carga) contorne o firewall.
Exemplo 3. Confiança
Este fator ainda precisa ser levado em consideração, mas ainda assim, dada a falta de confiabilidade da própria Internet, sua importância para este segmento não é tão significativa quanto para o data center.
Então, vamos supor que seu serviço seja baseado em http/https (com sessões curtas). Neste caso, você pode usar duas caixas independentes (sem HA) e caso haja problema de roteamento com uma delas, transferir todo o tráfego para a segunda.
Ou você pode usar firewalls em modo transparente e, se falharem, permitir que o tráfego contorne o firewall enquanto resolve o problema.
Portanto, provavelmente apenas preço pode ser o fator que o obrigará a abandonar o uso de firewalls neste segmento.
Importante!
Existe a tentação de combinar esse firewall com o firewall do data center (use um firewall para esses segmentos). A solução é, em princípio, possível, mas você precisa entender isso porque Um firewall de acesso à Internet está realmente na vanguarda da sua defesa e “assume” pelo menos parte do tráfego malicioso, então, é claro, você precisa levar em consideração o risco aumentado de que esse firewall seja desativado. Ou seja, ao utilizar os mesmos dispositivos nesses dois segmentos, você reduzirá significativamente a disponibilidade do segmento do seu data center.
Como sempre, é preciso entender que dependendo do serviço que a empresa presta, o desenho desse segmento pode variar bastante. Como sempre, você pode escolher diferentes abordagens dependendo de suas necessidades.
Exemplo
Se você é um provedor de conteúdo, com uma rede CDN (veja, por exemplo, ), talvez você não queira criar infraestrutura em dezenas ou mesmo centenas de pontos de presença usando dispositivos separados para roteamento e filtragem de tráfego. Será caro e pode simplesmente ser desnecessário.
Para BGP você não precisa necessariamente ter roteadores dedicados, você pode usar ferramentas de código aberto como . Então talvez tudo que você precise seja de um servidor ou vários servidores, um switch e BGP.
Nesse caso, seu servidor ou vários servidores podem desempenhar o papel não apenas de um servidor CDN, mas também de um roteador. É claro que ainda há muitos detalhes (como a forma de garantir o equilíbrio), mas é exequível e é uma abordagem que utilizámos com sucesso para um dos nossos parceiros.
Você pode ter vários data centers com proteção total (firewalls, serviços de proteção DDOS fornecidos por seus provedores de Internet) e dezenas ou centenas de pontos de presença “simplificados” apenas com switches e servidores L2.
Mas e a proteção neste caso?
Vejamos, por exemplo, o recentemente popular . O seu perigo reside no facto de ser gerada uma grande quantidade de tráfego, que simplesmente “obstrui” 100% de todos os seus uplinks.
O que temos no caso do nosso design.
- se você usar AnyCast, o tráfego será distribuído entre seus pontos de presença. Se a sua largura de banda total for de terabits, então isso por si só (no entanto, recentemente houve vários ataques com tráfego malicioso da ordem de terabits) protege você de uplinks “transbordantes”
- Se, no entanto, alguns uplinks ficarem obstruídos, basta remover este site de serviço (parar de anunciar o prefixo)
- você também pode aumentar a parcela do tráfego enviado de seus data centers “completos” (e, portanto, protegidos), removendo assim uma parte significativa do tráfego malicioso de pontos de presença desprotegidos
E mais uma pequena nota para este exemplo. Se você enviar tráfego suficiente através de IXs, isso também reduzirá sua vulnerabilidade a tais ataques
Configurando o BGP
Existem dois tópicos aqui.
- Conectividade
- Configurando o BGP
Já falamos um pouco sobre conectividade em . O objetivo é garantir que o tráfego para seus clientes siga o caminho ideal. Embora a otimização nem sempre seja apenas uma questão de latência, a baixa latência geralmente é o principal indicador de otimização. Para algumas empresas isto é mais importante, para outras é menos. Tudo depende do serviço que você presta.
Exemplo 1
Se você é uma exchange e intervalos de tempo inferiores a milissegundos são importantes para seus clientes, então, é claro, não se pode falar de nenhum tipo de Internet.
Exemplo 2
Se você é uma empresa de jogos e dezenas de milissegundos são importantes para você, então, é claro, a conectividade é muito importante para você.
Exemplo 3
Você também precisa entender que, devido às propriedades do protocolo TCP, a taxa de transferência de dados dentro de uma sessão TCP também depende do RTT (Round Trip Time). As redes CDN também estão sendo construídas para resolver esse problema, aproximando os servidores de distribuição de conteúdo do consumidor desse conteúdo.
O estudo da conectividade é um tema interessante por si só, digno de um artigo ou de uma série de artigos, e requer uma boa compreensão de como a Internet “funciona”.
Recursos úteis:
Exemplo
Vou dar apenas um pequeno exemplo.
Suponhamos que seu data center esteja localizado em Moscou e você tenha um único uplink - Rostelecom (AS12389). Neste caso (single homed) você não precisa do BGP e provavelmente usa o pool de endereços da Rostelecom como endereços públicos.
Suponhamos que você forneça um determinado serviço e tenha um número suficiente de clientes da Ucrânia, e eles reclamam de longos atrasos. Durante sua pesquisa, você descobriu que os endereços IP de alguns deles estão na grade 37.52.0.0/21.
Ao executar um traceroute, você viu que o tráfego estava passando pelo AS1299 (Telia) e, ao executar um ping, obteve um RTT médio de 70 a 80 milissegundos. Você também pode ver isso em .
Usando o utilitário whois (em Maduro.net ou um utilitário local), você pode determinar facilmente que o bloco 37.52.0.0/21 pertence ao AS6849 (Ukrtelecom).
A seguir, indo para você vê que o AS6849 não tem relacionamento com o AS12389 (eles não são clientes nem uplinks entre si, nem têm peering). Mas se você olhar para AS6849, você verá, por exemplo, AS29226 (Mastertel) e AS31133 (Megafon).
Depois de encontrar o espelho desses provedores, você pode comparar o caminho e o RTT. Por exemplo, para Mastertel, o RTT será de cerca de 30 milissegundos.
Portanto, se a diferença entre 80 e 30 milissegundos for significativa para o seu serviço, talvez você precise pensar em conectividade, obter seu número AS, seu pool de endereços do RIPE e conectar uplinks adicionais e/ou criar pontos de presença em IXs.
Ao usar o BGP, você não apenas tem a oportunidade de melhorar a conectividade, mas também mantém sua conexão com a Internet de forma redundante.
contém recomendações para configurar o BGP. Apesar de essas recomendações terem sido desenvolvidas com base nas “melhores práticas” dos provedores, no entanto (se suas configurações de BGP não forem tão básicas) elas são sem dúvida úteis e de fato deveriam fazer parte do fortalecimento que discutimos em .
Proteção DOS/DDOS
Agora, os ataques DOS/DDOS se tornaram uma realidade cotidiana para muitas empresas. Na verdade, você é atacado com frequência de uma forma ou de outra. O facto de ainda não ter percebido isso significa apenas que ainda não foi organizado um ataque direccionado contra si e que as medidas de protecção que utiliza, mesmo talvez sem o saber (várias protecções integradas nos sistemas operativos), são suficientes para garantir que a degradação do serviço prestado seja minimizada para você e seus clientes.
Existem recursos da Internet que, com base em registros de equipamentos, desenham lindos mapas de ataque em tempo real.
você pode encontrar links para eles.
Meu favorito do CheckPoint.
A proteção contra DDOS/DOS geralmente é feita em camadas. Para entender o porquê, você precisa entender quais tipos de ataques DOS/DDOS existem (veja, por exemplo, ou )
Ou seja, temos três tipos de ataques:
- ataques volumétricos
- ataques de protocolo
- ataques a aplicativos
Se você puder se proteger dos dois últimos tipos de ataques usando, por exemplo, firewalls, então não poderá se proteger de ataques que visam “sobrecarregar” seus uplinks (é claro, se sua capacidade total de canais de Internet não for calculada em terabits, ou melhor ainda, em dezenas de terabit).
Portanto, a primeira linha de defesa é a proteção contra ataques “volumétricos”, e seu provedor ou provedores devem fornecer essa proteção para você. Se você ainda não percebeu isso, então você está com sorte por enquanto.
Exemplo
Digamos que você tenha vários uplinks, mas apenas um dos provedores pode lhe fornecer essa proteção. Mas se todo o tráfego passa por um provedor, o que dizer da conectividade que discutimos brevemente um pouco antes?
Nesse caso, você terá que sacrificar parcialmente a conectividade durante o ataque. Mas
- isso é apenas durante o ataque. No caso de um ataque, você pode reconfigurar o BGP manual ou automaticamente para que o tráfego passe apenas pelo provedor que lhe fornece o “guarda-chuva”. Após o término do ataque, você pode retornar o roteamento ao estado anterior
- Não é necessário transferir todo o tráfego. Se, por exemplo, você perceber que não há ataques por meio de alguns uplinks ou peerings (ou o tráfego não é significativo), você poderá continuar a anunciar prefixos com atributos competitivos para esses vizinhos do BGP.
Você também pode delegar proteção contra “ataques de protocolo” e “ataques de aplicativos” aos seus parceiros.
aqui é você pode ler um bom estudo (). É verdade que o artigo tem dois anos, mas lhe dará uma ideia das abordagens sobre como você pode se proteger de ataques DDOS.
Em princípio, você pode limitar-se a isso, terceirizando completamente sua proteção. Existem vantagens nesta decisão, mas também existe uma desvantagem óbvia. O fato é que podemos conversar (de novo, dependendo do que sua empresa fizer) sobre a sobrevivência do negócio. E confie essas coisas a terceiros...
Portanto, vejamos como organizar a segunda e terceira linhas de defesa (como complemento à proteção do provedor).
Assim, a segunda linha de defesa é a filtragem e limitadores de tráfego (policiais) na entrada da sua rede.
Exemplo 1
Vamos supor que você tenha se protegido contra DDOS com a ajuda de um dos provedores. Vamos supor que este provedor use o Arbor para filtrar tráfego e filtros na borda de sua rede.
A largura de banda que a Arbor pode “processar” é limitada, e o provedor, claro, não pode passar constantemente o tráfego de todos os seus parceiros que solicitam este serviço através de equipamentos de filtragem. Portanto, em condições normais, o tráfego não é filtrado.
Vamos supor que haja um ataque de inundação SYN. Mesmo que você tenha solicitado um serviço que muda automaticamente o tráfego para filtragem em caso de ataque, isso não acontecerá instantaneamente. Por um minuto ou mais você permanece sob ataque. E isso pode levar à falha do seu equipamento ou à degradação do serviço. Nesse caso, limitar o tráfego no roteamento de borda, embora faça com que algumas sessões TCP não sejam estabelecidas durante esse período, salvará sua infraestrutura de problemas de maior escala.
Exemplo 2
Um número anormalmente grande de pacotes SYN pode não ser apenas o resultado de um ataque de inundação SYN. Suponhamos que você forneça um serviço no qual possa ter simultaneamente cerca de 100 mil conexões TCP (para um data center).
Digamos que, como resultado de um problema de curto prazo com um de seus principais provedores, metade de suas sessões sejam canceladas. Se a sua aplicação for projetada de forma que, sem pensar duas vezes, tente imediatamente (ou após algum intervalo de tempo igual para todas as sessões) restabelecer a conexão, então você receberá pelo menos 50 mil pacotes SYN aproximadamente simultaneamente.
Se, por exemplo, você tiver que executar o handshake SSL/TLS sobre essas sessões, o que envolve a troca de certificados, então, do ponto de vista de esgotamento de recursos para o seu balanceador de carga, este será um “DDOS” muito mais forte do que um simples Inundação SYN. Parece que os balanceadores deveriam lidar com tais eventos, mas... infelizmente, enfrentamos esse problema.
E, claro, um policial no roteador de borda também salvará seu equipamento neste caso.
O terceiro nível de proteção contra DDOS/DOS são as configurações do firewall.
Aqui você pode interromper os ataques do segundo e terceiro tipos. Em geral, tudo que chega ao firewall pode ser filtrado aqui.
Conselho
Tente dar o mínimo de trabalho possível ao firewall, filtrando o máximo possível nas duas primeiras linhas de defesa. E é por causa disso.
Já aconteceu com você que por acaso, ao gerar tráfego para verificar, por exemplo, o quão resistente é o sistema operacional de seus servidores a ataques DDOS, você “matou” seu firewall, carregando-o a 100%, com tráfego em intensidade normal ? Se não, talvez seja simplesmente porque você ainda não tentou?
Em geral, um firewall, como eu disse, é uma coisa complexa e funciona bem com vulnerabilidades conhecidas e soluções testadas, mas se você enviar algo incomum, apenas algum lixo ou pacotes com cabeçalhos incorretos, então você está com alguns, não com com uma probabilidade tão pequena (com base na minha experiência), você pode entorpecer até mesmo equipamentos de última geração. Portanto, no estágio 2, usando ACLs regulares (no nível L3/L4), permita apenas o tráfego em sua rede que deveria entrar lá.
Filtrando o tráfego no firewall
Vamos continuar a conversa sobre o firewall. Você precisa entender que os ataques DOS/DDOS são apenas um tipo de ataque cibernético.
Além da proteção DOS/DDOS, também podemos ter algo como a seguinte lista de recursos:
- firewall de aplicativos
- prevenção de ameaças (antivírus, anti-spyware e vulnerabilidade)
- Filtragem de URL
- filtragem de dados (filtragem de conteúdo)
- bloqueio de arquivos (bloqueio de tipos de arquivos)
Cabe a você decidir o que precisa nesta lista.
Para ser continuado
Fonte: habr.com