Uma das técnicas de negação de serviço mais conhecidas é a técnica de Syn Flood. Mas se encontra em diversos lugares "receitas" e regrinhas iptables para se defender dela. Funciona? É eficaz? Se não é, qual é realmente a defesa necessária?
Não conseguimos carregar os anúncios.Se usa bloqueador, considere liberar o Viva o Linux para nos patrocinar.
Parte 5: Solução FURADA 1: bloquear o IP do atacante
Alguém pode rapidamente pensar: posso simplesmente bloquear o número IP de quem está me atacando e pronto.
Isto não funciona porque o ataque de SYN flood só tem efetivo sucesso se o atacante realizar Ip spoofing de seus pacotes, falsificando o número Ip em cada novo SYN. Isto é desejável até para não atolar o próprio atacante: ele teria que tratar os SYN/ACKs que recebe!
Assim, a cada novo pacote de SYN ele inventa um IP qualquer e o SYN/ACK será devolvido para este IP inventado, que nada sabe a respeito. Qual IP irei bloquear se a cada nova requisição ele muda?
Tem ferramentas prontas que fazem isto, como o hping!
Como mencionado na introdução, por vezes pode ser que uma única máquina (a do atacante) não consiga gerar tantos SYNs até por questões de limite de banda. Mas se ele tem centenas de máquinas "escravinhas" ao comando dele, um ataque de Syn Flood distribuído é o pior cenário que um administrador de rede pode sofrer e não adianta ele ir brincando de bloquear números ips.
#1Comentário enviado por phelipe em 29/08/2007 - 11:34h
Ótimo! Simplesmente ótimo... parabéns! :-)
#2Comentário enviado por juninho (RH.com) em 29/08/2007 - 11:40h
Elgio,
que beleza, nunca imaginei que funcionasse desta forma, e muito menos que não estaria protegido apenas com a regra básica do iptables.
Parabéns, tenho certeza que será de bom proveito para muitos, como foi para mim.
#3Comentário enviado por andersonjackson em 29/08/2007 - 11:59h
Isso que é artigo :D
Parabens +Favoritos
#4Comentário enviado por zilli em 29/08/2007 - 12:01h
Parabéns .... show de bola.
Só fico imaginando como que deve ser o seu script de firewall :-)
Coisa de outro mundo !!!
Abraços,
Daniel
#5Comentário enviado por removido em 29/08/2007 - 12:05h
Essas opções do kernel são muito boas, a muitas mais opções como essas que facilitam a vida de muita gente, é so estudar.
Està de parabéns pelo artigo.
#6Comentário enviado por TSM em 29/08/2007 - 13:11h
Cara, realmente você tem razão, e o seu artigo é de qualidade, só em ler ele eu já faço idéia do conhecimento que você tem, valeu pelo artigo.
Já esta em meus favoritos.
Abraços.
#7Comentário enviado por removido em 29/08/2007 - 13:47h
Pois é. botando as caraminholas para funcionar a gente vai muito mais longe do que pensa!!!
#8Comentário enviado por engos em 29/08/2007 - 15:42h
Muito bom o artigo.
Acabo de mudar de emprego para atuar com segurança da informação e o artigo ajudou bastante a me atualizar e me relembrar de alguns detlhes técnicos do TCP/IP.
Me ajudou bastante!
Abraços.
#9Comentário enviado por capitainkurn em 29/08/2007 - 15:52h
Estou gostando muito de sua série de artigos acerca do Iptables. Muito bem redigidos e ditáticos.
Parabéns Elgio!
#10Comentário enviado por Ed_slacker em 29/08/2007 - 17:11h
Apenas uma palavra para resumir este artigo:
SEN-SA-CIO-NAAAAAAAAAAAAAAAAALLLLLL!!!!!!!
#11Comentário enviado por demattos em 29/08/2007 - 20:21h
sem palavras, nunca vi de forma clara como funciona o iptables como vc transmite por seus artigos
parabens
#12Comentário enviado por davis.peixoto em 29/08/2007 - 21:08h
Elcio, parabéns.
Há tempos que não lia um artigo tão didático e interessante.
Muito obrigado por me tirar do marasmo. Já foi pro meu favoritos.
#13Comentário enviado por DondaJr em 29/08/2007 - 21:42h
Kra.. parabens.. aprendi sobre o Syn Flood como nunca.. naum sabia q era assim
#14Comentário enviado por m4sk4r4 em 29/08/2007 - 22:52h
Realmente fantástico.
Lendo o tópico sobre Syn Flood, lembrei quando estava estudando sobre NAT Through(NAT TRAVERSAL, Hole Punch).
Não tive sucesso na época, me deu vontade agora de retomar os estudos, você teria algum material ou conehcimento sobre essa técnica.
Abraço
#15Comentário enviado por Bique em 30/08/2007 - 05:05h
Sensacional este artigo, a explicação não poderia ser melhor: tudo ao mais pequeno detalhe.
Parabéns
#16Comentário enviado por elgio em 30/08/2007 - 09:21h
COMO USAR O HPING?
Me perguntaram...
O hping3 faz tudo isto, tanto o Ip spoofing como o flood. Para testar você pode com sergunça ver em SEU SERVIDOR o efeito. Deixe um tcpump ligado no servidor para ver os ips falsos gerados:
tcpdump -i eth0 -n port 80
Vou mostrar com o meu mesmo, localhost:
# hping3 --rand-source -p 80 -S localhost
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=80 flags=SA seq=4 win=32792 rtt=0.2 ms
E o que eu peguei no tcpdump:
# tcpdump -i lo -n port 80
09:19:18.358407 IP 12.57.241.164.2098 > 127.0.0.1.80: S 934405501:934405501(0) win 512
09:19:19.359121 IP 197.136.235.76.2099 > 127.0.0.1.80: S 1879392267:1879392267(0) win 512
09:19:20.363153 IP 168.176.134.222.2100 > 127.0.0.1.80: S 1555847962:1555847962(0) win 512
Vejam os ips de origem...
Agora o hping é bem comportado, gera um SYN a cada segundo. Achou ele lento?
# hping3 --flood --rand-source -p 80 -S localhost
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
Fiz isto e meu monitor de rede subiu AO MAXIMO!
Aprecie com moderação.
#17Comentário enviado por removido em 30/08/2007 - 11:27h
excelente! estava esperando um tutorial desta qualidade, pois ja estava irritando o "control c control v" de amadores
#18Comentário enviado por ekklesiah em 30/08/2007 - 11:48h
quero instalar programas no ubuntu sou novo na area
#19Comentário enviado por marcrock em 31/08/2007 - 16:33h
Artigo maravilhoso!!!!!
Mais claro que isso impossível!!!!
Parabéns.
Até +!!!!!
#20Comentário enviado por gersonraymond em 02/09/2007 - 08:20h
Extremamente genial este artigo, parabéns pelo refinamento técnico e qualidade extraordinária.
#21Comentário enviado por removido em 14/10/2007 - 23:22h
realmente, refinamento e qualidade, fazia tempo que eu estava afastado do site devido ao padrao caindo, mas sempre há um bom motivo para voltar.
#22Comentário enviado por cytron em 18/11/2007 - 17:59h
Este artigo é sem dúvidas uma óbra de arte, seria bom sem todos fizessem dessa maneira, a maioria deixa ao menos um item sem explicar pra que serve, sempre dizem: "execute isso", "altere aquilo". Daí você faz um monte de coisas sem saber qual a função, apenas o objetivo final.
Parabéns!!!
(14-04-2008)
Opa!!! Tive que voltar o valor de tcp_syncookies para 0, pois com valor 1 o tráfego na rede ficou muito estranho, tinha hora que um server não encontrava o outro, bastava colocar 0 novamente e tudo voltava ao normal.
Não sei explicar isso e deve ter solução, mas estou sem tempo agora.
#23Comentário enviado por agk em 24/11/2007 - 16:11h
Muito bom, excelente artigo, realmente o autor entende muito bem como funciona o modelo osi e as flags do protocolo tcp.
Também gostei muito dos exemplos do tcpdump, alias, deixo a sugestão para quem conhece e domina bem o tcpdump que faça um artigo detalhando o seu uso, pelo que vejo é uma ferramenta poderosa para análise do tráfego da rede.
No mais só posso dizer que o artigo é 10, parabéns!!!
#24Comentário enviado por Pinguim Gigante em 08/02/2008 - 19:16h
Caraca Maluco!!!
[O.O]
Esse cara é bom!
#25Comentário enviado por jpgribeiro em 19/02/2008 - 12:39h
Excelente, simples e objetivo, adorei!!!
#26Comentário enviado por alexandre_mpm em 28/03/2008 - 17:25h
Boa tarde elgio
Muito bom o seu artigo excelente, com certeza ja está nos favoritos mas eu tenho um dúvida gostaria de sua ajuda para entender, o que eu endendia dessa regra:
# Protege contra os ataques do tipo Syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 10/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP
é que se a conexão não fosse estabelecida dentro de 10 segundos ela seria descartada, sendo assim não alocaria por tanto tempo recursos da máquina, ou seja receberia quantas conexões fossem solicita mas as que não forem estabelecida em 10 segundo era descartada, não é isso?
ahh além do hping3 temos também o netwox, que muiiiiiiiiiiiiiiiiitoo bom tem mais de 220 opções de teste só nele.
#27Comentário enviado por elgio em 28/03/2008 - 18:10h
Pois é alexandre!
o limit é quantos pacotes CASAREM com o syn por segundo, e não conexões estabelecidas.
Contudo, mesmo que fosse conexões estabelecidas, como imaginaste, mesmo assim o iptables não se livraria do Flood. Porque estarias (dentro do que tu imaginou) dando um tempo de 10s para completar o handshake e isto é MUITO TEMPO.
Umas das formas, inclusive, de MINIMAR o ataque é justamente diminuir este tempo nas configurações de cada servidor. Mas NÃO RESOLVE!!
#28Comentário enviado por alexandre_mpm em 29/03/2008 - 15:48h
opá muito obrigado elgio pela atenção mas eu não entendi com conexão estabelecida mas sim a serem estabelecidas, imaginamos o seguinte:
Protege contra os ataques do tipo Syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 2/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP
O cliente envia um pacote com a flag SYN
O server iria receber normalmente, mas se a conexão não fosse estabelecida dentro de 2 segundos essa conexão seria descartada liberando recursos do server.
ah não sei se conhece a ferramenta netwox é muito boa da para realizar diversos testes também mas o hping3 é muito bom também.
#29Comentário enviado por elgio em 29/03/2008 - 16:18h
Mas não é assim que o iptables faz.
Mesmo porque, não entendi o seu raciocício, pois se o servidor recebe o SYN, já está criado o cenário para SYN flood. O que o iptables FARIA depois dos dois segundos? Impediria novos pacotes desta conexão semi-aberta? Mas em um ataque de syn float não haverão novos pacotes desta conexão semi-aberta...
"O server iria receber normalmente, mas se a conexão não fosse estabelecida dentro de 2 segundos essa conexão seria descartada liberando recursos do server."
O iptables no roteador iria enviar um alerta para o server para que ele desaloque recursos??? Veja, aqui é uma questão de firewall de rede, onde ele tem que proteger VÁRIOS SERVIDORES, não firewall de host. Firewall e servidor NÃO SÃO A MESMA MÁQUINA.
E repito: mudar o tempo de espera de uma conexão semi estabelecida se faz configurando os tempos de TCP em /proc.
#30Comentário enviado por agk em 31/03/2008 - 09:05h
Protege contra os ataques do tipo Syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 2/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP
Nesse cenário o que o limit faz é limitar o número de conexões SYN a 2/s, ou seja o que passa de 2 conexões por segundo é descartado.
Usando o hping3 é possível deixar indisponível um servidor usando apenas uma estação.
Um jeito de minimizar isso foi bloqueando os pacotes da rede interna que vem de IPs diferentes da minha faixa de rede local.
Ex:
REDE_LOCAL=192.168.0.0/24
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s ! $REDE_LOCAL -j DROP
Na primeira regra você libera a volta dos pacotes, que obviamente vem com ips diferentes da sua rede local e na segunda regra é descartado sumariamente todo e qualquer pacote que não esteja dentro da faixa de rede local.
Lembre-se também que é muito importante deixar a policy do FORWARD em DROP, para as regras acima funcionarem.
Só que isso somente ainda não resolve, apenas minimiza.
Syn Flood em rede local ainda é um problema.
[ ]'s.
#31Comentário enviado por alexandre_mpm em 31/03/2008 - 09:31h
Iai agk tudo bem
Era exatamente isso que eu estava querendo dizer, o que passa de 2 segundos e que não for estabelecida a conexão é descartado.
Agora achei interessante sua regra, haja vista que um ataque Syn Flood de uma rede local, pode ser de um prejuízo enorme.
#32Comentário enviado por elgio em 31/03/2008 - 09:47h
NÃO É ESTE o comportamento limit!
No caso é somente 2 syn/s independente se for ou não estabelecido. O limit NÃO IMPÕE um tempo para que a conexão seja estabelecida.
Coloque APENAS estas regras no teu firewall:
iptables -A FORWARD -p tcp --syn -m limit --limit 1/minute -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP
(sem mais nada)
e tu verás que só conseguirá enviar syn, início de conexão, no ritmo de 1 por minuto, porém poderá enviar QUANTOS acks quiser (com hping3 por exemplo).
Por isto que SEMPRE em qualquer regra de firewall deve-se deixar passar conexões estabelecidas/relacionadas.
Este outro conjunto de regras, por exemplo, seria um DESASTRE:
iptables -A FORWARD -p tcp -m limit --limit 1/minute -j ACCEPT
iptables -A FORWARD -p tcp -j DROP
(sendo APENAS ELAS)
Agora eu limitei todo e qualquer pacote TCP, sendo syn, ack...
Nem mesmo o handshake será completado (pois ele faz passar TRES pacotes e em menos de 1 minuto).
O limit apenas CONTA QUANTOS, por tempo, e não é um timeout para estabelecer.
Lembrando que APENAS os dois primeiros pacotes do handshake possuem o syn ligado e APENAS O PRIMEIRO (inicio de conexão) possui SYN ligado e ACK desligado. O parâmetro --syn do iptables casa com SYN=1, ACK=0, logo, cada com APENAS o primeiro pacote do handshake.
Desta forma estamos apenas limitando o número de início de conexão TCP a X por segundo ou minuto. Nada a ver com tempo de timeout para que a mesma seja estabelecida.
#33Comentário enviado por elgio em 31/03/2008 - 09:51h
"Era exatamente isso que eu estava querendo dizer, o que passa de 2 segundos e que não for estabelecida a conexão é descartado."
Não é "o que passa de dois segundos". É o que passa de DOIS por segundo.
E apenas QUANTOS e não um tempo para estabelecer.
O limit não mexe no tempo para estabelecimento de uma conexão.
#34Comentário enviado por elgio em 31/03/2008 - 09:55h
E um ataque dentro de uma rede local (SYN FLOOD) pode, ser defendido pela mesma técnica de syn cookie, já que ela é implementada em cada servidor (independe de firewall de rede).
Mas ai já é outra polêmica: um usuário com poder de root em seu micro pode fazer muito mais estrago em uma rede local do que apenas um syn flood! Pode controlar TODA A REDE LOCAL (arp spoofing de gateway, por exemplo).
Ai danou-se por completo!
Por isto que muitas empresas, ou não deixam que seus funcionários entrem com seus notebooks, onde eles serão root (podem usar apenas as máquinas da empresa, sem privilégio) ou criam uma rede seperada para os notebooks, em outra VLAN, com um firewall próprio, enfim.
#35Comentário enviado por elgio em 31/03/2008 - 10:12h
Oi agk!
Sim, uma das primeiras coisas que TODO E QUALQUER firewall de rede deve fazer é o tratamento de ip spoofing!
Quando tu disse rede interna, eu imaginei usuários e servidores EM UMA MESMA REDE. Neste cenário que eu expliquei a teoria do "danou-se".
Colocar servidor e usuários em uma mesma rede já é um baita tiro no pé!
Poxa, hoje com switches 802.1q e Linux tu nem precisa de placas de rede extra para colocar os servidores em uma DMZ e protegê-los até mesmo dos teus "inocentes" usuários... :-D
Na Universidade que administro eu tenho TODOS os servidores em uma rede sozinha (hehehe, no caso TODOS são apenas DOIS!!).
Todos os acessos passam pelo firewall que controla IP spoofing.
Tenho regras do tipo:
iptables -A FORWARD -i PlacaRdInterna -s ! RedeInterna -j REJECT
Sim, REJECT e não DROP, para a máquina já ser chutada com um ICMP na hora. O DROP é útil para ajudar a esconder o IP do firewall (vejam que usei a expressão "ajudar a esconder" e não "esconder"...), pois a máquina DROPADA não recebe um aviso do firewall.
Na rede interna não tem tanto motivo assim para econder algo. Melhor é dar REJECT para que a máquina não fique insistindo...
#36Comentário enviado por alexandre_mpm em 31/03/2008 - 10:16h
Bom dia elgio
Agora sim ficou claro para mim, eu imaginava como timeout, e vc disse que não é valeu com certeza esse "pequeno debate" enrriqueceu ainda mais o que ja está ótimo (artigo), valeu mesmo pela atenção, e por esclarecer essa dúvida que acredito seja a de muita gente.
#37Comentário enviado por alexandre_mpm em 31/03/2008 - 10:25h
rsrs agora só solta a fonte ai de onde tirou tantas informações boas sobre iptables, rsrs
#38Comentário enviado por elgio em 31/03/2008 - 10:33h
A maioria do man iptables
Grandes revelações:
man iptables
(...)
limit
This module matches at a limited rate using a token bucket filter. A
rule using this extension will match until this limit is reached
(unless the ‘!’ flag is used). It can be used in combination with the
LOG target to give limited logging, for example.
--limit rate
Maximum average matching rate: specified as a number, with an
optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the
default is 3/hour.
(...)
E depois, testando em máquinas virtuais para ver o efeito.
#39Comentário enviado por agk em 31/03/2008 - 10:34h
Olá Elgio,
Acho que estamos enriquecendo o assunto, agora ficou mais claro pra mim, vou ter que fazer um teste, mas quando eu estava utilizando DROP na regra para descartar ip spoofing era preciso apenas algumas máquinas a mais para congestionar o firewall, sim, eu tenho uma DMZ também. Agora vou testar com o REJECT para ver se melhora.
Já tentou usar o hping3 em umas 5 máquinas atirando no gateway(firewall) da sua DMZ?
Eu sempre uso DROP, nunca sei exatamente quando devo usar DROP ou REJECT nas regras do IPTABLES, tenho que avaliar melhor isso.
Obrigado.
#40Comentário enviado por alexandre_mpm em 31/03/2008 - 10:39h
Valeu elgio
Muito obrigado!!!
#41Comentário enviado por elgio em 31/03/2008 - 10:44h
Pois é.
Ë que quando tu dá um DROP, a máquina que gerou o pacote não sabe o que aconteceu com ele. Logo ela tenta denovo, e denovo, e denovo... gerando muitos pacotes.
Já um REJECT devolve um icmp tipo 3 (destino inacessível) rapidamente informando a máquina do ocorrido.
Podes fazer um teste se puderes para ver os efeitos. Selecione um destino HTTP como teste e bloqueie ele no firewall:
(-I para entrar PRIMEIRO, antes de regras que já tenha)
Tente acessar de um navegador do teu cliente e observe:
a) a quantidade de logs geradas no teu firewall para o teu IP de teste
b) a demora que teu navegador levou para acusar erro!
Depois remova as regras:
iptables -D FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j DROP
iptables -D FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j LOG
Verás que APENAS um pacote será logado e teu navegador, no cliente, rapidamente acusará erro.
Qual é melhor?
Depende!
REJECT gera menos trafego, mas conta para todo mundo o IP do teu firewall (Porque o firewall avisa "Joguei fora teu pacote").
DROP gera mais trafego e mais logs, até os clientes desistirim, mas CONTRIBUI para esconder o IP do teu firewall (um atacante descobrindo o ip do teu firewall pode fazer um finger print nele e descobrir vulnerabilidades. É FATO que não se deve ter segurança por obscuridade, ou seja, minha rede deve ser SEGURA mesmo que todos saibam os detalhes dela, mas claro que vou esconder o máximo. Pra que facilitar?)
#42Comentário enviado por elgio em 31/03/2008 - 11:05h
Alexandre:
Quando escrevi os dois artigos sobre iptables, mas sem entrar em detalhes statefull, me cobraram referências. Ai eu citei algumas que andei lendo na Internet. Elas estão NÃO NO ARTIGO, mas em um comentário meu postado no artigo: http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834
#44Comentário enviado por elgio em 06/04/2008 - 17:46h
Guia Foca!
Hoje percebi que a "receita de bolo" para a falsa proteção de SYN FLOOD por iptables está publicada no guia Foca avançado. Entrei em contato com o autor para que ele reveja isto.
#45Comentário enviado por removido em 06/04/2008 - 21:52h
#46Comentário enviado por equeiroga em 02/06/2008 - 20:18h
Elgio,
O artigo, realmente, ficou MUITO bom, mas depois de tanto se falar de ataques SYN Flood, acabei ficando um pouco confuso sobre a defesa para este ataque. Minha pergunta é: Basta ativar o "tcp_syncookies" e o problema está resolvido???
Espero não ter sido uma pergunta '[*****]' :)
Enfatizo novamente: O artigo ficou MUITO bom!!!! Show de bola mesmo!!!
#47Comentário enviado por elgio em 03/06/2008 - 15:55h
Em agosto de 2007 (comtemporâneo a este artigo) foi publicada uma RFC sobre SYN Flood e formas de defesa. Muito interessante:
#50Comentário enviado por cytron em 14/06/2008 - 02:14h
Opa!!! Tive que voltar o valor de tcp_syncookies para 0, pois com valor 1 o tráfego na rede ficou muito estranho, tinha hora que um server não encontrava o outro, bastava colocar 0 novamente e tudo voltava ao normal.
Não sei explicar isso e deve ter solução, mas estou sem tempo agora.
#51Comentário enviado por walterti em 02/07/2009 - 12:10h
Ótimo artigo!
Simplesmente perfeito
#52Comentário enviado por murilosilva em 09/07/2009 - 17:00h
Elgio,
Parabéns pelo artigo. Muito bom mesmo, realmente de qualidade.
Só fiquei com uma duvida no final, onde você diz: "O fato é que a imensa maioria preocupa-se em não ser atacado, e raramente se preocupam em não permitir que seus clientes ataquem!"
Qual seria o risco para o provedor em aplicar uma regra que impede o ip spoofing?
Valeu!
#53Comentário enviado por magnolinux em 16/11/2009 - 11:21h
Elgio muito bom...
sempre surpreendendo com seus artigos ...
#54Comentário enviado por gregorye em 18/02/2010 - 14:51h
Muito Bom mesmo!
#55Comentário enviado por guto.rodrigues em 04/03/2010 - 15:11h
amigo !!! seu artigo é perfeito... vc não tem idéia do favor que vc me fez !!!
#56Comentário enviado por mxfera em 21/04/2010 - 14:44h
Muito bom seu artigo amigo, me ajudou muito vlw mesmo..
#57Comentário enviado por hugoalvarez em 29/04/2010 - 11:06h
Mto legal esse artigo, eu nem reclamaria se tivesse mais teoria envolvida pq foi mesmo uma aula.
#58Comentário enviado por fernandoreis em 06/07/2010 - 14:17h
Prezado Elgio,
excelente a sua explicação sobre o SYN FLOOD. Já tinha lido outras explicações mas nenhuma foi tão clara e objetiva como a sua.
Preciso que vc me esclareça uma duvida:
Liguei meu computador caseiro e logo apareceu uma informação do McAfee Host Intrusion Prevention me informando que eu estava sofrendo um ataque de SYN FLOOD e se eu queria bloquear essa ação? Bloqueei é claro mas por umas 5 vezes , durante os dois dias seguintes , apareceu essa mensagem e depois cessou. Como na sua explicação esse ataque é feito contra servidor e eu estava em um cp em casa , o que ocorreu realmente comigo?
abraço
Fernando
#59Comentário enviado por julianderson em 27/09/2010 - 18:15h
Amigao eu sou novo no mundo linux e eu estou precisando montar um firewall, voce poderia me ajudar por favor, pois alguns membros do vol ja mandara eu ter um professor particular, voce poderia me ajudar meu email e dril_jsp@hotmail.com
eigio eu fico muito grato pela ajuda ta ok
caso contrario obrigado
#60Comentário enviado por cpaynes em 14/11/2010 - 13:54h
Muito bom.
Nota 10!
#61Comentário enviado por pedrorawan em 25/02/2011 - 11:48h
Cara!!! Muito bom esse artigo, me ajudou bastante. Já tava quase fazendo uma proteção para Syn Flood no firewall. Muito obrigado !
Mas fica a dica para proximos artigos PAM limits.
Valeu!
#62Comentário enviado por rnduart em 29/04/2011 - 16:02h
Estou começando agora no Linux e estou querendo fazer um iptables faz 3 dias já consigo entender o básico dos comandos paramentos e regras, mas não sabia o que é: syn food, spoofing, etc, que tanto tem nesses iptables de exemplos. Com seu artigo as coisas estão ficando cada vez mais claras.
#63Comentário enviado por cleristonm em 13/03/2012 - 12:35h
Parabéns pelo artigo!
Além de syn flood, ping of death e brute force quais outros tipos de ataques devemos nos preocupar em um script de firewall
#64Comentário enviado por Carlos_Cunha em 05/10/2012 - 13:55h
Parabéns !!!!
artigo muito bem feito e vc soube explicar de uma forma simples e precisa!!
Abraço
#65Comentário enviado por donysilva em 02/10/2015 - 08:34h
Elgio sou novo em iptables
erro no meu iptables uso ipcop será que funciona bem?
Bad argument `192.168.95.0/16'
a placa assinante é meu ip válido ou minha interface de rede com saída pra internet
no caso a placa RED
Parabéns pelo post
Grato
Preferências de cookies
Usamos cookies essenciais para manter o site funcionando. Cookies de estatísticas e anúncios só serão carregados se você permitir.
