[FUG-BR] ipfw com deny sem sentido

[Marcelo Gondim]

Em 08/02/2012 10:51, Saul Figueiredo escreveu:
> Em 8 de fevereiro de 2012 10:48, Marcelo Gondim
> <gondim em bsdinfo.com.br>  escreveu:
>> Em 08/02/2012 10:35, Saul Figueiredo escreveu:
>>> Em 8 de fevereiro de 2012 10:28, Marcelo Gondim
>>> <gondim em bsdinfo.com.br>    escreveu:
>>>> Em 08/02/2012 10:22, Saul Figueiredo escreveu:
>>>>> Em 8 de fevereiro de 2012 10:04, Marcelo Gondim
>>>>> <gondim em bsdinfo.com.br>      escreveu:
>>>>>> Olá pessoal,
>>>>>>
>>>>>> Tem acontecido uma coisa estranha com uma regra de ipfw que tenho. Tudo
>>>>>> funciona normal mas fica me gerando uns logs que ai meu ver não deveriam
>>>>>> existir.
>>>>>> Tenho por exemplo esse trecho. Até aumentei pra 100 o limit de src-addr
>>>>>> pra ter certeza que não era isso:
>>>>>>
>>>>>> $fw add allow tcp from 187.xx.xx.44 to me 3306 setup limit src-addr 100
>>>>>> $fw add deny log tcp from any to me 3306 in via em0
>>>>>>
>>>>>> Ou seja liberei o IP 187.xx.xx.44 de conectar ao meu mysql. Funciona
>>>>>> perfeitamente. Somente esse IP conecta e os outros são bloqueados, mas
>>>>>> está me gerando log de bloqueio dele:
>>>>>>
>>>>>> em /var/log/security ele gera:
>>>>>>
>>>>>> Feb  8 09:50:23 game kernel: ipfw: 1210 Deny TCP 187.xx.xx.44:38277
>>>>>> 69.162.120.106:3306 in via em0
>>>>>> Feb  8 09:55:18 game kernel: ipfw: 1210 Deny TCP 187.xx.xx.44:34595
>>>>>> 69.162.120.106:3306 in via em0
>>>>>> Feb  8 09:57:34 game kernel: ipfw: 1210 Deny TCP 187.xx.xx.44:48869
>>>>>> 69.162.120.106:3306 in via em0
>>>>>> Feb  8 09:58:19 game kernel: ipfw: 1210 Deny TCP 187.xx.xx.44:48931
>>>>>> 69.162.120.106:3306 in via em0
>>>>>> Feb  8 09:58:27 game kernel: ipfw: 1210 Deny TCP 187.xx.xx.44:49740
>>>>>> 69.162.120.106:3306 in via em0
>>>>>>
>>>>>> Não entendi porque ele está dando deny em alguns pacotes e gerando log.
>>>>>> Como eu disse o acesso está funcionando perfeitamente mas alguns pacotes
>>>>>> estão caindo nesse deny. Why?  :)
>>>>>>
>>>>>> Grande abraço à todos.
>>>>>>
>>>>>> Gondim
>>>>>>
>>>>>> -------------------------
>>>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>>>> $fw add deny log tcp from any to me 3306 in via em0
>>>>> Marcelo
>>>>> a linha acima está fazendo isso.
>>>> Isso eu sei que ela está fazendo, o problema é que a regra anterior
>>>> libera o acesso, logo não deveria entrar nessa regra.  :) "First match wins"
>>>>
>>>> -------------------------
>>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>
>>> Mas lá no man do ipfw, na parte do log ele fala o seguinte:
>>>
>>>                Note: logging is done after all other packet matching
>>> conditions have been successfully veri-fied, verified,
>>>                fied, and before performing the final action (accept,
>>> deny, etc.) on the packet.
>> Ou seja, ele loga antes de qualquer deny ou accept. Nesse caso ele
>> estaria gerando um log mesmo se o pacote não tivesse sido negado? Nossa
>> muito estranho isso. No meu entendimento ele só deveria gerar um log
>> nessa situação se realmente houvesse um drop nessa regra. A não ser que
>> o número de conexões vindas daquele IP para o mysql tivesse passando de
>> 100. Nesse caso a regra deixaria passar e entraria no drop. Mas não
>> acredito ou não quero acreditar que o IP da outra ponta está conectando
>> mais de 100 vezes no mysql porque é uma página web e ela está em uma
>> máquina não divulgada ainda e só tem eu acessando ela para testes.
>>
>>
>>> Ou seja, meio bugado, mas normal
>>> xD
>>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
> rsrsrsrsrsr por isso que disse... "é meio bugado" eu também pensava
> assim... ou talves não seja um bug, pode ter sido feito para ser
> assim... vai entender...
>
>
>
Sabe o que parece? Que em algum momento o stateful falha e o pacote não 
é reconhecido aí ele descarta e vai pro drop. Eu uso na regra o setup e 
o limit, o setup obriga o 3 way handshake e o limit faz o stateful com a 
limitação de conexões. Só vejo isso, na comunicação algum pacote não é 
reconhecido no state e cai no drop.