[GTER] Sugestão Roteador

Thu Jun 9 09:00:27 -03 2022

Mais uma coisa que me perguntaram num mensageiro instantâneo e achei
interessante compartilhar:

(adaptei a pergunta)
"Porque você diz que para um ISP provavelmente não vale a pena usar um
Firewall como Border?"

Resposta rápida? DINHEIRO!
- Um Roteador que consegue encaminhar uns 400Gbps hoje deve custar uns
R$50-80 mil reais.
- Um Firewall com funcionalidade medianas(sem falar de deep inspection e
NGFW) que consiga encaminhar uns 40Gbps vai custar também uns
R$50-80mil reais.

Ou seja... Numa fala muito grosseira, dá pra dizer que a diferença de
firewall e roteador é de quase umas 10 vezes no custo por tráfego
encaminhado.
(Tô falando aqui de coisa normal, sem gambiarra hein!)

A função principal de um ISP não é Firewallzar nada, e apenas encaminhar
pacotes
Um ISP é só um carteiro que entrega cartas(leia-se pacotes IP).

Acaba existindo alguns tipos de filtragens para se manter a sanidade da
comunicação Internet.
Um exemplo é o bloqueio da porta 25, ou por exemplo o anti-spoofing...
Mas esse e outros são bloqueios "secos", que quase que certamente não
dependem de olhar para uma tabela de conexão ativa(a tal da contrack).

Existem tráfegos de ISPs que tem sim que passar por analise de conexão
statefull.
- O exemplo mais clássico é o CGNAT, que não existe sem Contrack.
- Mas também tem a parte de Firewall de Servidores e similares.

O lance é que no geral, um ISP com uns 100Gbps, em condições normais de
temperatura e pressão(e desconsiderando gambiarras) deveria ter uns
10-20Gbps de tráfego que passe por filtragem statefull.
Acho que aí já deu pra fazer as contas que quanto isso custaria né?

Em qui., 9 de jun. de 2022 às 08:26, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> Chegou para mim privadamente um questionamento sobre esse thread de e-mail
> que achei interessante e pertinente compartilhar com os demais colegas.
> Vou responder à pergunta no grupo, mas sem mencionar o colega que trouxe
> ela.
>
> <email_privado>
> Bom dia
>
> Tudo bem?
> Eu li sua resposta sobre a dúvida levantada.
> Fiquei muito curioso sobre.
>
> Você já fez isso sobre Palo Alto, Fortinet ou Checkpoint? Só citei os
> maiores de mercado.
> Se sim poderia comentar mais sobre?
> Nesse cenário também já usou SD-Wan?
>
> Não seria um único ponto de falha em caso de um ddos? Ter as duas funções
> na mesma caixa.
> Penso isso por causa da estabilidade do BGP.
> Se precisar reiniciar uma caixa vai o firewall e o bgp junto.
> Até as sessões subirem na outra caixa e as rotas serem recebidas vai
> demorar algum tempo.
> Estando em caixas separadas (bgp e firewall) pelo menos tenho a
> estabilidade do BGP.
>
> A ideia aqui é aprender por isso mandei as perguntas.
> </email_privado>
>
>
> Sim, já fiz! E certamente outros colegas aqui nessa missiva também já
> fizeram.
>
> Fiz com Cisco(ainda no saudoso ASA), com Fortinet, com Juniper(inclusive
> para um pequeno ISP), e também com Checkpoint.
>
> Sobre o ponto único de falha
> ------------------------
> Se tiver apenas 1 BGP e apenas 1 Firewall, não se tem dois pontos únicos
> de falha em série?
> A sugestão é unificar as funcionalidades na mesma camada física, mas
> duplicar (alta disponibilidade) as caixas dessa camada física.
> Em dinheiros, isso fica bem parecido.
>
> Vale ressaltar que isso provavelmente não fica financeiramente viável para
> ISPs, pois os volumes de tráfego são muito altos e tornariam as caixas
> muito altas.
> Mas para um Corporativo/Enterprise é muito interessante.
> Usei muito em Universidades.
>
> Sobre o SD-WAN
> ------------------
> É importante não misturar isso com o BORDER-BGP. São coisas diferentes!
> Num desenho bem-feito, a funcionalidade de BORDER-BGP vai estar separada
> do firewall, e aquela virtual interface que vai do Firewall pro BORDER-BGP
> vai ser apenas mais um provedor de rota default para a funcionalidade de
> Firewall.
> Se for adicionar um outro link de Internet que não seja Trânsito BGP (um
> dos baratinhos), é abaixo do container de BGP e acima do Firewall que isso
> vai entrar...
> E nisso, quem vai fazer o SD-WAN vai ser o container que faz a
> funcionalidade de Firewall.
> Também já usei isso muito em Universidades, e em 2 instituições bancárias.
>
> Sobre o DDoS.
> ------------------
> Que tipo de DDoS estamos falando?
> - Se for um volumétrico, não importa se vai ser Firewall ou Router, ou
> qualquer outra coisa...
> Certamente o que vai saturar vai(ão) ser o(s) link(s) que vem do(s)
> fornecedor(es) de trânsito.
> - Se for um DDoS de aplicação, aí entra a capacidade de Deep Inspection,
> Web Application Firewall, e etc...
> Imagino que sua preocupação seja mais:
> "A funcionalidade de Firewall ser comprometida se a caixa estiver saturada
> quando um ataque DDoS estiver chegando na parte BGP?"
> Aí depende! Se for uma solução exclusivamente Software Based, e sem as
> reservas de recursos para a funcionalidades específicas, CERTAMENTE VAI DAR
> MERDA.
> (Mikroitikinianos vão chorar...)
> Aí depende! Se for uma solução exclusivamente Software Based, onde existe
> uma parte Hardware-Based, e affinity (ou cgroups) para o controle dos
> hardwares based...
> (Checkpoint, acho que é um exemplo que cabe aqui... Mas os BareMetal da
> A10 também, e muitos outros.)
> E a parte de configuração não tiver nenhuma gambiarra porca... É bem
> provável que a funcionalidade de Border-BGP se cague todo, mas o firewall
> em si siga funcionando.
>
> Sobre reiniciar uma caixa
> ------------------------------
> Antes de mais nada, a pergunta de advogado do diabo:
> E se fosse uma caixa de BORDER-BGP em série com uma caixa de Firewall?
> Como seria o impacto disso para os serviços internos?
> Sendo duas caixas físicas em paralelo, e sendo um cenário de H.A. bem
> desenhado para que isso seja possível, você pode sim jogar as funções que
> estão ativas duma caixa para a outra e reiniciar a primeira (para atualizar
> por exemplo), sem perder conectividade.
>
>
> Em ter., 7 de jun. de 2022 às 18:03, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
>> Pelo jeito não trata-se de Internet Service Provider, certo?
>> Provavelmente Corporativo com altos níveis de criticidade na operação,
>> confere?
>>
>> Se for isso mesmo, quase que certamente não vai precisa de mais de 10-20
>> Gbps nos próximos 5 anos nesse cenário...
>>
>> VAI DE FIREWALL de alta performance!
>> Algum firewall que esteja com especificação de segurar a bronca de 10
>> Gbps com pacotes de 56 bytes com todas as inspeções ativadas...
>> (Firewall que tem especificação de 10Gbps mas que não conta que é medido
>> com pacotes de 1500Bytes é coisa de gente meias verdades)
>>
>> Algum Firewall que tenha suporte a
>> Container/VirtualSystem/LogicalSystem/VDom/Context ou o nome equivalente
>> nesse fabricante.
>> (Aí você deixa um Container de cara pro BGP com pouca filtragem, e outro
>> Container cuidando das LANs)
>>
>> Algum Firewall que já inclua por 5 anos subscrição de serviços e
>> atualizações.
>> (Assim você evita a masturbação mental de ficar lutando contra mudanças
>> que mudam todos os dias na internet e configuração malucas.)
>> (Não, OpenDNS e similares não vai fazer a mesma coisa que esse tipo de
>> firewall de inspeção profunda e Next Generation.)
>>
>>
>> Se for isso mesmo que mencionei(corporativo e não ISP), provavelmente
>> terá a camada do BGP e a camada do Firewall.
>> Concentrando o dinheiro gastos nas duas camadas, você usa a(s) mesma(s)
>> caixa(s) pra fazer as duas coisas, e separa isso logicamente na(s) caixa(s).
>> Derrepente, ao invés de 1(um) BGP e 1(um) Firewall, com o mesmo dinheiro
>> você coloca duas caixas e H.A.
>>
>> Mas não esqueça de olhar BEM certinho as especificações de memória, FIB,
>> RIB, regras, capacidade de inspeção, e etc...
>>
>> Em ter., 7 de jun. de 2022 às 17:44, André Luiz Honório de Jesus via gter
>> <gter at eng.registro.br> escreveu:
>>
>>> Boa tarde,
>>> Eu tenho um AS e dois links de 200MB e gostaria de uma sugestão de marca
>>> e modelo de roteadores.
>>> Os recursos que eu gostaria são: BGP parcial, balanceamento de link e HA.
>>>
>>> André Luiz Honório de Jesus
>>> Tecnologia da Informação
>>> CSC - Grupo Curimbaba
>>> Tel. +55 (35) 3729-7768
>>> www.grupocurimbaba.com.br<
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhes32-ctp.trendmicro.com%2Fwis%2Fclicktime%2Fv1%2Fquery%3Furl%3Dhttp%253a%252f%252fwww.grupocurimbaba.com.br%26umid%3D0c78b6a7-10ef-49e2-81b4-2d1c1c026768%26auth%3D8e1fed64e64e7af70ebad5570aaead8306c9a97c-5161f642f8efd7900c85fa42e2741e11be3a1b82&data=04%7C01%7Candre.jesus%40grupocurimbaba.com.br%7C8a7f73793d2e440a8e3208d95065e0e6%7C6c8a4580118a449bb1998ca7aaafe1d1%7C0%7C0%7C637629220792831147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bMnNtckhoRxCmQ57Zr8d5mgQ2wnggek3ICt4bXbCmvI%3D&reserved=0
>>> >
>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação