[GTER] Melhor pratica para firewall de borda

Sávio Marques savio.marques at sustentatelecom.com.br
Tue Mar 14 13:32:49 -03 2017


+1


Em 14/03/2017 11:33, Paulo Henrique escreveu:
> Primeiro, irá variar do tamanho do seu ambiente e objetivo do mesmo, se
> você é ISP e possui volumetria de trafego exorbitante, > 2mpps e 5Gb/s,
> então precisará trabalhar com varias soluções em paralelo a caixa BGP
> evitando o maximo o consumo de processamento da mesma, Ex:
>
> Intrusão não direcionada a caixa.
> DDoS = coletagem por flow ou port mirror da WAN, tratamento do trafego
> sobre blackhole, aqui vai ter que gastar com hardware e software adicional
> e dependendo da operadora com o serviço de firewall deles, que nada mais é
> do que o suporte a blackhole, que deveria ser obrigadorio para interconexão
> de ASN, mas a maioria das operadoras tupiniquim so liberam sobre
> contratação de serviço a parte.
>
> Intrusão direcionada a caixa.
> Portscanner, Brute force =Ignore, coloca regras em input permitindo o
> acesso a caixa apenas de um range da LAN, de preferencia em um IP não
> roteavel pela internet ( RFC1918 ), a segurança dependerá do trio ( Rede
> Permitida, usuario conhecido e senha ), pode até usar um TACACS ou um
> Radius com dois fatores de autenticação, não precisará se preocupar com
> custo, todas as caixas fazem o basico, para intrusão direcionada exaurir a
> capacidade de processamento de uma RE é quase impraticavel e o custo para
> manter uma tentativa de intrusão direcionada a um router é proibitivo, DDoS
> por exaustão de recursos demanda muito mais processamento de quem está
> originando a intrusão do que pela defesa.
>
> Quanto a rede de servidores, firewall statefull, rede de servidores
> distinta da rede de core, e nat não é segurança para servidores, é dor de
> cabeça, qualquer firewall descente aceita integração com IPS/IDS, use isso
> para tratar trafego originado da sua rede de acesso e gerencia, só aceita
> da internet o que realmente depende da internet o restante é drop from any
> to any que não teve como origem da conexão a sua rede de servidores, uma
> observação, embora é moda colocar tudo sobre virtualização, serviços que se
> requer comunicação aberta tendo como a Internet como origem devem ficar
> separados, lembro de ter lido uma tentativa de intrusão na rede da Apache
> Fundation, exaurir o recursos de alocação de conexão TCP de um httpd/imap
> ou outro serviço com o intuito de gerar DoS sobre a aplicação é facil e
> lidar com esse tipo de DoS é mais complicado.
>
> Se tratando de firewall para lidar com ataques direcionados aos seus
> clientes, Marco civil proibe o tratamento de tal trafego, então não
> interfira ou poderá ter problemas judiciais, a menos que seu contrato
> permite tal interceptação/analise de informação acima do L3.
>
> Para ambientes corporativos, onde a volumetria de dados é baixo ( não
> ultrapassa 1Gb/s de comutação L3 ) então poderá usar firewall
> statefull/bridge com soluções open-source ou mesmo pagas, como o seu
> objetivo é segurança de serviços de TI não será problema justificar um
> investimento de 350 mil reais um um firewall descente como Palo Alto ou
> mesmo o investimento por parte da empresa em uns 5 ou 6 cursos de segurança
> de perímetro usando open-source alem de que por se baixa quantidade de
> informação a contratação de firewall DDoS com o seu transito é mais em
> conta para previnir o DDoS, deixando a caixa BGP lidar com todos os demais
> conexões.
> No duro, seria basicamente as mesmas recomendações para o firewall de
> servidores de um ISP, e a sua rede corporativa de acesso dos usuarios para
> a ser tratada de forma ativa com as mesmas preocupações que a sua rede de
> servidores.
>
> Em ambiente corporativo quanto mais delimita e definido o serviço ou
> alcance do serviço menor será o problema de implantar o firewall, mesmo com
> politica de saida default allow any to any para os usuarios internos, a
> politica de default drop to internet to localnet ainda deve ser mantida.
>
> Não sou especialista de segurança, contudo esse seria o meio de menor custo
> para lidar com tais requerimentos de segurança quanto a filtragem de
> datagramas.
> Evitar filtragem no core no caso do ISP ou limitar filtragem na borda no
> caso de rede corporativa de pequeno médio porte.
> Sou fã de tecnologia opensource, então se tiver hardware sobrando, no duro,
> tenda descolar o custei de cursos em ferramentas como BRO NMS, Snort,
> Suricata, caso o seu ambiente seja corporativo, para ISP ferramentas de
> filtragem não estão ainda no mesmo patamar que as proprietárias,
> principalmente para volumetria de trafego superior a 2mpps, mais por
> questões de desempenho de hardware do que pelo software em si.
>
> Att.
>
> Em 14 de março de 2017 11:40, Leonardo Amaral - Listas <
> listas at leonardoamaral.com.br> escreveu:
>
>> Em 14 de março de 2017 10:52, Luiz Fernando Mizael Meier <
>> lfmmeier at gmail.com
>>> escreveu:
>>> O pior do fastpath é ele simplesmente "bypassar" as suas queues.
>>>
>> Mesmo em borda?
>>
>>
>>
>> [image: --]
>>
>> Leonardo Amaral
>> [image: https://]about.me/leonardo.amaral
>> <https://about.me/leonardo.amaral?promo=email_sig&utm_
>> source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>




More information about the gter mailing list