[FUG-BR] ***SPAM*** Re: ***SPAM*** Re: ***SPAM*** Re: Traduzir regra do TCPDUMP para o IPFW

[Marcelo Gondim]

Em 05/04/2012 18:28, Marco Aurélio V. da Silva escreveu:
> Caro Marcelo,
>
> O 111.111.111.111 é o servidor de dns e correio, e o 222.222.222.222 é a
> maquina de monitoramento.

Opa Marco. Já checou se o ataque está vindo do seu servidor 
111.111.111.111 ou se está sendo spoofado? Se está sendo spoofado  você 
tem algum Firewall  antes de chegar nos seus servidores ou eles estão de 
cara pra Internet?

>
> Marco Aurélio V. da Silva
> marco em prodatanet.com.br
> marcoprodata em gmail.com
> msn: marco em prodatanet.com.br
> Prodata Inf. e Cadastros LTDA
> (33) 3322-4444
> -----Mensagem Original-----
> From: Marcelo Gondim
> Sent: Thursday, April 05, 2012 3:43 PM
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> Subject: ***SPAM*** Re: [FUG-BR] ***SPAM*** Re: ***SPAM*** Re: Traduzir
> regra do TCPDUMP para o IPFW
>
> Em 05/04/2012 14:58, Marco Aurélio V. da Silva escreveu:
>> Caro Marcelo,
>>
>> Entendido, a minha preocupação com a porta 53 é que não sei se tinha
>> falado
>> antes, mas este servidor é um servidor de dns e email, e este servidor o
>> 222.222.222.222 é uma maquina de monitoramento da rede que envia pacotes
>> snmp para o servidor, por isto libero a saida pra ele de pacotes udp que
>> não
>> sejam pela porta 53.
> Perae vamos dar nome aos bois.  :)  222.222.222.222 é a maquina servidor
> de dns, correio e também monitoramento?
> Precisamos separar quem é quem pra poder fazer a coisa certa.
>
>
>> Agradeço a atenção recebida.
>>
>> Marco Aurélio V. da Silva
>> marco em prodatanet.com.br
>> marcoprodata em gmail.com
>> msn: marco em prodatanet.com.br
>> Prodata Inf. e Cadastros LTDA
>> (33) 3322-4444
>> -----Mensagem Original-----
>> From: Marcelo Gondim
>> Sent: Thursday, April 05, 2012 11:31 AM
>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>> Subject: ***SPAM*** Re: [FUG-BR] ***SPAM*** Re: Traduzir regra do TCPDUMP
>> para o IPFW
>>
>> Em 05/04/2012 10:06, Marco Aurélio V. da Silva escreveu:
>>> Caro Marcelo,
>>>
>>> Eu consegui bloquear o ataque com a seguinte regra:
>>> /sbin/ipfw add 150 deny log udp from any to any src-ip 111.111.111.111
>>> not
>>> src-port 53 not dst-port 53 not dst-ip 222.222.222.222 via re0
>>> e ta funcionando legal.
>> Não entendi a sua preocupação com a porta 53. Eu tentaria uma regra mais
>> global:
>>
>> ipfw add 150 deny log udp from 111.111.111.111 to any
>>
>> Igual à "Oi simples assim" rsrsrsr
>>
>> Logicamente que existem outras coisas legais para se colocar nas regras
>> do Firewall, por exemplo eu gosto de usar o setup com limit nas regras
>> entrantes, bloquear pacotes com flags estranhas e um outro que seria:
>>
>> net.link.ether.ipfw=1  mas cuidado se você habilitar esse cara e sua
>> última regra for drop pra tudo, você vai bloquear seu acesso remoto sem
>> dó nem piedade. Precisa ter uma regra dessas aqui com ele habilitado:
>>
>> ipfw add allow all from any to any layer2 mac-type ipv4,arp,rarp
>>
>> Aí sim você está liberando no layer 2 pacotes do tipo ipv4, arp e rarp o
>> que não for drop neles.  :)  só não pode esquecer do ipv6 se tiver
>> trânsito ipv6. Já peguei umas coisas muito estranhas vindo do meu clear
>> channel com essa regra.  :)
>>
>> Abaixo uma tabela que fiz para essa regra aí acima:
>>
>> ip - 0x0800
>> ipv4 - 0x0800
>> ipv6 - 0x86dd
>> arp - 0x0806
>> rarp - 0x8035
>> vlan - 0x8100
>> loop - 0x9000
>> trail - 0x1000
>> at - 0x809b
>> atalk - 0x809b
>> aarp - 0x80f3
>> pppoe_disc - 0x8863
>> pppoe_sess - 0x8864
>> ipx_8022 - 0x00E0
>> ipx_8023 - 0x0000
>> ipx_ii - 0x8137
>> ipx_snap - 0x8137
>> ipx - 0x8137
>> ns - 0x0600
>>
>> Eu sou partidário do mantenha tudo o mais simples possível.  :)
>>
>>> Os fragmentos de um dos ataques coletados pelo tcpdump segue abaixo:
>>> IP (tos 0x0, ttl 64, id 54066, offset 0, flags [none], proto UDP (17),
>>> length 29, bad cksum 0 (->12a0)!) 111.111.111.111.50222>
>>> 91.204.161.226.55624: [bad     udp cksum 4e08!] UDP, length 1
>>> IP (tos 0x0, ttl 64, id 54067, offset 0, flags [none], proto UDP (17),
>>> length 29, bad cksum 0 (->129f)!) 111.111.111.111.50222>
>>> 91.204.161.226.55624: [bad     udp cksum 4e08!] UDP, length 1
>>> IP (tos 0x0, ttl 64, id 54068, offset 0, flags [none], proto UDP (17),
>>> length 29, bad cksum 0 (->129e)!) 111.111.111.111.50222>
>>> 91.204.161.226.55624: [bad     udp cksum 4e08!] UDP, length 1
>>> IP (tos 0x0, ttl 64, id 54069, offset 0, flags [none], proto UDP (17),
>>> length 29, bad cksum 0 (->129d)!) 111.111.111.111.50222>
>>> 91.204.161.226.55624: [bad     udp cksum 4e08!] UDP, length 1
>>> IP (tos 0x0, ttl 64, id 54070, offset 0, flags [none], proto UDP (17),
>>> length 29, bad cksum 0 (->129c)!) 111.111.111.111.50222>
>>> 91.204.161.226.55624: [bad     udp cksum 4e08!] UDP, length 1
>>>
>>> Com a regra funcionando estou logando tb as tentativas de ataque, segue
>>> fragmentos do log do ipfw.
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:51541
>>> 94.125.182.234:39863 out via re0
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:51078
>>> 94.125.182.234:21345 out via re0
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:49361
>>> 94.125.182.234:63380 out via re0
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:52813
>>> 94.125.182.234:52468 out via re0
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:63571
>>> 94.125.182.234:27017 out via re0
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:63269
>>> 94.125.182.234:24971 out via re0
>>> Apr  4 10:01:09 ns1 kernel: ipfw: 150 Deny UDP 111.111.111.111:62786
>>> 94.125.182.234:34251 out via re0
>>>
>>> As  tentativas de ataque continuam, mas estaum parando todas na regra
>>> acima.
>>> Se alguém tiver alguma sugestão para melhorar a regra.
>>>
>>> Desde já agradeço a atenção recebida.
>>>
>>> Marco Aurélio V. da Silva
>>> marco em prodatanet.com.br
>>> marcoprodata em gmail.com
>>> msn: marco em prodatanet.com.br
>>> Prodata Inf. e Cadastros LTDA
>>> (33) 3322-4444
>>> -----Mensagem Original-----
>>> From: Marcelo Gondim
>>> Sent: Wednesday, April 04, 2012 4:29 PM
>>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>>> Subject: ***SPAM*** Re: [FUG-BR] Traduzir regra do TCPDUMP para o IPFW
>>>
>>> Em 04/04/2012 12:31, trober em trober.com escreveu:
>>>>> Caros,
>>>>>
>>>>> Como seria a tradução desta escuta do tcpdump para uma regra do ipfw
>>>>> para
>>>>> travar este mesmo trafego ?
>>>>>
>>>>> tcpdump -i re0 -n -q -vvv udp and src 111.111.111.111 and not port 53
>>>>> and
>>>>> not dst 222.222.222.222
>>>>>
>>>>> Desde já agradeço a atenção recebida.
>>>>>
>>>>> Marco Aurélio V. da Silva
>>> Me parece que você está tentando bloquear um ataque e coletou o ataque
>>> com as regras filtradas acima. Ao invés de tentar fazer uma regra
>>> baseada no filtro acima, poste pra gente o resultado que foi o ataque
>>> para que a gente lhe mostre uma regra adequada ao ataque e não ao
>>> filtro.  ;) Pode mascarar seu IP público.
>>>
>>>> [SNIP]
>>>> Boa tarde.
>>>>
>>>> Você aplicou três operadores lógicos "AND", ou seja, tudo precisa ser
>>>> verdadeiro, logo, a porta de origem e destino não podem ser 53, em ambos
>>>> os hosts. Procede?
>>>>
>>>> Se sim, sua regra de bloqueio fica assim:
>>>>
>>>> ipfw add deny udp from 111.111.111.111 not domain to not 222.222.222.222
>>>> not domain
>>>>
>>>> Essa é a regra que atende "ipsis litteris" o que seu TCPDUMP está
>>>> capturando. Entretanto, "ipsis verbis", é isso mesmo que você precisa?
>>>> Se
>>>> fosse um diálogo entre dois humanos, como você pediria a contraparte
>>>> para
>>>> bloquear?
>>>>
>>>> Pressupondo que você deseja que o host 111.111.111.11 somente trafegue
>>>> UDP
>>>> se for requisição DNS para o servidor 222.222.222.222, negando todo o
>>>> tráfego UDP restante, então a regra fica diferente, sendo:
>>>>
>>>> #Negar todo o tráfego UDP originado em 111.111.111.111, exceto
>>>> requisições
>>>> DNS para 222.222.222.222
>>>> ipfw add deny udp from 111.111.111.111 to not 222.222.222.222 not domain
>>>>
>>>> Espero ter ajudado.
>>>>
>>>> Saudações,
>>>>
>>>> Trober
>>>> -
>>>> -
>>>> -
>>>> -
>>>> -
>>>>
>>>>
>>>>