[1] Comentário enviado por phelipe em 29/08/2007 - 11:34h

Ótimo! Simplesmente ótimo... parabéns! :-)

0 0

[2] Comentá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.

0 0

[3] Comentário enviado por andersonjackson em 29/08/2007 - 11:59h

Isso que é artigo :D

Parabens +Favoritos

0 0

[4] Comentá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

0 0

[5] Comentá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.

0 0

[6] Comentá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.

0 0

[7] Comentá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!!!

0 0

[8] Comentá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.

0 0

[9] Comentá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!

0 0

[10] Comentário enviado por Ed_slacker em 29/08/2007 - 17:11h

Apenas uma palavra para resumir este artigo:

SEN-SA-CIO-NAAAAAAAAAAAAAAAAALLLLLL!!!!!!!

0 0

[11] Comentá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

0 0

[12] Comentá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.

0 0

[13] Comentário enviado por DondaJr em 29/08/2007 - 21:42h

Kra.. parabens.. aprendi sobre o Syn Flood como nunca.. naum sabia q era assim

0 0

[14] Comentá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

0 0

[15] Comentá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

0 0

[16] Comentá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.

1 0

[17] Comentá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

0 0

[18] Comentário enviado por ekklesiah em 30/08/2007 - 11:48h

quero instalar programas no ubuntu sou novo na area

0 0

[19] Comentário enviado por marcrock em 31/08/2007 - 16:33h

Artigo maravilhoso!!!!!

Mais claro que isso impossível!!!!

Parabéns.

Até +!!!!!

0 0

[20] Comentário enviado por gersonraymond em 02/09/2007 - 08:20h

Extremamente genial este artigo, parabéns pelo refinamento técnico e qualidade extraordinária.

0 0

[21] Comentá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.

0 0

[22] Comentá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.

0 0

[23] Comentá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!!!

0 0

[24] Comentário enviado por Pinguim Gigante em 08/02/2008 - 19:16h

Caraca Maluco!!!

[O.O]

Esse cara é bom!

0 0

[25] Comentário enviado por jpgribeiro em 19/02/2008 - 12:39h

Excelente, simples e objetivo, adorei!!!

0 0

[26] Comentá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.

0 0

[27] Comentá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!!

0 0

[28] Comentá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.

0 0

[29] Comentá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.

0 0

[30] Comentá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.

0 0

[31] Comentá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.

0 0

[32] Comentá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.

0 0

[33] Comentá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.

0 0

[34] Comentá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.

0 0

[35] Comentá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...

0 0

[36] Comentá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.

0 0

[37] Comentá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

0 0

[38] Comentá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.

1 0

[39] Comentá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.

0 0

[40] Comentário enviado por alexandre_mpm em 31/03/2008 - 10:39h

Valeu elgio

Muito obrigado!!!

0 0

[41] Comentá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:

iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j DROP
iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j LOG

(-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

E insira com REJECT:
iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j REJECT
iptables -I 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?)

1 0

[42] Comentá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

São elas:

http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html#ss3.1
Howto do netfilter, onde mostra os caminhos de um pacote.

http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Tutorial do iptables. Destaque para a introdução sobre redes. Legal que ele inclusive descreve o novo protocolo SCTP, uma evolução do TCP, digamos assim.

ftp://ftp.registro.br/pub/gts/gts0103/gts-2003-artur_jarbas-iptables.pdf
Slides sobre o netfilter, muito completo, embora desatualizado (já se passaram 4 anos e muitos novos módulos do iptables foram amadurecidos ou construidos)

0 0

[43] Comentário enviado por alexandre_mpm em 31/03/2008 - 11:39h

Muito obrigado elgio

Esse artigo eu li quando saiu do forno
Estrutura do Iptables
http://www.vivaolinux.com.br/artigos/verArtigo.php...

Estrutura do IPTables 2: a tabela nat
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834

e está também no meus favoritos!!!

0 0

[44] Comentá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.

0 0

[45] Comentário enviado por removido em 06/04/2008 - 21:52h

Excente artigo!

Slackmaster ( jlgomessouza@hotmail.com)

http://dangercode.awardspace.com

0 0

[46] Comentá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 'idiota' :)

Enfatizo novamente: O artigo ficou MUITO bom!!!! Show de bola mesmo!!!

0 0

[47] Comentá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:

http://rfc-editor.org/rfc/rfc4987.txt

1 0

[48] Comentário enviado por fsoaress76 em 13/06/2008 - 13:08h

muito bom esse artigo, nao sabia disso não.

nota:10!

0 0

[49] Comentário enviado por elgio em 13/06/2008 - 13:46h

Fiz uma palestra sobre Negação de serviços no evento TcheLinux. A mesma pode ser BAIXADA no endereço http://gravatai.ulbra.tche.br/tchelinux2008

0 0

[50] Comentá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.

0 0

[51] Comentário enviado por walterti em 02/07/2009 - 12:10h

Ótimo artigo!
Simplesmente perfeito

0 0

[52] Comentá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!

0 0

[53] Comentário enviado por magnolinux em 16/11/2009 - 11:21h

Elgio muito bom...

sempre surpreendendo com seus artigos ...

0 0

[54] Comentário enviado por gregorye em 18/02/2010 - 14:51h

Muito Bom mesmo!

0 0

[55] Comentá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 !!!

0 0

[56] Comentário enviado por mxfera em 21/04/2010 - 14:44h

Muito bom seu artigo amigo, me ajudou muito vlw mesmo..

0 0

[57] Comentá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.

1 0

[58] Comentá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

0 0

[59] Comentá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

0 0

[60] Comentário enviado por cpaynes em 14/11/2010 - 13:54h

Muito bom.
Nota 10!

0 0

[61] Comentá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!

0 0

[62] Comentá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.

0 0

[63] Comentá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

0 0

[64] Comentá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

0 0

[65] Comentá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

0 0