PfSense aguenta o Tranco?
-
Só corrigindo, por padrão o pfsense aplica um BLOCK e não um REJECT.
block drop in log inet all label "Default deny rule IPv4"
att,
Bruno Pinheiro
Olá!
Verdade, editei minha postagem. Verifiquei nos Logs e a ação é Block.
-
Os ataques que recebo são UDP flood e as vezes Ip Spoofing
Hoje, no próprio dedicado dos jogos, tem o CSF rodando…. ele segura bem os ataques... porém quando estou sendo atacado, pega MUITO processamento e da lag....
O Jogos são Counter Strike, MineCraft, Team Fortress 2, Left 4 Dead.
E em todos os casos, preciso deixar tanto o UDP quanto o TCP abertos na mesma porta.
Exemplo: Abro um server de Counter Strike... na porta 27015, preciso deixar tanto TCP quanto UDP liberados!!!A Banda é Fibra, mas não é dedicada... Tenho 200 Mb Down e 100 Upload... quando não tem ataque, o que é raro, ela aguenta na boa.
A fonte é Thermaltake de 500W reais!LFCavalcanti, muito obrigado pelas dicas, alias… à todos.... você acha que compensa investir em um maquina mais nova?? E vc acha que mesmo com uma maquina mais "parruda", o PfSense segura esses ataques???
Pq assim... ataques de IP´s domésticos... nem faz cocegas... porém o cara vai e aluga um VPS nos EUA de 15,00 e tem 100 Mb de Upload... esse ja começa a fazer efeito... o CSF bloqueia... mas ja se percebe leves "travadas".Ai eu pegaria uma placa simples..... onboard... colocaria uma placa boa dessas de rede (Intel) com dual Lan... dessas que vc aconselhou.... Com uns 08 Gb de ram...
Mas meu medo é gastar e o PfSense não fazer o que promete.Regras... faço pouquíssimas... não chega a 10... basicamente faço NAT com Limite de conexões...
No meu caso, o Snort é necessário ?? Pq sinceramente, não entendo praticamente NADA dele.Essa placa seria boa?? http://produto.mercadolivre.com.br/MLB-570930777-placa-de-rede-intel-pro1000-pci-e-101001000-dual-port-_JM
Demonstração do log na hora do ataque
Abraços e obrigado
-
Olá!
Vamos entender o seguinte, a variação de latência vai ocorrer, não importa se você colocar um Juniper na tua rede, se o ataque for bem organizado eventualmente vai comprometer a latência dos teus servidores.
A questão do DDoS via spoofing é mais técnica, vou te passar dois links que achei interessantes, de uma lida neles e pesquise, esse tipo de coisa é complicado explicar e você pode acabar perdendo muito tempo esperando respostas num fórum, na internet a muito material a respeito. Enfim, os dois links:
http://rmeijer.home.xs4all.nl/spoofing.html
http://www.wedebugyou.com/2012/11/how-to-prevent-and-mitigate-ddos-part1/Sobre o PFSense, o sistema em si vai aguentar o tranco, tudo depende de você fazer a configuração certa. Feito isso, você no máximo terá a variação de latência que já experimenta hoje.
Outra coisa que você precisa ter em mente é que essa variação de latência também depende dos equipamentos do seu ISP, se o Router deles que é o Gateway do seu modem não der conta, a latência vai aumentar porque haverá Jitter lá.
Pelo que você me falou é um Link comum, não dedicado, então a chance é que você esteja ligado a um setor da rede deles que compartilha recursos e com certeza possui traffic shapping para balancear o trafego. Tenha isso em mente. -
Entendi… muito obrigado pela ajuda....
a placa que postei estaria boa/??
O PfSense tem limite para conexões TCP, mas UDP não tem???
-
Entendi… muito obrigado pela ajuda....
a placa que postei estaria boa/??
O PfSense tem limite para conexões TCP, mas UDP não tem???
A placa que você postou é boa, mas não excelente. A questão é que como é um PC montado, não adianta gastar com uma placa de rede caríssima, o conjunto não vai operar no mesmo nível. Isso não soou muito técnico eu sei, estou pensando mais no custo-beneficio.
Sobre o protocolo UDP, lembre-se que ele é "Stateless" ou seja, não possui uma conexão com correção de erro e etc, o que o PFSense mantém nesse caso é uma tabela com as conexões estabelecidas em camada 3.
Alguém me corrija por favor se a minha explicação sobre o UDP no caso está errada.
-
bOM… o Roteador que uso hoje... eh da propria vivo.,.... caseiro mesmo... e o CSF fica no dedicado, junto com o jogos !!!
De qualquer forma, esse PC não pode ser mais lento que o roteador da vivo neh?!?!?!?
-
kkkkkk
Com toda certeza não, especialmente se for aqueles brancos…
Mas pra você não depender do desempenho dele, é melhor colocar ele em modo Bridge e o IP "valido" ficar na interface WAN do PFSense.
-
MAs eu preciso… pois ele faz o NAT pra mim...
A nova fibra da Vivo, precisa ter VLAN para conectar o PPPOE... e não sei fazer VLAN direto pelo CentOs.
Então uso o roteador da Vivo para conectar e para fazer NAT. -
MAs eu preciso… pois ele faz o NAT pra mim...
A nova fibra da Vivo, precisa ter VLAN para conectar o PPPOE... e não sei fazer VLAN direto pelo CentOs.
Então uso o roteador da Vivo para conectar e para fazer NAT.Olá!
Não, deixe o PFSense fazer o NAT. Se você deixar o seu modem, depois o PFSense fazer outro NAT, vai ter dois pontos afetados com os DDoS e ai a latência vai piorar.
VLAN não é tão complicado, no PFSense tem centenas de tutoriais, só dar uma busca no You Tube. A VLAN vai do modem até o seu PFSense e depois pro servidor já é uma subrede normal, direto na interface LAN até o servidor.
-
Sobre o protocolo UDP, lembre-se que ele é "Stateless" ou seja, não possui uma conexão com correção de erro e etc, o que o PFSense mantém nesse caso é uma tabela com as conexões estabelecidas em camada 3.
Eu não entendi muito bem isso… ele segura flood UDP???
Pq o CSF segura... e como tambem roda em cima do Iptables, deduzo que o PfSense tambem segure.... ou estou errado??
-
O CFS está mais para um IDS/IPS assim como o fail2ban, ambos são simples. Sua função principal é bloquear baseando-se em anomalias de rede ou base de conhecimentos (banco de dados com assinaturas conhecidas). Não sei se é preciso subir um modulo no kernel no caso do CFS, mas o fail2ban cria regras com base nos logs. No caso de um IDS/IPS o snort é mais eficiente que os dois, mas é muito complexo implanta-lo. Geralmente você precisa de um servidor dedicado para isso. Uma configuração muito aberta no snort pode elevar consideravelmente o consumo de recursos de um servidor e derruba-lo (ex: você ativou um grupo de assinaturas que detecta ataques a web-servers, nesse grupo tem assinaturas para IIS, NGINX e Apache, mas no fim das contas seu servidor web roda somente o apache).
O PFsense é um UTM. Seu sistema é baseado no FreeBSD com o kernel personalizado. Utiliza como filtro de pacotes o pf (packet filter - stateless/stateful). Vem por padrão no kernel das distribuições BSD. O iptables é um filtro de pacotes (netfilter - stateless/stateful), é um módulo padrão no kernel das distribuições Linux. Ambos os filtros de pacotes são bons, cada um tem suas particularidades, vantagens e desvantagens. Alguns dizem que para conexões do tipo stateless o iptables é melhor e para conexões do tipo stateful o packet filter se destaca. A utilização de um ou outro vai depender de sua necessidade. As vantagens do PFsense são: um gerenciamento melhor do filtro de pacotes, gerenciamento centralizado de outras soluções de segurança (proxy, snort, pfblock, openvpn, L7, etc…) e o principal, redução de erros humanos na criação de regras no que se refere a segurança e performance. O Pfsense possui uma série de pré definições que garantem um certo nivel de segurança e performance que não seria percebível por muitos administradores de redes. **#**Por padrão o pfsense marca as regras TCP com as flags S/SA (evitando ataques com pacotes inválidos); **#**todas as regras são marcadas com o recurso "quick" (aplica-se imediatamente sem a necessidade de verificar as demais); **#especifica a interface onde ocorre o trafego em todas as regras (isso evita processamento desnecessário na verificação de regras que não pertencem a mesma interface);#**utiliza alias (tables) para agrupamento de IPs ou Redes que enquadram-se na mesma regra (muito, muito bom na questão de performance). No que se trata ao gerenciamento do filtro de pacotes não tem o que discutir, uma série de parametrizações que seriam bem complexas de implantar (gateway, tratamento dos states, aplicação do l7, definições avançadas de conexão RATE LIMIT, integração com pfblock, definição por S.O., etc…).
Não deve-se comparar pfsense e iptables com cfs, fail2ban e snort. Os filtros de pacotes são definidos estaticamente pelo administrador, eles não são dinâmicos como os IDS/IPS.
Só corrigindo nosso colega Luis, o statelles não é o protocolo UDP e sim a forma como você trata o protocolo. Voce pode tratar o protocolo UDP, TCP, ICMP como stateless ou stateful, depende como a aplicação trabalha. Já pensou em ter que fazer uma regra para um usuário da rede acessar o google na porta 80 e outra regra para o google responder a requisição? Você pode garantir a volta sem ter que criar regras adicionais, ai entra o stateful, onde na ida a conexão entra (keep state) na tabela de estado e na volta ele verifica a tabela e detecta que aquela conexão saiu e que por sua vez a volta está garantida. Isso é muito bom, pois evita verificação na tabela de regras. Já o stateless, toda conexão é tratada como nova, então toda vez é preciso passar por verificação de regra. Provavelmente sua aplicação se encaixa mais em stateful, tanto UDP quanto para TCP.
No seu caso que utiliza em média 10 regras, não teria muita diferença entre ambos os filtros. Se você utilizar o pfsense, você poderá combater os ataques de varias formas. O site indicado pelo nosso amigo Luis é muito bom, é tudo o que você precisa: http://www.wedebugyou.com/2012/11/how-to-prevent-and-mitigate-ddos-part1/
De inicio recomendo você analisar a origem dos seus usuários, ex: são do Brasil, EUA, Europa, Africa... O pfblock é muito bom no que se trata a categorização de blocos IPs por país e continente. Se seus usuários são da Europa e Américas.. ótimo, libere o acesso somente a estes, pois a maioria dos ataques originam-se da China, Russia, (Asia).
Depois analise as conexões de sua aplicação, tente encontrar um padrão. Ex: 3 entradas na tabela de estado por IP de origem (UDP e TCP), 4 conexões por segundo (TCP). Feito isso, configure o RATE LIMITE nas regras. Geralmente é visível a anomalia nos acessos, sendo assim é possível mensurar um numero. Lembrando que você deve liberar somente as portas listadas no seu servidor, tanto UDP quanto TCP. Um erro muito comum dos administradores é fazer uma unica regra liberando porta 4999 e 2000 UDP e TCP, sendo que a porta 4999 é UDP e a porta 2000 é TCP, note que são necessário duas regras em vez de uma. Se um atacante tentar um UDP flood na porta 2000, ele pode usar ao máximo o throughput do pf e derrubar seu servidor de aplicação, onde poderia ter sido bloqueado de primeira. Por isso "cada regra no seu quadrado".
Evite utilizar reject nas regras de bloqueio, sempre que possível utilize block. Nas conexões que exigem mais rapidez, adicione as regras de liberação em floating marcando a opção "quick". Utilize alias na medida do possível.
Segurar os ataques no firewall não vai garantir que a aplicação fique de pé. Já tive casos de inundação UDP que derrubaram o meu link. Nesse caso a minha solução foi abrir chamados para o provedor :D … No meu caso, o meu provedor tinha um equipamento que mitigava ataques DDOS, PEAKFLOW (http://www.arbornetworks.com/products/peakflow/tms). Tente entrar em contato com seu provedor, pois esse tipo de ataque, as vezes não tem como você evitar. Pensando pelo lado da operadora (sendo otimista) o provedor quer que você tenha um link de alta qualidade.
Por favor, corrijam-me caso encontre algum erro. Obrigado.
Qualquer duvida estamos aqui, abraços.
Att,
Bruno Pinheiro.
-
Bruno Pinheiro, ótima explicação e obrigado por compartilhar o link, muito bom conteúdo.
-
Nossa Bruno, quem me dera ter este conhecimento….Fico muito agradecido.
Então... as vezes, eu mesmo ataco meu server... alugo um VPS qualquer nos EUA, e inundo de pacote UDP.... O CSF segura.... e pelo jeito o PfSense também... porém como vc mesmo disse, usar o SNORT não é para qualquer um (eu).
Nao posso usar o pfBlock, pois recebo conexões dos EUA, e de lá vem a maioria dos Ataques... alias, até posso usar para deixar só EUA, BRA, ARG, CHI, que são os que realmente preciso, bloqueando todo o resto.
Mas pelo que entendi, esse jeito de bloquear o Flood UDP, é só com SNORT mesmo neh!?!?!?
-
Ainda é pouco, quero mais e mais.. rs. Mas é uma questão de tempo para todos nós (alguns começam mais cedo), se for dedicado e determinado, o céu será o limite.
Bom, depende do ataque. Utilizando o T50 (disponivel nas distribuições backtrack e kalalinux) (desenvolvido pelo brasileiro Nelson Brito https://twitter.com/nbrito), é possível simular vários endereços de origem. Se você for capaz de detectar a anomalia e identificar um padrão, não é preciso o uso de um sistema IDS/IPS (que recomendo muito dependendo do nível de disponibilidade de sua aplicação).
Faça assim, identifique o endereço IP de um cliente que esteja utilizando todos os recursos de seu servidor (real-time). Feito isso execute o seguinte comando no terminal:
pfctl -ss | grep [color]lagg1_vlan135[/color] | grep udp | grep MULTIPLE | grep [color]8.8.8.8[/color] | grep '' -c
Substitua os valores no comando:
lagg1_vlan135 por sua inteface wan
8.8.8.8 por o endereço IP do usuário em questãoA saída será o numero de linhas que representa o numero de entradas de endereço único na tabela de estado.
Com esse valor, navegue até a regra que concede acesso UDP à aplicação, e em "Advanced features > Advanced Options > Maximum number of unique source hosts" adicione esse numero acrescido uma margem de 50% (ex: se o resulta foi 10, adicione 15). Salve a regra e aplique. Feito isso, simule o ataque novamente e verifique se está sendo bloqueado no pfsense através do seguinte comando:
tcpdump -n -e -ttt -i pflog0 |grep [color]ip_da_vps[/color]
Pode fazer esse teste contando as entradas do IP do atacante pra ver se tem muita diferença entre uma conexão saudável e uma conexão pobre (do atacante)
Pode fazer isso para as conexões TCP também.
Falei isso tudo e até agora não sei se você instalou o pfsense, caso não, veja como verificar a tabela de estado do seu firewall.
att,
Bruno Pinheiro.
-
Olá!
Não vou puxar citação, mas Bruno Pinheiro, obrigado pelas explicações bem elaboradas.
Quando eu falei do "stateless" é que não há etapas de verificação como no TCP, então é mais difícil mitigar esse tipo de ataque. A verdade é que você deu uma resposta muito mais completa para o colega.
Recomendo trocar o título desse tópico para "Como lidar com ataques DDoS UDP Spoofing no PFSense" e pedir para o Marcelloc adicionar aos tutoriais.