From owner-freebsd-pf@freebsd.org Wed Jun 15 11:58:51 2016 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA238A444A4 for ; Wed, 15 Jun 2016 11:58:51 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF341BEB for ; Wed, 15 Jun 2016 11:58:51 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id u201so29779445oie.0 for ; Wed, 15 Jun 2016 04:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YPpSnkYa1qq70gs+gCOnyg2V7tDvGY1D+ji6VJKUBKg=; b=f2hRHhdXDQmkdrAtCISzP4lYTyCWXU2GBsv3jl6NlxpTV0wTn1KIgLp1VnW+1WzAtL kIx+8OC87u/Xqj1NpyQNjAEj1rxOrimhhOU5oGbXzXWUQUtJy5EN0oqmMc7KU749lelZ 00KZ3yKwI4Nmbtl024soTbc8A71x5rYSrwPiB0Xuv9B5ZgwEfPSppxel14qn4mYpTzF/ UY1gMJRSxaBba48BtPp6zs7SCTyeEQPUNk0goSx2T9kyyhDmGQfJ9zXB+E8ykmVx19fV PnsvlBW2dqo2hUthaNV5V9lrDfimHm4mNNXwpmeI3Q0c1nDDVXtxwqFDX8J9dFQJvZUV CRZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YPpSnkYa1qq70gs+gCOnyg2V7tDvGY1D+ji6VJKUBKg=; b=TJyNcushVbiJgeuTg7CHS/l3TNC2/DtVNFQgwwUiypDK7QhKUP1RE5QkHUBlvzDq8U zVO1iOwOUg2i5t+y77ucXzaO6Ojw/k/ZH3pBtKSUK2LZXNtu6MFI7BrXoNl/KEkrJRKS P2Pz69QOmx8UNcAVSpTovR7SQNQ91V70vZNqwwdEBlO4bqHDk8O6G2Th/yCTWW+0FxVT g+4ePcmt+JHAB9gwciLSmnZQt4h5iwEoAiP1t3wFYQRhbV0qO+RPjMSOWCIOsqcgVtzp gq71CATD+NgCPPQiZvPD0QJ24IXNLmSYlwwMfLYXlLVwoo3iyMrwoLCFIIXo7BZzq/GF fTKg== X-Gm-Message-State: ALyK8tJeBWI84J809UQfrqZv/UhFjilmSzuwbDqcgIJxJNi5mrVPIyH0a0qo1gVYaM+PTPpImLO1i+M76FINcA== X-Received: by 10.202.193.215 with SMTP id r206mr12198445oif.109.1465991930727; Wed, 15 Jun 2016 04:58:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.16.76 with HTTP; Wed, 15 Jun 2016 04:58:50 -0700 (PDT) In-Reply-To: References: <5858A82C-FB66-4D67-A676-47EABED976CE@gmail.com> <57600481.6080204@quip.cz> <08195C33-DC97-4ADD-9C0A-D9493E2C29F7@gmail.com> <57602DEC.6080201@quip.cz> <969F8F1C-E992-4F47-89F9-759FD8CE2B91@gmail.com> <576055AC.9020605@quip.cz> From: Kimmo Paasiala Date: Wed, 15 Jun 2016 14:58:50 +0300 Message-ID: Subject: Re: Filter connections based on the hostname. To: atar Cc: Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-pf@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 11:58:51 -0000 On Wed, Jun 15, 2016 at 11:11 AM, atar 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