On Wed, Jun 15, 2016 at 11:11 AM, atar <atar.yo...@gmail.com> wrote:
>> atar wrote on 06/14/2016 20:29:
>>>> atar wrote on 06/14/2016 16:05:
>>>>>> atar wrote on 06/14/2016 14:52:
>>>>
>>>> [...]
>>>>
>>>>>>> The hostname "google.com" isn't blocked since its current ip differs
>>>>>>> from its previous ip when pf has loaded the rule, what can I do in
>>>>>>> order to be able to block such sites (with many ip addresses)?
>>>>>>
>>>>>> I would use tables and populate them periodically from shell script
>>>>>> which can do FQDN to many IPs resolution.
>>>>>>
>>>>>> It can be simple as this
>>>>>>
>>>>>> host yahoo.com | awk '$0 ~ /has address/ { print $4 }' >
>>>>>> /var/run/pf.yahoo_table
>>>>>> pfctl -t yahoo_table -T replace -f /var/run/pf.yahoo.table
>>>>>>
>>>>>> I am sure you will find better solution :)
>>>>>>
>>>>>> Miroslav Lachman
>>>>> Thanks for your answer, it is an interested idea.
>>>>>
>>>>> However, is this method of update periodically the pf tables not disturb
>>>>> or burden the performance of the pf filter engine especially if the
>>>>> script that update the tables runs too often?
>>>>
>>>>
>>>> How often is "too often"?
>>>> I think that updating the tables every 5 minutes is enough (no one uses
>>>> shorter TTL for DNS entries)
>>>> The nicest thing on PF tables is you don't need to reload PF and tables
>>>> can live in memory (not need for persistent file on filesystem) so all
>>>> operations are really quick.
>>>> Our PF firewalls are using tables with thousands of entries without any
>>>> issues.
>>>> I don't see any trouble even if you will update tables each minute.
>>>>
>>>> Miroslav Lachman
>>>
>>> Thanks again for replying.
>>>
>>> I don't know why, but even refresh rate of one minute isn't enough for the
>>> domains google.com or gmail.com.
>>>
>>> Even immediately after I load the table which has the rule to block the
>>> above mentioned domains I am still able to access those domains. Sometimes
>>> it is indeed blocked for a half of a minute but finally the chromium
>>> browser succeed to load them.
>>>
>>> Do you have any idea?
>>
>> I am not sure but it can have something with keep-state.
>>
>> If you have PF disabled, then start it, populate table and then make first
>> connection attempt (there should be no states), are you still able to
>> connect for a half minute?
>>
>> You can check tables by: pfctl -vv -s Tables
>>
>> and check states by: pfctl -vv -s state
>>
>> Miroslav Lachman
>
> Hi there,
>
> I've tried your advice but pf report on error which says that keep state is
> not make sense on block rules.
Keep state makes no sense on block rules as the error says, the block
rules reject the packet without creating a state. States are created
only by pass rules.
-Kimmo
_______________________________________________
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
