PfSense aguenta o Tranco?
-
Olá galera… tenho uma duvida... ja postei um tópico PARECIDO, mas não era bem isso a pergunta.
tenho um servidor de jogos, ligado a uma fibra... gostaria de tirar o Roteador e colocar o PFSENSE.
Minha duvida... ele aguenta essa imensa quantidade de requisições sem perder a qualidade.... sem dar "lag"??
Além do que, recebo muitos Floods.
O CSF aguenta segurar os floods.... porém não sei o PfSense.A Maquina é
Athlon X2 4200+ (2200 Mhz)
3 Gb de ram DDR2
HD SSD SATA 3 de 60 Gb
Placa PCI-E Gigabit (dual Lan)A placa de rede é parecida com essa.
Vocês acham que aguenta?? Pois precisaria fazer Várias regras, proteger de inumeros floods, e permitir MUITAS conexões legitimas…. tem horario, que tem mais de 120 pessoas jogando em meu server.
Obrigado
-
Outra duvida… a placa mãe ja possui 2 placas de rede Gigabit Onboard (Asus A8N-Sli Premium).
Essas placas sera que são melhores, mais rapidas que a PCI-E ?? Eu sei que ambas são Gigabit... mas eu quero dizer a taxa de transferência de dados.
Onboard ou PCI-E? -
Tudo vai depender do hardware e da placa de rede. Qual é o chipset dessa NIC? Já realizou testes?
-
Boa tarde Brupj,
baseando-se na documentação oficial do packet filter no que se refere a questão de performance, levantei os seguintes intens:
- Como o packet filter já vem no kernel dos "BSDs", memória e processamento não deve ser levado TANTO em consideração;
- As placas de rede são o principal influenciador de performance;
- As complexidades das regras influenciam muito;
Conclusão:
- Como disse o colega neo_X, verifique a qualidade do chipeset;
- Verifique se cada porta de rede possui seu próprio chip ou um chip é compartilhado para as duas portas;
- O máximo possível, utilize alias (tables) em vez de varias regras com o mesmo destino ou origem (o packet filter bate muito nessa tecla no que se refere a performance);
- Se possui varias regras e dentre estas, alguma deve ser aplicada antes de outras, adicione essa regra em "Firewall > Rules > Floating". Marcar a opção Quick *****.
Outra sugestão é a marcação de pacote com qos, isso é muito útil (dependo do seu cenário). Espero ter clareado suas idéias.
grande abraço.
Att,
Bruno Pinheiro
-
Note que a imagem postada da placa de rede possui dois chips atrás de cada porta. Quando trata-se de placa on-board, geralmente vem um chip para duas portas de rede.
Tenho um pfsense com mais de 30mil conexões simultâneas e mais de 900 regras de firewall sem contar as regras de NAT.
Com serviços de criticidade baixa, média e alta.
att,
Bruno Pinheiro.
-
Tenho um pfsense com mais de 30mil conexões simultâneas e mais de 900 regras de firewall sem contar as regras de NAT.
Bruno, se puder passar informações de hardware, consumo de memória, processamento seria interessante.
Estou começando agora com o PFSense e isso nos ajuda a dimensionar as instaçaões.
Obrigado. -
Dell PowerEdge R610 com 8GB de memória RAM.
Estou mandando em anexo a utilização de recursos das ultimas 8 horas.
No cenário desse cliente é um servidor dedicado para firewall e outro para proxy. Estou adicionando mais um servidor em breve, para fazer um firewall somente Interno e outro Externo. Nesse firewall atual possui 34 Vlans.
O que pesa mesmo é o proxy, por isso separei.
abraços.
Att,
Bruno Pinheiro
-
O consumo de memória dar-se pelo recurso do pfblocker e snort. O pfsense com seus recursos nativos, consumiria menos.
-
Interessante, obrigado.
-
Referente ao hardware onde será instalado o pfSense, creio que não terá problema. A maior preocupação são as NICs. Já tive problemas com NICs realtek, substitui por broadcom e intel e nunca mais tive problema.
Se puder adquirir nics desses fabricantes será um ótimo investimento.
-
Desculpem a demora para responder…
A placa mãe (Asus que citei) pelo que vi, possui um chipset para cada placa Onboard...
Pelo menos foi o que entendi !! Quem manja mais... como testo para ver se realmente são boas em transferência de dados, latência e tals???Outra coisa... compensa mais em questão de velocidade, SSD ou Memory Card ?? Lembrando que recebo MUITOS ataques e preciso de velocidade... Internamente só terei 2 servidores... mas as conexões externas são MUITAs
-
Para testes recomendo o iperf. Com ele é possível teste de carga, parametrizando protocolos como UDP, TCP, tamanho dos pacotes entre outros avançados. Alem da velocidade ele traz o jitter. Para o windows tem uma versão em java "jperf". Ele é simples, voce precisa iniciar uma instância no servidor e no cliente apontar para este.
No que se refere a ataques, voce precisa identificar os tipos de ataques e a origem. Se seu servidor prove o serviço para o Brasil somente, utilize o pfblocker para bloquear trafego estrangeiro (alem disso, trafego de redes nivel1, nivel2, nivel 3, redes de hackers conhecidos, redes Zeus, spyware.. etc). No tipo de ataque voce pode verificar se é dos ou ddos, se for tcp e voce pode limitar em !Firewall > rules > Advanced features > Advanced Options" numero de conexoes por segundo, entradas na tabela de estado, conexões por host entre outros.
Se não for possível identificar esses ataques, recomendo implantar o snort ou o suricata. Mas não é simples assim, primeiro voce precisa identificar os tipos de ataques, pois uma regra mal configurada pode interferir muito na performance.
Na questão do disco, não vejo uma considerável importância para o seu cenário, pois não vai ter muita escrita e leitura. Se tivesse um serviço de cache (dns ou proxy) faria muita diferença.
att,
Bruno Pinheiro
-
Olá!
Primeiro, você quer uma resposta precisa sem fornecer dados importantes:
1 - Qual a banda dessa conexão de Fibra?
2 - É conexão dedicada?
3 - Qual jogo você vai hospedar? Isso pode influenciar na lógica do teu Firewall.Eu tenho servidores PFSense segurando 90 usuários de uma rede em duas conexões, servindo VPN com outros pontos, com Squid+SquidGuard, Samba com Winbind, SNORT, duas conexões de 30Mpps tudo sem afetar a latência.
O hardware que você passou, em termos de desempenho é suficiente para segurar muitos usuários(veja minhas observações abaixo), desde que não haja defeito no mesmo. Porém, o principal fator ai é a placa de rede. Compre uma Intel ou pelo menos uma Broadcom. Nada de Realtek, Marwell, Atheros…
Como já citado, a lógica das regras influenciam muito no desempenho. Use Aliases e deixe as regras o mais objetivas e sucintas possível. Por exemplo, o PFSense por padrão aplica BLOCK a qualquer pacote que não tenha uma regra de firewall especificamente permitindo o trafego. Isso já elimina várias regras.
Acredito que você tenha criado um tópico sobre o uso de HD SSD um tempo atrás. Enfim, no seu cenário não vejo necessidade do uso de SSD, a não ser que você vá implementar o VARNISH ou algum tipo de Cache no PFSense. O SSD te propiciará melhor desempenho de inicialização, mas não em filtragem de pacotes. Tanto o firewall do PFSense, quanto o SNORT, trabalham com a memória RAM direto, justamente por questão de desempenho. Logo sairá mais barato e você terá uma vida útil maior do seu servidor utilizando um HD comum, "mecânico".
Eu investiria um pouco em memória RAM. 3GB poderiam se tornar 4GB. Importante ai implementar o PFSense 64 Bits e se ater ao barramento das memórias. Mantenha a paridade delas, todas com o mesmo barramento, melhor 800MHz. Confira se a sua placa mãe trabalha nos Slots da RAM nessa frequência.
A fonte de alimentação. Nada de fonte Coletek, MyMAX ou outra dessas genéricas. Abra o bolso e compre uma Termaltek, Corsair ou outra marca de sua preferência, mas que seja uma fonte de qualidade e com boa taxa de eficiência. E quando falo isso, não é uma fonte de 800W, é uma fonte de 400W que te entregue 400W, seja chaveada, possua correção de ruido e estabilização corretas.
No seu ambiente, pense na energia, você está saindo de um Roteador, com memória EPRON ou algo parecido, onde desligar e ligar não vai corromper o sistema. No PFSense, se a energia cair de repente você pode dar o azar de corromper algum arquivo importante e ter que formatar o PFSense. Então coloque um NoBreak nele, de boa qualidade, modelos voltados para ambiente SOHO no mínimo. Aterramento correto da tomada é outra coisa importante!
-
Muito boa as sugestões do Luiz.
. o PFSense por padrão aplica REJECT a qualquer pacote que não tenha uma regra de firewall especificamente permitindo o trafego.
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
-
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.